Scoping agent permissions before the agent exists

The order most teams do this in, and what it costs

The usual sequence is: build the agent, wire the tools, demo it, then ask security to look at it. Security asks what identity the thing runs as. The answer is a service account created during the prototype that can read every row in the warehouse, because that was the fastest way to make the demo work. The permission model is now a refactor of every tool, every test and every integration, quoted at six to ten weeks and landing inside a launch commitment. We have been called into that room. The rebuild is not hard engineering. It is expensive at the wrong moment.

The alternative costs about three days. Before any tool is written, decide four things and write them down: whose authority the agent acts under, what data it may touch and in which direction, which actions require a person, and the ceiling on tokens, calls and dollars per run. Those four answers determine the shape of every tool signature that follows. Decided first, they are free. Decided last, they are a rewrite.

Whose authority is it, actually

Start here because everything else depends on it. When the agent calls the CRM, whose permissions apply? There are three real answers and they have very different consequences.

The initiating user's. The agent gets a token scoped to the person who asked, and every downstream call carries it. Your existing access controls keep working unchanged. If a support rep cannot see the enterprise contracts table, neither can the agent working on their behalf. This is the right default for anything user-facing, and it is the answer that makes the security review short.

A dedicated service identity with a narrow grant. Correct for scheduled work where no user initiated anything. The discipline is that the grant is enumerated, not inherited: three tables, two API scopes, one write path, reviewed on a schedule. A service identity is dangerous only when it was created by copying an admin role.

A delegated identity that is neither. The agent acts as a distinct principal with its own entry in your identity provider, its own group memberships and its own audit trail. This is the mature pattern for agents operating across users, and it is what makes the log answer "who did this" without ambiguity. Worth the setup once more than one team depends on the system.

Read scope: the direction nobody budgets for

Teams reason carefully about writes and casually about reads, which is backwards. An agent that reads broadly and produces text has a path from any record it can see to any surface it can write to, including a chat window a person is watching. And if the read scope includes protected health information, cardholder data or controlled unclassified information, then the agent, its logs, its vector store and its model provider are all inside a boundary somebody has to document.

The specific trap is the retrieval index. A team builds one index over "the company knowledge base" because that is one job instead of nine, and it quietly becomes the union of every permission that ever existed on any source document. Row-level permissions enforced in the source system are not enforced in the embedding store unless someone built that, and building it afterward means reindexing with metadata you did not capture. Two to four weeks, and the most common avoidable rework we see.

The mechanism is not complicated: every chunk carries the access-control identifiers of its source document, and every query filters on the caller's entitlements before the similarity search. Filtering after retrieval leaks through result counts and through anything the model has already seen. Capture the metadata at ingest even if you do not enforce on it yet. That costs an afternoon. Adding it later costs the reindex.

Write scope, and the two-tier rule that actually holds

Sort every action into reversible and irreversible, honestly. A draft is reversible. A database update with a recorded prior value is reversible. An email that has left your server is not. Nor is a payment, a row deleted without soft-delete, or a message posted into a customer's channel.

Reversible actions run without asking. Irreversible ones require a person. The rule fails in one specific way: teams gate too much. A user who has clicked through nine confirmations is not reading the tenth, and approval fatigue turns a safety control into a rubber stamp with a log entry. Keep the gated tier short enough that each prompt is a real decision.

The confirmation has to show consequence, not intent. "The agent wants to update customer records" is not something a person can evaluate. "Update 1,247 records: set status from active to archived; reversible for 30 days via the audit log" is. Show the count, the diff, and what undo looks like. If the architecture cannot produce that preview, the gap is in the tool design.

Read the last two rows together. A budget ceiling is cheap late because it wraps the loop rather than the tools. The identity decision is expensive late because it threads through every call signature in the system. That asymmetry is the whole argument for a design document instead of a hardening sprint.

What the frameworks already say, and why that helps you

You do not have to invent the vocabulary. Four published references cover this ground, and a customer's security team will recognize all four.

The OWASP Top 10 for LLM Applications names excessive agency as a distinct risk category: an agent granted more functionality, permission or autonomy than the task requires. Its stated remedies are the ones above, in the same order. Naming your design against that entry gives a reviewer a map instead of a novel. The same list names prompt injection and insecure output handling, which are the two attack paths that convert excessive agency into an incident. MITRE ATLAS sits next to it, cataloging adversary behaviors against AI-enabled systems in the ATT&CK structure, and starting a threat model from that list is faster than starting from a whiteboard.

The NIST AI Risk Management Framework supplies the governance shell: who owns the risk, who approves the deployment, what gets measured, what the escalation path is. Govern and Map are where permission decisions live, and mapping your design to specific subcategories makes it legible to a regulated buyer. For financial institutions, SR 11-7 is older and stricter and applies to agents whether or not anyone has said so. It requires effective challenge from parties independent of the developers, and an agent that takes actions is a model whose outputs are decisions.

