The principle of least privilege has been a foundational security tenet for fifty years, since Saltzer and Schroeder articulated it in 1975: every program and every user should operate using the least set of privileges necessary to complete the job. For human users and conventional service accounts, organizations have spent decades operationalizing this through identity providers, role-based access control, and quarterly access reviews. For AI agents, almost none of that infrastructure works as-is, because agents have properties that humans and services do not: their actions are non-deterministic, their identity is often borrowed from whichever account spun them up, and their permission surface fans out across every tool, data source, and downstream system they can reach. The result is that the average agentic deployment today operates with permissions far in excess of what any of its individual tasks require. That gap is where the highest-leverage security work happens. For the broader risk picture this control sits within, the OWASP Top 10 for Agentic Applications remains the canonical reference, and the controls described here map directly to ASI03 (Identity and Privilege Abuse).
Why least privilege is harder for agents than for services
A traditional microservice has a static, declared set of dependencies: it talks to these databases, calls these APIs, and writes to this queue. Its permission set can be enumerated at build time and reviewed by humans. An agent's permission set is, in principle, the union of every tool it has ever been registered against, every data source it can query, and every other agent it can hand off to. Many of those are added incrementally over the agent's life, by different developers, for different tasks. The default outcome, absent deliberate design, is the agentic equivalent of a service account with sysadmin-equivalent reach — what the Cloud Security Alliance calls "scope creep" and what the OWASP Agentic Top 10 catalogues under identity and privilege abuse.
That figure tracks closely with what the CSA, Microsoft, and OWASP have all converged on independently: scope is the highest-leverage structural control available to teams deploying agents today, and the gap between the permissions an agent is granted and the permissions any single task actually needs is the surface area most agent incidents propagate through. Closing that gap is what this control is about. It is also why guardrails before production treats default-deny tool permissioning as the foundational layer rather than an optimization.
The four dimensions of agent privilege
Tool Scope
Which tools the agent is permitted to invoke. The default for a new agent should be the empty set, with each tool explicitly added per agent persona. The CSA scope control framework identifies this as the single most impactful structural control available today.
Data Scope
Which records, documents, and fields the agent can read or write within each authorized tool. A customer-support agent authorized for a CRM should be scoped to the records owned by its current task — not the entire tenant's data, and not other tenants' data.
Identity
Each agent should have its own discrete identity — not a shared service account inherited from the deploying team. Microsoft's authorization framework and emerging Agent ID standards make this the prerequisite for any meaningful audit, attribution, or revocation.
Capabilities
The operational verbs the agent can exercise — read, draft, send, approve, write, delete, escalate. Capability-based access control, as in Google's CaMeL research, separates "the agent can talk to this tool" from "the agent can use this verb on this tool right now."
Default-deny tool permissioning is the foundational pattern
Default-deny means a new agent has zero tool permissions until each one is explicitly added, scoped, and approved. This sounds obvious and is overwhelmingly not what teams actually ship. The common pattern is to register the agent against a shared toolset inherited from the agent framework, with the assumption that the agent's reasoning will only invoke the tools it needs for the task at hand. That assumption fails the moment the agent is wrong, prompt-injected (see Chapter 5), or operating outside its tested behavior envelope. The fix is structural rather than behavioral: the policy engine, not the model, decides which tools are reachable for each agent persona.
Operationally, default-deny is implemented as an allowlist per agent persona, with each tool entry naming the operation, the data scope, and the conditions under which the operation is permitted. The runtime then refuses any tool call that doesn't match an allowlist entry — including tool calls the model attempts to make for tools it was never registered against.
Per-agent identity, not shared service accounts
When ten agents share one service account, every action they take is attributed to that account, every policy decision is made about that account's privileges, and any compromise of any one agent compromises the privileges of all ten. The OWASP Agentic Top 10 catalogues this as ASI03 (Identity and Privilege Abuse) and identifies shared identity as one of the highest-frequency root causes in observed agentic incidents. Microsoft Entra's agent identity model, SPIFFE/SPIRE workload identity, and Google Cloud's per-workload service account guidance all converge on the same structural answer: each agent gets its own short-lived, automatically-rotated identity, with permissions attached to that identity rather than to a shared parent.
The practical implication for an agentic deployment is that the identity provisioning step happens automatically as part of agent instantiation, not as a manual ticket to the security team. If a developer can spin up an agent without it getting its own identity, the identity model has already failed.
"The default outcome, absent deliberate design, is the agentic equivalent of a service account with sysadmin-equivalent reach."
Working through these controls yourself? The Skyrelis Agent Checklist condenses this series into a one-page pre-production reference.
Download Free →Just-in-time and ephemeral permissions
Persistent broad permissions are the worst case. A better model is just-in-time permission granting: the agent requests the specific capability it needs for the current task, the policy engine evaluates the request against the agent's persona and the task context, and a time-bounded, single-use or low-count token is issued. When the task completes or the token expires, the capability is gone. This is the agentic translation of the same JIT and PAM patterns long established for human privileged access.
| Capability Tier | Default Grant | Elevation Path |
|---|---|---|
| Routine | Read-only lookups within the agent's data scope; draft generation; summarization | Granted at agent instantiation, bound to the agent's identity and persona |
| Elevated | Creating records, modifying non-critical data, sending internal communications | JIT token issued per task, time-bounded (minutes), revoked at task completion or expiration |
| Privileged | Privileged operations, financial actions, infrastructure changes, external API writes, schema or permission changes | Explicit human approval required; capability token issued only after approval, single-use, with full audit context |
The tier structure mirrors the human-oversight tiering described in our guardrails piece for a reason: the same risk axis that determines whether a human needs to approve an action also determines whether the agent should be holding the capability at all in its default state.
Policy engines as the enforcement layer
Least privilege is only meaningful if it is enforced — not declared. The enforcement layer is a policy decision point that evaluates each proposed action against the active policy for the current agent, returns an authorization outcome, and logs the decision. Open Policy Agent (OPA), Cedar, and the Microsoft Agent Runtime Controller are all examples of this pattern. Each evaluates a request that names the agent identity, the proposed action, the target resource, and the context, and returns one of: allow, allow with redaction, require human review, deny.
The policy engine pattern is what makes least privilege concrete rather than aspirational. Without it, "the agent only does what its permissions allow" is a claim about what the model will choose, not a guarantee about what the system will permit.
Standards alignment: NIST, CSA, EU AI Act
A least-privilege architecture for AI agents is not just a security best practice — it is increasingly a compliance expectation. The NIST AI Risk Management Framework's Govern and Manage functions both require demonstrable, scoped control over what autonomous systems are permitted to do. The EU AI Act, with high-risk obligations fully in force August 2026, requires that autonomous systems operate within actively enforced boundaries — which is exactly what default-deny scoping plus runtime policy enforcement produces.
Pre-Production Least-Privilege Checklist
Frequently Asked Questions
Existing IAM systems were designed around two assumptions agents break: identity is established at session start and held for the duration, and the set of resources a principal accesses is roughly knowable from role membership. Agents reason dynamically about what to do next, fan out across tools added by many different developers, and frequently inherit identity from whichever service account spun them up. The result is that IAM at the session-start layer authorizes the agent for everything its parent account can reach. The fix is layering a per-agent identity above the parent account and enforcing a policy decision at every tool call.
Scope control answers "which tools can this agent reach?" Capability-based access control answers "what verbs can this agent exercise on this tool, under what conditions, right now?" Scope is the coarser, foundational layer — an allowlist of tools, often persistent for the lifetime of the agent persona. Capabilities are the finer layer, typically issued as time-bounded tokens for specific tasks and revoked at completion.
Prompt injection is a content-side attack — the attacker manipulates what the model wants to do. Least privilege is the action-side defense — even when the model is hijacked into wanting to do something harmful, the policy engine refuses the action because the agent does not hold the capability required to execute it. The two controls compose: see our prompt injection chapter for the content side.
It satisfies most of the substantive control requirements those frameworks impose on autonomous systems. The EU AI Act's high-risk obligations require demonstrating that the system operates within actively enforced boundaries — which is exactly what default-deny scoping plus runtime policy enforcement produces. The NIST AI RMF's Govern and Manage functions both require demonstrable, granular control, and the Measure function requires the audit trail that runtime policy decisions naturally produce (covered in our audit and monitoring chapter).
See how Skyrelis enforces least privilege at runtime
Per-agent identity, default-deny tool scoping, and JIT capability grants — enforced by the runtime, not the model.