Skip to main content

Developer blog

Scoping what an AI agent can reach: the Agent Access Scope Checker

A client-side worksheet that turns an AI agent's data reach into a risk tier and a one-page scope statement, counting only controls that are enforced where the data lives.

ShareLinkedIn
AI governanceagentsaccess controlleast privilegedevelopers
On this page
  1. The failure this is built for
  2. How the tier is set
  3. The one design rule
  4. Three examples, preloaded
  5. The scope statement

Key takeaways

  • Ten questions about an agent’s data stores, autonomy, credentials, and blast radius produce a tier from 1 (Standard) to 3 (Restricted), with the reasoning in plain sentences.
  • A prompt or config instruction never counts as a control. Controls must be enforceable at the data layer: roles, restricted views, row-level security, scoped or short-lived credentials.
  • The output is a one-page scope statement: stores in reach, least-privilege scope, the tier’s control checklist, and the exposure that remains. Nothing leaves the browser.

The failure this is built for

A team connects an agent to its billing database so staff can ask questions in plain language. The agent only reads. It only drafts answers for a person to send. It can also see every customer’s records, because the connection it was handed can. Nobody scoped it to the accounts the questions are actually about. Nobody decided the agent should hold that reach; it fell out of a connection string and a deadline.

Governance programs review use cases: the purpose, the vendor, the model. The reach, the actual list of stores and the sensitivity of what sits in them, usually gets one line. This checker exists to make that line the whole worksheet.

How the tier is set

Two inputs do most of the work. The first is the most sensitive data in the agent’s reach, on a four-step scale from public to regulated personal information. The second is autonomy: drafts only, acts after a person approves, or acts on its own. Two modifiers widen the result: standing access to full stores instead of scoped views, and a blast radius that reaches customers or the public while the agent acts unsupervised.

One hard rule sits above the arithmetic. An agent holding full-store reach into regulated personal information lands in the top tier even when it only reads and only drafts. The exposure is the read access itself. Autonomy does not shrink it, and a careful prompt does not either.

The result is a tier, never a score out of 100. A tier with named drivers can be argued with. A number like 73 cannot; it just gets believed.

The one design rule

Every control the checker requires is enforceable where the data lives. A read-only database role is a control. A restricted view or a row-level security policy is a control. A per-task credential that expires is a control. A human approval gate wired into the workflow is a control.

“Tell the agent not to open other customers’ records” is not a control. It is a request the model can be talked out of, by a user, by a poisoned document it reads, or by its own confusion. The practitioner discussions behind this tool keep landing on the same sentence: enforce scope in the database, not in the agent’s configuration. The checker is that sentence, turned into a form.

Three examples, preloaded

The billing agent above is the first example. It comes out Tier 3, and the driver list says why: regulated data, full-store reach, standing shared credentials.

The second is a research agent that searches public sources and emails a morning brief. Public data, one team affected, per-user credentials. It lands mid-tier, and its real questions turn out to be about source allowlists and how long the briefs are kept, not about the data it touches.

The third drafts customer support replies from a ticket system, with a person approving every reply before it sends. Gated, it sits in Tier 2. Move its autonomy switch to acting on its own and it jumps to Tier 3. The approval gate was doing real work, and the worksheet shows exactly how much.

All three examples are editable. Change an answer and the tier, the control list, and the statement change with it.

The scope statement

The export is one page: the agent’s purpose and owner, the stores in reach with their sensitivity, the least-privilege version of that reach, the control checklist for the tier, and a residual exposure paragraph in plain words. Even with every control in place, a compromised agent can read what its credentials can read until someone revokes them. The statement says that out loud, because a scoping document that hides the remainder is marketing.

It also says what it is: a worksheet, not a security review. Attach it to the use-case intake next to the PIA. When the agent’s reach changes, and it will, run it again.