Where the work touches government systems, the control language is NIST SP 800-53 and 800-171. AC-2 for account management, AC-6 for least privilege, AU-2 and AU-3 for what the audit record must contain. If the design already answers those, the assessment conversation is short.

Rate, budget and the runaway loop

An agent with a tool that keeps failing will call it again. Without a ceiling, that is a bill and, for anything that writes, a real incident. Four limits belong in the design, and all four are inexpensive to add before the loop is written.

A step ceiling per run, so the loop terminates whether or not it succeeded. A token and dollar ceiling per run and per user per day, enforced by the orchestrator rather than by a dashboard someone checks on Monday. A per-tool call ceiling, because forty calls to one failing endpoint is a different bug from forty calls across ten tools. A concurrency limit per identity, so one user cannot start two hundred runs. When a ceiling is hit the run stops cleanly and reports what it completed. Partial completion is a legitimate outcome and it needs a state.

Assume everything the agent reads is hostile

Documents, web pages, ticket bodies, email, tool responses, database fields a customer can edit. Any of it can contain text written to steer your agent. Instructing the model to ignore instructions in data does not solve it, because the model cannot reliably distinguish a sentence written by your user from one written by an attacker inside a PDF the user uploaded.

The defenses that hold are structural. Keep the boundary between instruction and data explicit in how the context is assembled, so untrusted content sits in a marked region and is never concatenated into the system prompt. Put the guarantee in the permission layer: an agent that structurally cannot delete does not need to be persuaded not to. Treat model output flowing into another system as untrusted input to that system. And log the fully rendered prompt for every step, because the question at two in the morning is always what the model actually saw.

Scope is what turns a successful injection from a breach into a nuisance. If the worst an injected instruction achieves is a wrong draft in a document the user reviews, you have an annoyance. If it reaches the production database with write access, you have a disclosure.

The permission matrix, written before the code

Here is the artifact. One table, filled in during design, reviewed by whoever owns the data and whoever owns the risk. Short enough to write in an afternoon, specific enough to generate the tool signatures.

Column	What goes in it	What it prevents
Capability	The action in the user's words. "Refund an order." "Draft a reply to a support ticket." Not the tool name.	Tools that exist because an API was available rather than because a task needed them
Acts as	Initiating user, named service identity, or delegated agent principal. One of the three, written down.	The convenience key that quietly became the production identity
Reads	Named data classes and the sensitivity of each. Not "the knowledge base."	A retrieval index that is the union of every permission that ever existed
Writes	Named systems, and reversible or not, with the undo mechanism stated.	Discovering during an incident that there is no undo
Gate	Automatic, or approval by a named role, with the preview the approver will see.	Approval fatigue on one side, ungated irreversible actions on the other
Ceiling	Calls per run, spend per run, concurrency per identity.	The retry loop that becomes an invoice
Audit	What is recorded, where it goes, how long it is kept.	An incident nobody can reconstruct, and a control that fails its own evidence test

Every blank row is an unanswered design question, and it is cheaper to find it in the table than in the code. In practice the exercise removes capabilities: a team writes down twelve and finds four existed only because an API had the endpoint.

Where the government version differs

If the system will touch federal data, three things change and none of them are surprises if you planned for them.

Authorization becomes a document. The permission model appears in a system security plan, mapped to 800-53 controls, reviewed by an authorizing official accepting operational risk for an agency. That official is not evaluating whether the engineering is clever. They are deciding whether a stated risk is acceptable, and a bounded claim with a mitigation is far easier to accept than an unbounded one with none.

The model provider becomes part of the boundary. If the agent sends controlled unclassified information to a model API, that API is processing regulated data and the FedRAMP status of the service becomes a live question rather than a procurement footnote. Deciding this at design time changes which model you build against. Deciding it after integration means changing model providers under deadline.

Audit expectations are specific. The record establishes what happened, when, by which identity and with what outcome, and it is protected from the thing it audits. An agent writing its audit log to a store it can also delete has not produced an audit trail. Commercial systems get away with that. Federal ones do not.

What this looks like as a piece of work

Three days of working sessions, not a document handed over. Day one is the capability list and the identity decision, with whoever owns the data in the room, because that decision is theirs and not the engineering team's. Day two is read and write scope per capability, which is where the list gets shorter. Day three is gates, ceilings, the audit record, and a threat model written against ATLAS techniques and the OWASP entries. Out of it comes the matrix above, the tool signatures it implies, and the list of what has to change in your identity provider before the first tool is written.

Then the build proceeds normally, and the security review at the end is a conversation about a document that already exists rather than a discovery process. The engineering is the same engineering. The order determines whether it ships.

Bottom line

Permissions are not hardening. They are the shape of the system. Whose authority the agent borrows, what it can see, what it can change without asking and what it may spend are four answers that determine every tool signature, every log record and every conversation with a customer's security team. Answered in three days, they cost almost nothing. Answered after the tools exist, they cost a quarter and arrive on the critical path. The teams shipping agents into regulated environments are not the ones with better models. They are the ones who wrote this down first.

Frequently asked questions