Safe with full access, by design
Every security tool runs into the same bind. To tell you something useful about your access, it needs access. To show you who can see a record, it has to read how your org is configured. The more a tool can help you, the more it generally needs to touch. So the honest question is not “how do we keep this tool away from your data,” it is “how do we make a tool that is safe to connect even when it can reach what it needs to.”
For a long time the easy answer was “we only read, we never write.” That is a true and comforting thing to say, and Who Sees What is in fact read-only today. But read-only as the whole safety story has a short shelf life. The moment a tool needs to actually fix something, or act on your behalf, the “we can’t touch anything” promise falls apart, and you are left with no safety story at all. A promise that only holds as long as the product stays weak is not much of a promise.
We would rather build the safety in, so it holds no matter what a product is able to do. Here is what that means for Who Sees What, and for everything Digadop builds.
Safety comes from the design, not from staying at arm’s length
Least privilege by design. Each product asks for only the access its job requires, and what it reads and writes is spelled out in its Product Schedule. Nothing important is hidden in the fine print.
A deterministic core. The heart of Who Sees What, the actual “who can see what” answer, is computed by deterministic analysis, not by an AI making a guess. The findings are exact and reproducible. AI features are a separate, clearly governed layer, not the thing deciding your access results.
You authorize, and you stay in control. You connect the org. You choose what to turn on. You can scope it down, disable it, or revoke access at any time, straight from Salesforce. The connection is yours, not ours.
Changes are opt-in, deliberate, and logged. Anything that could change your org is off by default and takes a separate, elevated authorization to enable. Where a product can write, it works with per-change approval and an audit log of every change it makes. There is no quiet path from reading to writing.
Isolated and encrypted. Your tenant is isolated from every other customer, enforced down at the database with row-level security. Stored credentials are encrypted with AWS Key Management Service, and data is encrypted in transit. It all runs inside our own AWS environment in the United States.
Your data never trains someone else’s model. When AI does process your data, it runs through AWS Bedrock inside our environment, and your data is never used to train a model that benefits another customer.
We say exactly what each product does. Read-only products are described as read-only. Products that write tell you what they write. We do not overstate it, and we do not understate it.
So where does read-only fit now?
Right where it should: as one true fact about Who Sees What today. Who Sees What reads how access is configured and reports on it. It does not write to your org. That is accurate, it is a real protection, and we are not taking it away. What we are retiring is the idea that read-only is the reason the product is safe. It is a property of one product, not the foundation of the whole thing.
That distinction matters the first time a Digadop product needs to do more than look.
Why this holds up when a tool can act
Lynceon, our dedicated Salesforce security product, is coming soon, and it is designed to go a step further than Who Sees What: to help you act on what an audit finds. That means, at your election, reading more and writing changes back to your org.
Notice that none of the pillars above break when that happens. Least privilege still applies. You still authorize it, and any write capability is still off by default behind a separate step. Every change is still approved and logged. Your tenant is still isolated, and your data still trains no one’s model. A tool that can write is not less safe under this model, because the model never depended on the tool being unable to write in the first place.
That is the whole point. Read-only was a comfortable place to start. Engineered safety is what actually scales.
Curious what your own org looks like today? Run a quick scan. Who Sees What is read-only, and it takes about five minutes.