Read-only by design: how Who Sees What connects, and what it never touches
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 read-only access, 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. The worst thing a read-only tool can do is read, and we have kept it that way on purpose.
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. The way to make that safe is to ask for the least possible and to be able to prove it. Read-only with no install means the blast radius is small and the connection is yours to cut. 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.
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.