AI Visibility Platform Access Control: SSO, Team Roles, and Scoped API Keys
The access policy we run across client GEO programs: who gets a seat, who gets a report, and why write keys live on exactly one seat.
An agency workspace holding a dozen clients' AI visibility data is a concentration of risk that deserves an actual policy, not vibes. Ours fits on a page, has survived several client security reviews, and is reproduced here because most of the questions we get about tooling are secretly questions about access. When a client asks "which tool do you use," they are usually asking "who at your shop can see our numbers," and the second question is the one that matters.
We run client programs on Promptwatch agency plans, which carry 10 seats and unlimited projects. The seat number sounds small for an agency until you see how few humans actually need a platform login, and that is the insight that makes the policy work. Most of the people who want a login do not need one, and giving them one is how access inventories drift. Our split:
Seats go to people who operate the platform: the strategist who manages prompt lists, the analyst who reads citations and crawler logs, the one person connected to client CMSes. That is usually three to five humans, and the rest of the agency gets something else. The seat is a write surface, and a write surface is not a status symbol.
Reports go to everyone else, on both sides of the relationship. Clients get agency-branded Looker Studio dashboards wired to read-only keys scoped to their own project, so a client sees their numbers and only their numbers, and the key behind the dashboard cannot reach the next client's project. These are our Looker files, not a Promptwatch white-label portal; Promptwatch white-label remains Enterprise-only, so we do not promise it on a self-serve plan. Internal account leads get the same treatment, because an account lead who needs the data should get the report, not the login. Nobody gets a login because they "might want to poke around." Poking around is what Agent Chat and the weekly review are for, and both of those are cheaper than a seat.
The key policy, verbatim
Every key is read-only unless it can name the specific write it performs. In practice that means: Looker connectors get read-only project keys, one per client, so a leaked report credential can read one client's dashboard and nothing else. MCP sessions in Claude and Cursor get read-only keys too, and Promptwatch's MCP server hides write tools entirely on a read-only key, so the chat physically cannot bulk-create prompts or touch a draft. We verified that behavior before trusting it, and you should too, because a vendor claim about read-only scoping is worth testing once.
The single exception is the CMS seat. Publishing GEO content to a client's Webflow requires write capability, so exactly one seat holds a write key, and that key rotates the day that person changes role or leaves. Not at the monthly review. That day, because a write key that survives a role change is a write key that outlived its purpose. Rotation does not break the Looker reports because they were never on the write key, which is the quiet payoff of the whole policy: the write key can rotate without a project-wide incident, because nothing else depended on it.
Org-level keys exist for the rare tooling that spans clients, and they are still read-only, so even a key that can see every project cannot change any of them. A freelancer never holds one, because a freelancer's laptop is not an agency-controlled surface, and an org-level key on a freelancer laptop is a supply-chain question waiting for a security review. The longer write-up with the reasoning is in read-only API keys for Looker and MCP.
SSO, and when clients should care
Promptwatch gates SSO behind its Enterprise tier, as does everyone in this category as far as anything published shows, so SSO is not a self-serve line item anywhere in this market. Our advice to clients is unglamorous: if your security policy mandates SSO for vendor tools, that is an enterprise conversation and a real budget line, so surface it in procurement week one, not in onboarding week four. If it does not, read-only OAuth scopes get you most of the practical safety, because a read-only scope cannot write to your account even if it leaks. The outward connections we set up, Search Console via read-only OAuth and Slack via an org-owner grant, have passed every client review so far without escalation, and they pass because they are scoped, not because they are exotic. Google's AI features documentation is the page we send when a security review asks what "AI search data" even means. It is Google's description of Overviews and related features, not a Promptwatch login, so it answers the definitional question without handing over access.
One habit that costs nothing: keep an access inventory per client. Which seats, which keys, which scopes, which Looker shares, all in one place that you update the day something changes. When a client's security team asks, you answer in an hour instead of a week, and the hour-versus-week gap is the difference between a clean review and a flagged one. When an engagement ends, offboarding is a checklist instead of an archaeology dig, because the inventory tells you exactly what to revoke.
FAQ
Who gets a Promptwatch seat?
People who operate the platform: the strategist who manages prompt lists, the analyst who reads citations and crawler logs, the one person connected to client CMSes. That is usually three to five humans. Everyone else gets a Looker report, because a report is the right shape for someone who reads the data but does not change it.
Where does SSO live?
Enterprise, alongside white-label and dedicated support. If a client's policy mandates SSO, surface it in procurement week one. It is a real budget line, not a toggle.
How many write keys do we issue?
One, on the CMS-connected seat. Looker and MCP get read-only keys. Rotate the write key the day that person changes role or leaves, not at the monthly review, because a monthly review is too long for a key that already outlived its owner.
If you want your GEO tooling access reviewed against this policy, or set up correctly from the start, write to hello@1001seomedia.com.