[ LEARN // AI AGENT GOVERNANCE ]
AI agent least privilege
AI agent least privilege means every agent starts with zero permissions and receives only explicit, scoped grants — per agent, per system, per condition — sized to its task. It is the classic security principle applied to a new actor class: software that improvises.
[ WHY AGENTS BREAK CLASSIC LEAST PRIVILEGE ]
Least privilege was designed for two kinds of actor. Humans hold stable roles: a database administrator needs database permissions this quarter and next, so a role scoped to the job description works. Services hold fixed call patterns: a deterministic program makes the same calls every run, so you can enumerate exactly what it needs at integration time and grant precisely that. In both cases the privilege question is answered once, up front, and stays answered.
Agents fit neither model, because agents improvise. The same agent may legitimately need read_file this minute and want merge_pull_request the next — its need is task-dependent, not role-dependent, and the task was chosen by a model at runtime, not enumerated by an engineer at integration time. Faced with an actor whose needs can't be predicted, teams respond by over-granting "to be safe" — which is exactly how a changelog bot ends up holding credentials that can drop tables. The fix is not a broader role that covers every task the agent might attempt. It is per-action authorization at runtime: deciding each attempted action on its own merits, at the moment it is attempted — the question at the center of AI agent runtime governance.
[ BLAST RADIUS THINKING ]
The practical measure of an agent's privilege is not how many permissions it holds — it is what the worst plausible action it can execute would cost. That number is the agent's blast radius, and it is worth computing before any debate about which grants are convenient. An agent that can read files and post comments has a blast radius of an embarrassing comment. An agent that can merge to main and run production queries has a blast radius of an outage.
What makes this the right frame is a fact about how agents fail: prompt injection and plan errors do not grant new permissions — they exploit existing ones. A poisoned document can convince the model to attempt anything, but the attempt only becomes damage if a grant lets it execute. An agent that can only read and comment has a small blast radius no matter how badly it is steered; an over-granted agent turns every model failure into a potential incident. Framed this way, granting permissions is blast-radius budgeting: each grant buys capability and spends safety, and the question for every grant is whether the task is worth the worst case it enables.
[ THE GRANT MODEL ]
Least privilege for agents reduces to four rules. Together they replace "what might this agent need someday?" with "what does this task require right now, and who approved it?"
Zero-permission default
No agent can do anything until someone writes a grant saying it can. There is no baseline role, no template of "what agents usually need", no implicit allowlist. The default answer to every tool call is no.
Explicit, scoped grants
Each grant names an agent identity, a target system, a tool, and optionally a condition — parameters, branch, environment, rate. A grant is as narrow as the sentence describing the task: "changelog-bot may read files and create comments on GitHub", nothing wider.
Approval instead of standing permission
For actions an agent genuinely needs but should not hold as a standing right — merging to main, touching production — the grant is require_approval, not permit. The action stays possible; the permission never sits idle waiting to be exploited.
Grants as reviewable artifacts
Grants live in version control as plain text, not in a console someone configured once. Every widening is a diff a reviewer can question in a pull request, and every existing grant can be re-read, re-justified, or deleted on a schedule.
[ WHAT IT LOOKS LIKE IN PRACTICE ]
The grant model is most useful as plain, versionable text: a default-deny rule at the top, then one narrow grant per agent per task. In YAML:
# Default posture: nothing is granted until it is granted.
- agent: "*"
server: "*"
tool: "*"
action: block
# The changelog bot may read and comment on GitHub — nothing else.
- agent: changelog-bot
server: github
tool: [read_file, create_comment]
action: permit
# The data-sync agent may run queries — never against production.
- agent: data-sync
server: postgres
tool: execute_query
when: { environment: "!production" }
action: permit
# Merging to main stays possible — with a human in the loop.
- agent: deploy-bot
server: github
tool: merge_pull_request
when: { branch: main }
action: require_approvalZero-permission default, scoped permits, conditions, and approval instead of standing permission.
Because grants are text in version control, they inherit the software lifecycle for free. A proposed widening arrives as a pull request diff — one visible line where a reviewer can ask why the changelog bot suddenly needs delete_file. And grants can be tested in CI like any other production change: assert that the calls each agent's task requires are permitted, that known-dangerous calls are blocked or gated, and that a policy edit never silently widens another agent's blast radius. Least privilege stops being a posture someone remembers to maintain and becomes a property the pipeline checks.
[ BEST PRACTICES ]
- ◈One identity per agent. Shared credentials make least privilege unenforceable: a grant scoped to "the service account" is a grant to every agent behind it, and no grant can be narrower than the identity it attaches to.
- ◈Grant tools, not scopes-of-everything. "read_file and create_comment on github" beats a repo-wide OAuth scope: the unit of grant should match the unit of action, because the unit of misuse is the action.
- ◈Prefer conditions to broad permits. "execute_query when environment is not production" is a smaller blast radius than "execute_query" — most over-grants are missing conditions, not wrong tools.
- ◈Use approval gates as the pressure valve. When a team can pause an action for a human instead of permitting it outright, they stop widening grants "just in case" — approval is what keeps the standing grants narrow.
- ◈Review grants on a schedule. Put a recurring review on the calendar and re-justify every grant against what the agent does today, not what it was built for.
- ◈Delete unused grants. A permission no recent task has exercised is pure blast radius with zero utility — remove it and let the next legitimate need arrive as a reviewable diff.
[ HOW SENTNELOPS IMPLEMENTS THIS ]
[ FREQUENTLY ASKED QUESTIONS ]
What does least privilege mean for AI agents in one sentence?
Every agent starts with zero permissions and receives only explicit grants — scoped by agent identity, target system, tool, and condition — sized to the task it exists to do, with everything else denied by default.
Why not just use IAM roles?
IAM authorizes the credential, not the specific action-in-context: a role decides what the holder of a key may ever do, once, at grant time. An agent improvising through a task needs a per-call decision — is this agent allowed to call this tool, on this system, with these parameters, right now? Roles are the input to that decision, not a substitute for it.
Doesn't least privilege make agents useless?
No, because rare-but-needed actions don't require standing permission — they require an approval gate. An agent whose grants cover its routine work, plus require_approval rules for the occasional dangerous action, can do everything it legitimately needs while holding almost nothing an attacker or a broken plan could abuse.
How does least privilege limit prompt injection?
Prompt injection steers the agent's behavior; it does not mint new permissions. Whatever the injected instructions say, the agent can only execute actions its existing grants allow — so narrow grants cap the damage of a successful injection. An agent that can only read and comment stays a read-and-comment problem no matter how thoroughly it is fooled.
How often should grants be reviewed?
On a fixed schedule — quarterly is a reasonable default, monthly for agents touching production — plus ad hoc whenever an agent's task changes. The review question is simple: does each grant still map to a task this agent performs today? Anything that fails the question gets deleted; if the need returns, it comes back as a reviewable diff.