Assessments
Agent Access Scope Checker
An AI agent wired into a billing database to save time could read every customer's records. Nobody decided that. It fell out of a connection string. This checker makes the decision explicit: what the agent can reach, what it needs, and which controls its tier requires.
The one rule
Enforce scope where the data lives, not in the agent's instructions. A prompt that says "only look at this customer's records" is a hope. A database role that can only read a view of this customer's records is a control. Every control this checker requires is of the second kind: roles, views, row-level security, scoped and short-lived credentials, approval gates in the workflow itself.
Answer ten questions. You get a tier from 1 (Standard) to 3 (Restricted), the reasoning in plain sentences, a least-privilege version of the agent's reach, the control checklist for its tier, and the exposure that remains. Export it as a scope statement and attach it to the use-case intake.
Start from a worked example, or clear it and describe your own agent.
An internal helper wired into the full billing database to answer questions faster. It only reads, and it only drafts answers. It can still see every customer's records.
Scope result
Tier 3 of 3: Restricted
Why this tier
- Sensitivity: the agent can reach regulated personal information, the highest data class in its reach.
- Autonomy: the agent only drafts or suggests; a person decides and acts.
- Reach: the agent holds standing access to full stores rather than scoped views, which widens what a compromise gets.
- Credentials: the agent runs on standing shared credentials, so its access cannot be revoked per task.
Least-privilege scope
- Billing database (all customer accounts): replace full-store access with restricted views or a scoped subset covering only the records and fields the task uses.
- Internal wiki: replace full-store access with restricted views or a scoped subset covering only the records and fields the task uses.
Required controls for this tier
Residual exposure
Even with every control in place, a compromised or misbehaving agent can still read regulated personal information in Billing database (all customer accounts) until its credentials are revoked. The people affected would be customers. Scoping to views and per-task credentials shrinks how much is exposed at once; it does not make the exposure zero.
This is a worksheet, not a security review. The tier is a judgment aid that shows its reasoning; the person who owns the risk makes the final call.
Read the full scope statement
SCOPE STATEMENT: Billing questions helper Purpose: Answer internal questions about accounts and invoices Owner: Operations lead Assessed: 2026-11-07 Tier 3 of 3: Restricted Why this tier: - Sensitivity: the agent can reach regulated personal information, the highest data class in its reach. - Autonomy: the agent only drafts or suggests; a person decides and acts. - Reach: the agent holds standing access to full stores rather than scoped views, which widens what a compromise gets. - Credentials: the agent runs on standing shared credentials, so its access cannot be revoked per task. Stores in reach: - Billing database (all customer accounts): regulated personal information - Internal wiki: internal information Least-privilege scope: - Billing database (all customer accounts): replace full-store access with restricted views or a scoped subset covering only the records and fields the task uses. - Internal wiki: replace full-store access with restricted views or a scoped subset covering only the records and fields the task uses. Required controls: - [ ] Name an owner for the agent and record it in the AI use-case inventory. - [ ] Issue the agent its own scoped API token or service account; never run it on a person's credentials. - [ ] Log every tool call with the agent identity, the store touched, and the outcome. - [ ] Give the agent a read-only database role wherever writes are not required for the task. - [ ] Point the agent at restricted views or row-level security policies instead of base tables. - [ ] Replace standing credentials with per-task or short-lived credentials. - [ ] Require human approval before the agent sends anything outside the organization or writes to a production store. - [ ] Where the agent reads the public web, enforce the source allowlist at the fetch layer (proxy rule or API setting), never only in the prompt. - [ ] Remove all standing credentials; issue credentials per task and revoke them when the task ends. - [ ] Make base-table access technically impossible: views and row-level security are the only path to regulated data. - [ ] Give the agent no write access to stores holding regulated data; writes go through a queue a person reviews and releases. - [ ] Have a named reviewer read the full tool-call log on a fixed schedule. - [ ] Document a kill switch that revokes the agent's credentials and network access in one step, and test it. - [ ] Raise tool-call logging to full fidelity (inputs, stores touched, outputs) before this agent's next run; partial logs cannot support the review this tier requires. Residual exposure: Even with every control in place, a compromised or misbehaving agent can still read regulated personal information in Billing database (all customer accounts) until its credentials are revoked. The people affected would be customers. Scoping to views and per-task credentials shrinks how much is exposed at once; it does not make the exposure zero. This statement was produced by a worksheet, the Agent Access Scope Checker on movahedi.ca. It is not a security review, not a penetration test, and not legal advice. The tier is a judgment aid that shows its reasoning; a person who owns the risk makes the final call.
How the tier is set
Two inputs do most of the work: the most sensitive data in the agent's reach, and how much autonomy it has. Two modifiers widen it: standing access to full stores instead of scoped views, and a blast radius that reaches customers or the public while the agent acts on its own. One hard rule sits above the arithmetic: an agent holding full-store reach into regulated personal information is Tier 3 even if it only reads and only drafts, because the exposure is the read access itself.
What this is not
Not a security review, not a penetration test, and not a compliance assessment of the use case. For the use case itself, run the PIA Questionnaire Builder. For the program around the agent, start with the AI Governance Starter Checklist and the Privacy and AI Governance Maturity Assessment.
Questions
What is an access scope statement?
A one-page record of what an AI agent can reach, what it actually needs, which controls its risk tier requires, and what exposure remains even with the controls in place. It attaches to an AI use-case intake the way a data-flow note attaches to a PIA.
Why does the checker refuse to count prompt instructions as controls?
Because a prompt is a request the model can be talked out of, by a user, a poisoned document, or its own confusion. A control that holds is enforced where the data lives: a database role, a restricted view, row-level security, a scoped token that expires. The checker only credits controls of that kind.
Where do my answers go?
Nowhere. The assessment runs entirely in your browser. Nothing is stored, sent, or logged by this page.
Is the tier a grade?
No. There is no pass or fail. The tier is a judgment aid that shows which of your answers drove it, so a reviewer can argue with the reasoning instead of a number.