Securing autonomous AI agents: Applying Zero Trust to transform confused deputies into trusted actors

Autonomous AI agents are reshaping modern application architectures. These agents act on behalf of users, invoke APIs, access protected resources, and coordinate actions across trust boundaries. Unlike traditional applications or microservices, AI agents make real-time decisions with limited human supervision. This evolution challenges existing security and identity models, which were designed for interactive human users or long-lived service accounts.

In OAuth 2.0 and OpenID Connect (OIDC) ecosystems, security relies on strong identity, explicit delegation, and scoped authorization. However, current deployments treat non-human actors as static clients with coarse-grained permissions, often using long-lived credentials and broad access scopes. When applied to autonomous AI agents, this pattern introduces substantial risk. It violates core Zero Trust assumptions, which are minimizing implicit trust, enforcing least privilege, and applying continuous, context-aware validation. It also increases exposure to the confused deputy problem, where an AI agent acting with delegated authority is unintentionally induced to perform actions beyond the original intent of the delegating party.

To align with modern security best practices, AI agents must be treated as first-class security principals within OAuth 2.0–based authorization systems. In such an architecture, AI agents need to:

• Be assigned a verifiable cryptographic identity anchored in asymmetric key material
• Authenticate using proof-of-possession mechanisms, enabling relying parties to validate not only token claims but also the agent’s control over its private key. This provides stronger guarantees than bearer-token–only models.

Building on this identity foundation, the architecture must also ensure delegation through fine-grained, purpose-bound access tokens. Leveraging Rich Authorization Requests (RAR), the delegating user or system can explicitly define the resources, actions, and constraints under which an agent may operate. The resulting OAuth access tokens enforce least privilege access, ensuring that an agent’s authority is limited in scope, duration, and intent. This approach closely mirrors Zero Trust principles, where access is continuously evaluated and never assumed based on circumstances such as network location or actor type.

Beyond this foundation, agent security can evolve toward more adaptive and resilient architectures. First, adaptive access control can be achieved by combining OAuth-based authorization with attribute-based access control (ABAC) and policy decision engines. In this model, authorization decisions incorporate agent attributes, user context, environmental signals, and real-time risk indicators, enabling dynamic enforcement beyond static scopes. Second, agent identity lifecycle management and governance must be addressed, including automated onboarding, policy-driven delegation, short-lived credentials, and dynamic key and secret rotation. These capabilities are essential for maintaining compliance, minimizing blast radius in the event of compromise, and enabling rapid revocation in highly autonomous environments.

By aligning AI agent security with OAuth 2.0, OIDC, and Zero Trust architectures, established identity and authorization standards can be extended (rather than replaced) to securely support autonomous AI agents.

Understanding the confused deputy problem

The confused deputy problem occurs when a privileged entity (the "deputy") is induced to perform an action using its own authority on behalf of another actor, without correctly enforcing the actor's permissions.

This problem typically occurs when:

• The deputy has broad or elevated authority
• The requester has limited or different permissions
• The deputy cannot reliably determine both "who" is making the request and "under which authority" the action should be executed
• The deputy performs the action using its own privileges rather than constraining execution to the requester's rights

A classic example is a service that has access to a protected resource and is tricked into accessing it on behalf of a user who would not normally be authorized to do so.

Why AI agents are high-risk confused deputies

AI agents are particularly prone to becoming confused deputies because of how they operate in modern architectures (as described in this blog, Before you build agentic AI, understand the confused deputy problem).

AI agents:

• Act autonomously with limited or delayed human oversight
• Interact with multiple APIs and services across boundaries
• Often rely on persistent credentials or long-lived tokens
• Execute tasks on behalf of different users or systems over time

Without proper controls, this agentic architecture creates several failure modes, such as:

• Reusing broad credentials across unrelated tasks or users
• Mixing user intent or context between requests
• Executing actions outside the original delegation scope
• Being induced maliciously by a prompt injection, or accidentally to perform actions with excessive privilege

In essence, an AI agent that lacks scoped, context-aware delegation and strong identity binding behaves like a classic confused deputy: it has authority, but cannot reliably apply it to the correct principal or intent.

How to apply Zero Trust principles and mitigate the confused deputy problem

The confused deputy problem can be addressed by separating user identity, agent identity, and resource authority so that the agent never acts with broad and reusable privileges. The key protection is that the AI agent never holds long-lived, high-privilege credentials. Instead, each action is backed by a validated on-behalf-of (OBO) token and a short-lived, purpose-bound credential issued only after policy checks.

The following architecture diagram shows how you can use IBM Verify, IBM watsonx Orchestrate, and HashiCorp Vault to mitigate the confused deputy problem.

This architecture applies Zero Trust principles and prevents confusion because:

1. The user is authenticated against IBM Verify, so that the system knows exactly who initiated the request.
2. The AI agent, running in IBM watsonx Orchestrate, performs a token exchange against IBM Verify to obtain an OBO token tied to that user context rather than using a shared service account.
3. When the AI agent uses a tool in the MCP server, the MCP server validates the OBO token against IBM Verify before requesting access to the resource.
4. MCP server authenticates against HashiCorp Vault and requests access to the resource. HashiCorp Vault validates token claims and permission scope, ensuring the action is authorized for the originating user and intent.
5. HashiCorp Vault issues a dynamic credential with a short time-to-live.
6. Tool in MCP server accesses the resource with the provided dynamic credential.
7. HashiCorp Vault automatically cleans the credential up, preventing its reuse and thus limiting blast radius.

This architecture provides auditable provenance and traceability because:

• The OBO token encodes the originating user, every resource access can be traced back to the original requester and the exact delegation event.
• The issuance and revocation of dynamic credentials are recorded, producing a clear chain of custody: user authentication > token exchange > token validation > credential provisioning > resource access > credential removal.

This architecture enables automated compliance checks and fine-grained auditing (who acted, when they acted, and for what purpose), which is essential for security investigations and regulatory requirements.

Why strong identity and explicit delegation matter

With IBM Verify, the architecture gains intelligent identity and access management required for Zero Trust. By using IBM Verify, the system can distinguish between a legitimate delegated request and a malicious coercion attempt, and it also keeps audit trails complete and unambiguous.

Why short-lived, purpose-bound credentials matter

HashiCorp Vault provisions short-lived, purpose-bound credentials. These are important because they ensure the AI agent cannot accumulate standing privileges across unrelated tasks or users and they restrict what the AI agent can do (scope), for how long (time-to-live) and under which conditions (policy), aligning with least privilege and Zero Trust principles. If a compromise occurs, the limited lifetime and narrow scope reduce any damage. Learn more in this blog, Native AI Agent Support in HashiCorp Vault.

Summary and next steps

The proposed architecture mitigates the confused deputy problem by binding authority to the originating user and request context, enforcing fine-grained, policy-checked delegation, and producing an auditable trail that shows who truly initiated each action.

Learn how to configure IBM watsonx Orchestrate, HashiCorp Vault, and IBM Verify to enable AI agents that by default act in a least-privileged and auditable way in the tutorial, "Secure AI agents with IBM watsonx Orchestrate, IBM Verify, and HashiCorp Vault".