Agent Permissions and Least Privilege: The New Zero-Trust for AI Systems

The Permissions Problem

In 2024, the lazy way to give an agent access to a system was to hand it a long-lived API key with broad scopes. By 2026 this is the dominant root cause of agent-driven security incidents. Agents that get prompt-injected, jailbroken, or simply confused use the broad credentials to do real damage.

Zero-trust principles applied to agents close most of this gap. This piece walks through the patterns that work.

Three Failure Modes the Pattern Closes

flowchart TB
    F1[Confused-deputy:<br/>agent acts on attacker's behalf<br/>with user's privileges] --> Fix1[Per-call user attribution]
    F2[Lateral movement:<br/>agent uses one credential<br/>to access broader scope] --> Fix2[Least-privilege scoping]
    F3[Persistent compromise:<br/>credential exfiltration<br/>survives the session] --> Fix3[Short-lived JIT tokens]

The Five Patterns

1. Per-User Token Scoping

Every tool call carries a token scoped to the specific user the agent is working for. The token cannot read other users' data even if the agent is tricked into asking. Implemented at the MCP server (or whatever tool API) — not at the agent.

2. Just-in-Time Access

The agent does not hold long-lived credentials. When it needs to call a tool, it requests a short-lived token from a credential broker. The token expires quickly (minutes to an hour). Compromise of the agent does not give long-term access.

3. Capability-Based Permissions

Instead of "read-write to the database," the agent gets specific capabilities: "read-customer-record-by-id," "schedule-appointment-for-current-user," etc. Each capability is a narrow grant. Even if all capabilities are compromised, the attacker has only the union of what was granted.

4. Two-Person Rules for High-Stakes Actions

Sensitive actions (export data, delete records, send money, change permissions) require explicit human confirmation through a non-LLM channel. The agent proposes; a human commits.

5. Comprehensive Audit

Every tool call, every credential exchange, every elevation attempt is logged with user, agent, action, parameters, and result. Logs are tamper-evident and reviewed.

A Reference Architecture

flowchart LR
    User[User auth] --> Agent[Agent]
    Agent --> Broker[Credential Broker:<br/>STS / OAuth on-behalf-of]
    Broker -->|short-lived token<br/>scoped to user + capability| Tool[Tool / MCP Server]
    Tool --> Resource[Backend Resource]
    Tool --> Audit[(Audit Log)]
    Agent --> Audit

The broker is the chokepoint. Every credential the agent uses comes from the broker; every credential carries scope and audience claims; every issuance is logged.

OAuth 2.1 Patterns That Apply

The 2026 OAuth 2.1 toolkit maps cleanly to agent permissions:

• PKCE: prevents code interception during token exchange
• DPoP (Demonstrating Proof of Possession): binds tokens to keys, prevents stolen-token replay
• Token Binding: ties tokens to TLS sessions where possible
• On-behalf-of flow: agent acquires a downstream token authorized for the original user
• Step-up authentication: high-stakes actions trigger fresh user authentication

MCP and A2A both adopt OAuth 2.1 with PKCE as the standard.

Tool Server Implementation

For each tool/MCP server in your agent stack:

flowchart LR
    Req[Tool Call] --> A[Auth: validate token]
    A --> S[Scope check:<br/>does token cover this op?]
    S --> U[User check:<br/>can this user do this?]
    U --> R[Rate limit + quota]
    R --> Exec[Execute]
    Exec --> Aud[Audit log]

The four checks are separate and explicit. Skipping any one of them is the typical security incident.

Hard Cases

Three patterns that need extra thought:

• Multi-user agents: an agent operating across users (a help-desk routing bot) must propagate the right user identity per call. This is where confused-deputy attacks land.
• Background agents: long-running agents without an active user session need service-account-style identity, scoped extremely narrowly.
• Cross-organization workflows: an agent invoking a partner's A2A endpoint needs federated identity; the partner trusts your IdP claims about the user.

Real-World Application

For CallSphere's voice agents talking to provider databases:

• Each call has a session token tied to the verified caller (via voice biometrics or KBA fallback)
• Tool calls to the medical-records API include the patient's identity in the request, validated server-side
• Tools cannot return data for any other patient even if asked
• High-stakes actions (cancellation, prescription request) require provider confirmation through a separate, non-voice channel

This pattern has been audited by HIPAA-aware security teams and held up.

What's Next

Two patterns are emerging in late 2026:

• Capability negotiation in the protocol layer: MCP and A2A extensions that negotiate fine-grained capabilities at session start
• Agent identity attestation: the agent itself has a verifiable identity (a signed "agent card" with attestations about how it was built); tools can decide what to grant based on the agent's properties, not just the user's

Both are on standards-track and likely to be production-ready in 2027.

Sources

• OAuth 2.1 specification — https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1
• OWASP LLM Top 10 — https://owasp.org/www-project-top-10-for-large-language-model-applications
• "Capability-based security" — https://www.erights.org
• Anthropic on agent permissions — https://www.anthropic.com/research
• "Confused deputy" original — https://en.wikipedia.org/wiki/Confused_deputy_problem