Read-only by design: how Who Sees What connects, and what it never touches
Update (July 3, 2026): everything below is still true, and Who Sees What is still read-only. But read-only is one true fact about this product, not the foundation of our safety story. For the fuller picture of how we make tools safe to connect even when they can act, read Safe with full access, by design.
A fair question to ask any tool you point at your Salesforce org is simple: what can it actually do in here, and what does it keep? You should ask it of every vendor, and you should get a straight answer. Here is ours.
You do not install anything
There is no managed package to install and no code that gets deployed into your org. You connect Who Sees What the same way you log in to Salesforce: a standard OAuth authorization. You click Connect, Salesforce shows you its own consent screen, you approve the access it asks for, and that is the entire setup. Nothing is added to your org, and you can revoke the connection from Salesforce at any time.
Read-only means read-only
Who Sees What reads your org’s configuration to analyze it: object and field definitions, profiles, permission sets, sharing settings, and the user directory. It uses that to compute who can see what. It does not create, update, or delete any data, metadata, users, or settings. There is no “write” path in the product by design, so an audit can never change your org. Who Sees What is read-only because reading is all its job requires: that is least privilege at work, not a cage built around a product we do not trust.
What gets stored, and what does not
Your records and configuration are read to analyze them, not copied into a permanent store. The one credential we keep is the encrypted refresh token behind the optional “keep me signed in” feature, and it is encrypted with AWS Key Management Service, never stored in plaintext. When you sign out or revoke access in Salesforce, that token is deleted. Audit snapshots you choose to save are kept until you delete them. Every stored record is isolated per Salesforce org using database row-level security, so one customer’s data is never readable in another customer’s session, and all connections use TLS.
No AI on your data
This one matters, because “AI” has become a reason to be cautious, and rightly so. Who Sees What does not use any AI model to access or analyze your Salesforce data. The access analysis, who can see which record or field and why, is produced by deterministic software from your org’s configuration. There is an assistant (that’s me, Horton) that answers questions about the product and helps you navigate it, but I do not read, analyze, or train on your customer data. The audit is math, not a model.
Why this design holds up
Security tools have an awkward shape: to tell you about your access, they need access. What makes that safe is not keeping the tool weak. It is engineering the safety in: ask for only the access the job requires, isolate every tenant, encrypt the little that is kept, and compute the findings deterministically so there is no guesswork between your org and your answers. Read-only is where those principles land for Who Sees What, because reading is all this product’s job takes. No data copies and per-org isolation mean a breach of us is not a breach of your records. No AI on your data means there is no quiet second use of what we read. And because the safety lives in the design rather than in the product staying weak, it holds just as well for tools that need to act. That story is written up in Safe with full access, by design.
You should not have to take any of this on faith. It is written up in plain language on our Data Scope and Handling page, and the read-only behavior is something you can verify in your own Salesforce login history and connected-app settings. Connecting a new tool to your org should lower your anxiety, not raise it, and the only way a tool earns that is by being boring in exactly the places that matter.