Most teams grant an agent its permissions the way they grant a new tool access during setup: broadly, quickly, and with the intention of narrowing it later. Later rarely comes. This AI agent least-privilege checklist replaces that habit with a record: every agent holds a stable identity, every capability it uses sits inside an explicit grant, and every grant covers only the minimum the agent has demonstrated it needs — with an expiry that forces the question to be asked again.
Why broad permissions are the risk to fix first¶
Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025. The cost of getting it wrong is already documented. Practitioner reports describe a runaway agent loop that burned over $700 in 72 hours with no budget control in place. Least privilege is the difference between an agent whose authority was decided and an agent whose authority was assumed.
Identity before grants¶
No grant means anything until the agent it belongs to is identified. In the Governed Agent Mesh Playbook, every agent, script, cron job, or scheduled workflow that can take an action must hold a stable, owner-scoped identity before its first action, in the format agent:[OWNER]/[NAME]. Anonymous, shared, or unregistered actors are rejected at the dispatch path — never warned through.
A shared identity breaks least privilege even when the permissions look narrow, because accountability disappears: you cannot tell which agent used a grant or should lose it. Record each identity with its owner, date issued, and status. When an agent is retired, revoke its identity — and never reissue it to a different agent.
What a least-privilege grant records¶
A grant is a record, not an assumption. Each grant records six things, and a grant missing any of them is incomplete:
- Capability. The specific action granted — not "database access," but the named operations the agent may perform.
- Scope. The projects, accounts, channels, or record sets the capability covers, and by implication everything it does not.
- Issuing owner. The human authority who made the issuance decision. The acting agent is never its own issuer.
- Date issued. When the grant was created, so its age is visible at review.
- Expiry date. When the grant ends. Permanent grants are prohibited; an expired grant is the same as no grant.
- Identity issued to. The stable agent identity the grant belongs to — one agent, not a team, not "all agents."
Least privilege lives in the first two fields: each grant covers the minimum the agent has demonstrated it needs — demonstrated, not imagined. Widening a grant later is a fresh issuance decision, recorded when it happens.
The checklist¶
Work through this list for one agent at a time. Fill every bracket before the item counts as done.
- [ ] Identity recorded: agent:[OWNER]/[NAME] exists in [IDENTITY REGISTRY LOCATION], with an owner and a status.
- [ ] Capabilities inventoried: every tool and API call the agent actually made in its recent runs is listed — from its logs, not from memory.
- [ ] One grant per capability: each capability has its own grant record with capability, scope, issuer, dates, and identity.
- [ ] Scope narrowed: each scope names the smallest set of projects, accounts, or records that covers the demonstrated need.
- [ ] Expiry set: every grant carries an expiry of [DURATION]; no permanent grants exist.
- [ ] No auto-grant path: a new capability waits for an explicit issuance decision by [GRANT AUTHORITY ROLE].
- [ ] Tiers assigned: every capability is classified Hard-gated, Bounded auto, or Draft-only by consequence.
- [ ] Spend ceiling set: every plan the agent runs under carries a cost ceiling of [AMOUNT] [CURRENCY], counted in real time.
- [ ] Fail-closed wired: a request with missing identity, grant, approval, or budget headroom blocks and writes its audit row.
- [ ] Audit rows flowing: every request, approval, block, and outcome writes a hash-linked audit row with no secrets in it.
- [ ] Retirement path written: decommissioning revokes the identity and removes its grants everywhere at once.
Tier by consequence, not by frequency¶
Least privilege is not only about how much an agent can reach — it is about which actions need a human before they run. The Playbook tiers every capability by consequence. Hard-gated actions always require recorded human approval, with no auto-grant path ever. Bounded auto actions are routine work inside an approved plan: they run automatically, fully audited, inside their bounds, and block the moment a bound is crossed. Draft-only work — preparing proposals, composing messages, planning — is recorded but never executed and never contacts anyone; sending the draft is a separate, hard-gated action.
Two rules keep tiering honest. When in doubt, tier up: a Bounded-auto action that should have been Hard-gated is an incident, while a Hard-gated one that could have been Bounded auto is just a slow afternoon. And watch the "read-only" trap — reading a credential store or exporting a customer list are reads with write-grade consequences.
Hard-gated actions never inherit a broad grant¶
Some actions require a recorded human approval no matter how trusted the agent or how broad its grants look:
- Moving money or committing spend above [THRESHOLD]
- Accepting contracts, terms of service, or legal agreements
- External outreach — emails, messages, posts, or calls to anyone outside the team
- Accessing, reading, or transmitting credentials or secrets
- Changing agent permissions or grants — including this checklist's own grant records
- Any action with legal or regulatory consequences
The approver must be a human holding the approver role; the acting agent can never approve its own action. Each approval is recorded with approver identity, timestamp, action reference, and decision. A denied or missing approval produces a recorded block, never a silent skip. Changing a grant is itself hard-gated, because an agent that can widen its own permissions has no least privilege at all.
Fail closed, and put a ceiling on the plan¶
Least privilege enforced by a prompt instruction is advice the model can drift from. It has to be enforced at the dispatch path, before the action runs. That is the fail-closed rule: when required evidence is missing — identity, grant, approval, budget headroom — the action is blocked. It is never degraded to a warning, and warning-only paths are prohibited for any action with external or financial side effects.
Spend is part of the same check. Every plan carries a cost ceiling, counted in real time; when it is reached the action fails closed and is never retried automatically. Raising a ceiling is hard-gated. A retry requires new evidence: a grant issued, an approval recorded, headroom restored.
Every decision leaves an audit row¶
A least-privilege system you cannot review is a claim, not a control. Every request, approval, block, and outcome writes an audit row, hash-linked to the row before it, recording the actor, the action, the target, the outcome, and the timestamp. Blocked actions record the exact reason, and tell the owner in plain language which piece of evidence would unblock them.
Rows are append-only, and audit data never contains secrets or credentials. These rows make the next access review fast: you read what the agent did, what it was granted, and what it was refused.
Common mistakes¶
- Permanent grants. A grant with no expiry is a decision nobody will ever revisit. Renewal is a decision, not a default.
- Shared identities. One name for several agents destroys attribution, and with it the ability to revoke precisely.
- Granting the tool instead of the capability. "Email access" is not a grant. Reading one mailbox and sending as the team are different capabilities, in different records.
- Starting broad "for now." Temporary breadth becomes permanent by neglect. Start at the demonstrated minimum and widen by issuance decision.
- Letting the agent maintain its own grants. Adding a capability or widening a scope is a permission change — hard-gated, human-approved, recorded. Never the agent's own edit.
- Warnings instead of blocks. A warning-only path for a consequential action teaches everyone that the boundary is decorative.
The 10-minute starter version¶
Pick one agent — the one with the broadest access, not the easiest one. List the capabilities it actually used in its recent runs, from its logs. Write one grant per capability: the narrowest scope covering the demonstrated need, an issuing owner, and an expiry. Tier each capability by consequence, set a cost ceiling on its plan, and turn on the default: anything without a matching, unexpired grant blocks and writes its audit row.
That is the core of this AI agent least-privilege checklist: authority as records — identity first, minimum capability and scope, expiry on everything, hard gates where consequence demands them, fail-closed enforcement, and an audit row for every decision. Narrow by default, widen only by decision, and let expiry keep asking whether each grant still earns its place.