Least Privilege for AI Agents: Zero Trust Extended

Autonomous systems break the assumptions your access model was built on. Here is how to bound them.

The identity your access model was never designed for

Autonomous software now takes actions your access control model never anticipated. An AI agent reads a ticket, queries a database, calls three APIs, and writes to a repository — all in seconds, under one credential, with no human in the approval path.

Least privilege was designed for two identity types: humans who log in and services that run fixed code. AI agents are neither. They hold standing credentials like a service, but their behavior is non-deterministic like a human — and often broader than either.

That gap matters at scale. Analysts at Gartner expect more than 40% of agentic AI projects to be scrapped by 2027, citing escalating costs, unclear business value, and inadequate risk controls. When you cannot state what an AI agent is allowed to do, you cannot ship it safely. Zero trust gives you the frame; the work is applying it to identities that decide their own next move.

What does least privilege mean for AI agents?

Least privilege for AI agents means granting each agentic AI identity only the specific, time-bound permissions its current task requires — and revoking them when the task ends. It is not one broad service account shared across every workflow. It is per-task, per-tool authorization enforced at the point of action, not assumed at design time.

The distinction from traditional least privilege is behavioral. A microservice does the same thing every run, so you can scope it once. An AI agent composes new action sequences from a toolset, so its effective privilege is the union of everything its tools can reach.

That union is the real attack surface. If an AI agent can call a tool that queries any customer record, its privilege is "all customer records" — regardless of what any single prompt intended. Scope the tools, not just the identity.

• Bind permissions to a task context, not a long-lived key
• Scope each tool the AI agent can invoke to the narrowest resource set
• Expire authorization when the task completes
• Log the granted scope alongside every action for later review

Why zero trust already answers the hard question

Zero trust does not ask whether a request comes from inside the network. It asks who is making the request, what they are trying to do, and whether that specific action is authorized right now. That model transfers directly to AI agents — the identity is machine, but the evaluation is the same.

The core principle is documented in NIST SP 800-207: never trust, always verify, and enforce per-request. An AI agent making a thousand calls an hour is a thousand verification events, each evaluated against policy, not one login that opens the door.

We have argued before that zero trust tells you who, not whether — identity is the input, authorization is the decision. For AI agents the decision has to fire on every tool call, because the agent chooses its own path and you cannot predict the sequence in advance.

This is where many teams stall. They authenticate the AI agent once, then let it act freely. That is authentication without authorization — the exact failure zero trust exists to prevent.

The delegation problem: whose privilege is the AI agent using?

When an AI agent acts on a user's behalf, whose permissions apply? This is the confused-deputy problem, and agentic AI makes it acute. An AI agent invoked by a low-privilege user can call tools running under a high-privilege service identity — and quietly perform actions the user could never authorize directly.

The OWASP Top 10 for LLM Applications 2025 edition lists Excessive Agency (LLM06) and Improper Output Handling (LLM05) among its top risks precisely because delegation boundaries blur. The AI agent becomes a privilege-escalation path if its authorization is not tied back to the requesting principal.

Getting delegation right means the effective privilege of any action is the intersection of the AI agent's scope and the invoking user's rights — never the union. If a user cannot read a record, no AI agent acting for them should read it either.

This is fundamentally a trust decision, and we break down its mechanics in the anatomy of a trust decision. The inputs — identity, context, requested action, current state — are the same whether the requester is a person or an autonomous process. What changes is frequency and the need to resolve delegation on every call.

Enforcement has to be runtime, not design-time

A permission scoped correctly at design time tells you nothing about what an AI agent did at 2 a.m. Tuesday. Autonomous systems drift: tools get added, prompts change, and a scope that was tight last week may be over-broad against this week's data. We have made this case directly — right at design time, wrong by Tuesday.

Static policy review cannot keep pace with identities that generate their own workload. The 2025 Verizon Data Breach Investigations Report found credential abuse was the most common way into a breach, at 22% — and an AI agent holding a standing, over-broad credential is exactly that kind of target.

Runtime enforcement closes the gap. Every tool call is evaluated against live policy, the granted scope is recorded, and out-of-scope attempts are denied and logged. This is the continuous, observed, enforced posture: authorization is not a gate you pass once but a check that fires on each action.

The practical payoff is evidence. When enforcement is continuous, your audit trail is a byproduct of operation rather than a scramble — compliance evidence, not a fire drill.

A reference model for bounding AI agents

Bounding an AI agent is not a single control — it is a layered model where each layer assumes the one before it can fail. Security architects should be able to state, for any agentic AI identity, exactly what it can touch and prove it at runtime.

• Distinct identity per agent. No shared service accounts. Each AI agent gets its own credential so actions are attributable and revocable independently.
• Tool-level scoping. Constrain each tool to the narrowest resource set — a specific dataset, a single API path, a read-only view. The AI agent's privilege is the sum of its tools, so this is where over-privilege hides.
• Delegated authorization. Resolve effective privilege as the intersection of AI agent scope and invoking principal, evaluated per call.
• Time and task binding. Issue short-lived credentials scoped to the active task; expire them when it completes.
• Runtime policy evaluation. Check every action against live policy; deny and log anything outside scope.
• Full action logging. Record the identity, the granted scope, the requested action, and the decision — for every call.

This structure sits inside a broader infrastructure trust framework we describe in the Augustine infrastructure trust framework, where trust is assembled from observed facts rather than assumed at onboarding. The point is not to trust the AI agent more, but to need to trust it less — because each action is independently verifiable.

The takeaway

Least privilege for AI agents is the same discipline you already practice, applied to identities that choose their own actions. The rules do not change — the enforcement point does.

• Give every AI agent a distinct, revocable identity — never a shared account.
• Scope tools, not just credentials; an AI agent's real privilege is the union of what its tools can reach.
• Resolve delegation as the intersection of AI agent scope and invoking user rights.
• Enforce at runtime on every call, because design-time scope goes stale fast.
• Log the granted scope with every action so your audit trail writes itself.

Zero trust already answers the hard question of who and whether. Agentic AI just raises the frequency. Build the enforcement point to match.

Next: see how identity and context resolve into one decision in the anatomy of a trust decision.