Securing Agentic Systems with Authenticated Delegation - Part I

As AI agents advance in autonomy and capability, particularly with the development of large language models (LLMs), they introduce new challenges in identity and access management (IAM). Unlike traditional applications with predictable behaviors, modern AI agents can reason, plan, use tools, and access resources on behalf of users with minimal supervision. This shift in behavior raises significant security questions: How do we ensure these agents act only within their intended scope? How do we maintain proper accountability? How do we prevent them from breaching trust boundaries?
This transition fundamentally disrupts traditional IAM models built around predictable applications and direct user control. Relying on existing approaches such as static API keys or simple application permissions for these autonomous agents is problematic because it opens doors to sophisticated confused deputy attacks, privilege escalation, and untraceable actions with potentially severe consequences. A new foundation based on verifiable delegation will be essential, not optional, for navigating this future securely.

The concept of authenticated delegation provides a framework for addressing these issues. As outlined in the MIT research paper “Authenticated Delegation and Authorized AI Agents,” this approach enables human users to securely delegate and restrict the permissions and scope of agents while maintaining clear chains of accountability. This foundation becomes crucial when considering the extensive threat landscape described in OWASP' s “Agentic AI - Threats and Mitigations” document, which identifies numerous IAM- specific vulnerabilities in agentic systems.
This paper, the first of five on IAM Security for Agentic Systems, explores how authenticated delegation addresses critical IAM security challenges in AI agent deployments by creating verifiable chains of authority from human principals to agents, establishing explicit scope limitations, and enabling auditability across autonomous operations.

Understanding Authenticated Delegation for AI Agents

Authenticated delegation establishes a secure foundation for AI agency through three essential pillars:

1. Authentication confirms an entity’s identity, verifying both the human user initiating the action and that the interacting entity is a specific AI agent with defined properties.
2. Authorization determines permissible actions and resource access, ensuring the AI agent acts on behalf of a specific, authenticated human user with explicitly delegated permissions for a defined scope.
3. Auditability enables all parties to inspect and verify that claims, credentials, and attributes (related to the user, the agent, and the delegation itself) remain unaltered and that actions can be traced back to their origin. ​ These three pillars work together to create a comprehensive security framework specifically adapted to the unique challenges of Agentic AI systems.

Practical Implementation

Rather than creating entirely new infrastructure, authenticated delegation extends established protocols—particularly OAuth 2.0 and OpenID Connect—to address the unique requirements of AI agents. While leveraging familiar flows, it introduces crucial agent-specific identity and delegation constructs. The practical implementation uses a token-based framework often consisting of three conceptual components:

1. User’s ID-token: A standard OpenID Connect token issued by an OpenID Provider (IdP), representing the human user’s authenticated identity claims. This is unchanged from standard OIDC flows.

2. Agent-ID token: This token contains relevant, verifiable information about the specific AI agent instance, such as its capabilities, limitations, vendor origin, documentation links, and unique identifiers. Crucially, this provides a distinct, verifiable identity for the agent itself, separate from the user. This token might be issued by the agent's vendor, registered during deployment within an organization's IAM system, or derived from other verifiable credentials.
   The key requirement is that it allows services to reliably identify this agent and trust claims about its properties. Managing the lifecycle and registration of these agent identities is a critical operational aspect, presenting challenges similar to, yet distinct from traditional application client management. Establishing trusted sources for Agent-IDs, ensuring their secure issuance, and handling updates or revocations are essential considerations for a robust implementation.

   The lifecycle management requirement introduces operational complexity. An organization supporting this token must design robust processes for issuing, updating, revoking, and rotating Agent-ID tokens, similar to application client secrets, but with richer metadata and shorter lifespans. Policies must define what constitutes a "trusted agent," which vendors are allowed, and what happens if an agent's trust posture changes or is compromised. Integration with existing workload identity systems and PKI infrastructure can help, but dedicated processes for AI agent trust management will emerge as a new IAM responsibility.

3. Delegation Token: This is the core extension that explicitly authorizes a specific AI agent (identified by its Agent-ID) to act on a specific user’s behalf (identified by the User ID), but only for a specific, approved scope and duration. This token acts as the essential cryptographic bridge, containing verifiable references (e.g., hashes or identifiers) to both the User's ID-token claims and the Agent-ID token claims, alongside the defined scope (e.g., "read:calendar", "send:email"), validity conditions, and potentially audit URLs. Unlike a standard OAuth access token, which primarily represents the user's permission granted to the client application allowing it to access resources, the Delegation Token explicitly binds the User, the Agent, and the Scope into a single, verifiable artifact. This explicit, bound delegation is fundamental to mitigating confused deputy attacks and ensuring clear accountability, as the token itself carries proof of the specific delegation act.

This conceptual three-token architecture (useful for clearly separating the distinct identity and authorization elements involved, even though implementations might combine claims into fewer physical tokens for efficiency) creates a robust, cryptographically verifiable chain of trust from the human principal to the agent's actions. Any service interacting with the agent can validate this entire chain—confirming the user's identity, the agent's identity and properties, and the specific delegated permissions defined in the delegation token—before granting access.

To make this more concrete, the following diagram shows how the user, agent, and authorization server interact to produce a verifiable delegation token. Note: this is a simplified view meant to illustrate the essential components and their relationships.

@startuml
title Authenticated Delegation Token Issuance Flow (Simplified View)

actor User as U
participant "AI Agent" as A
participant "Auth & Delegation Server\n(OAuth Provider + Extensions)" as ADS
participant "Resource Server" as RS

U -> A: Request Agent to perform task requiring specific permissions
A -> ADS: Initiate Delegation Flow (indicates required scope, presents Agent ID/Credentials)
ADS -> U: Redirect User for Authentication & Consent\n(Shows User who Agent is and what scope is requested)

U -> ADS: Authenticates (proves identity)
U -> ADS: Grants Consent (approves requested scope for this Agent)

ADS -> ADS: Verify User, Agent ID/Credentials, and Consent
ADS --> A: Issue **Delegation Token** (or derived Access Token representing the delegation)
note right of A: Agent now holds a specific, verifiable token\nrepresenting delegated authority from User.

' Optional: Subsequent Action Phase (Simplified)
A -> RS: Perform Action (Presents Token)
RS -> RS: Verify Token & Enforce Scope\n(Checks token validity, signature, and ensures\n action is within the approved scope for this User/Agent pair\n as defined *by the delegation*)
RS --> A: Action Result (Success/Failure)

@enduml

1. The user invokes an AI agent to perform a task.
2. The agent, identifying itself, initiates an OAuth-like flow requesting specific scoped access (e.g. "documents.read") from the Authorization and Delegation Server.
3. The user authenticates and explicitly approves this delegation request, granting the agent permission for that specific scope.
4. The agent receives a Delegation Token (or an access token derived from it) representing this specific, scoped grant.
5. The agent uses this token to access the requested resources on behalf of the user, with the resource server verifying the token and enforcing its embedded scope.

Note that the full authenticated delegation framework, particularly the distinct User, Agent, and Delegation tokens/claims, adds critical agent-specific security layers which we will discuss later in the series. Regardless, even this conceptual extension of OAuth offers several advantages:

• Token-based security: Agents receive limited scope tokens specifically representing the delegation rather than handling raw user credentials.
• Explicit consent: Users actively approve the delegation of specific permissions to a specific agent.
• Fine-grained control: Permissions can be scoped to specific resources and actions within the delegation grant.
• Revocability: Delegated access can be terminated by revoking the delegation token or underlying session. Because authenticated delegation by principle builds on established standards, it provides a practical pathway for securing AI agents within existing IAM ecosystems.

Agentic AI Threat Landscape Through an IAM Lens

The OWASP Agentic Security Initiative (ASI) has identified numerous threats unique to Agentic AI systems that all organizations must address. Understanding these threats is essential for implementing effective security measures.

Confused Deputy Vulnerabilities: A Core IAM Risk

The most significant IAM threat in Agentic systems is the Confused Deputy vulnerability (related to OWASP ASI T3 - Privilege Compromise and T7 - Misaligned & Deceptive Behaviors). This occurs "when an AI agent (the 'deputy') has higher privileges than the user but is tricked into performing unauthorized actions on the users behalf". This vulnerability materializes when an agent lacks proper privilege isolation and cannot distinguish between legitimate user requests and adversarial injected instructions.

For example, if an AI agent has access to database operations with elevated privileges but doesn’t properly validate user input, an attacker could manipulate it into executing high-privilege queries that the attacker themselves couldn’t directly perform. The OWASP document emphasizes that “to mitigate this, it is essential to down scope agent privileges when operating on behalf of the user”.

Non-Human Identities Management

The management of Non-Human Identities (NHIs)—such as machine accounts, service identities, and agent-based API keys—presents another significant challenge. Unlike traditional user authentication flows, NHIs “may lack session-based oversight, increasing the risk of privilege misuse or token abuse if not carefully managed” (contributing to risks like T3 - Privilege Compromise and T9 - Identity Spoofing).

Agents operating under these non-human identities create unprecedented security risks because:

• They often have persistent, long-lived credentials
• They may operate outside of normal user sessions
• They can access multiple services and resources across trust boundaries
• They might lack clear accountability mechanisms linking actions to human principals

In practical engineering, deploying agent-based delegation will likely require system evolution in specific ways:

• Extend Identity Provider (IdP) or OAuth infrastructure to issue delegation tokens that bind both user and agent identities.
• Create or integrate a registry of trusted AI agent identities, capturing metadata like capabilities, provenance, trust level, and owner.
• Establish policies for agent identity verification and revocation (e.g., when a vendor is offboarded or an agent is compromised).
• Define secure mechanisms for agent authentication (e.g., mTLS, signed assertions, or Verifiable Credentials) during delegation flows.
• Update resource servers to parse and enforce delegation scopes from tokens — including constraints like purpose, context, or time.

Tools Misuse and Excessive Agency

One of the defining characteristics of modern AI agents is their ability to use tools and APIs to accomplish tasks. However, this capability creates significant security risks when agents have “unconstrained autonomy either in advanced planning strategies or multi-agent architectures” (related to OWASP ASI T2 - Tool Misuse and LLM06 - Excessive Agency).

The OWASP document notes that “tool misuse relates to LLM Top 10’s excessive agency but introduces new complexities,” particularly in the context of code generation where agents might create code with security vulnerabilities or even malicious capabilities.

Memory Poisoning and Context Violations

Another unique threat in agentic systems is memory poisoning (OWASP ASI T1 - Memory Poisoning), where the agent’s internal state or external memory storage is corrupted with misleading or malicious information. This is particularly concerning in multi-agent architectures “where agents learn from each other’s conversations”.

Memory poisoning can lead to context violations, where information from one context (e.g., enterprise data) inappropriately influences actions in another context (e.g., personal tasks), potentially leading to data leakage or unauthorized access.

Privilege Escalation

Furthermore, the potential for privilege escalation (OWASP ASI T3 - Privilege Compromise) presents a critical vulnerability, distinct from simple tool misuse within authorized bounds. This threat specifically concerns agents gaining permissions beyond their intended role or initial authorization level. As highlighted in the OWASP Agentic threat model, this can occur through exploiting mismanaged roles, overly permissive configurations, dynamic permission inheritance, or chaining tool accesses in unexpected ways. Unlike traditional systems where escalation paths might be more predictable, agent autonomy and their ability to interact across multiple services create novel pathways for escalating basic access (e.g., reading a file) into administrative control or unauthorized cross-system operations, exploiting the difficulty in enforcing strict, dynamic boundaries.

Identity Spoofing

Building on the challenges of NHI management, identity spoofing and Impersonation (OWASP ASI T9 - Identity Spoofing & Impersonation) emerge as another fundamental IAM threat taking on unique dimensions. Attackers may exploit authentication mechanisms or compromised credentials (human or non-human) to impersonate legitimate AI agents, human users, or even external services. The OWASP ASI highlights this risk, noting attackers can enable unauthorized actions under false identities. This is particularly dangerous in multi-agent environments where trust assumptions are prevalent. A malicious entity could masquerade as a trusted agent to intercept communications, manipulate other agents, exfiltrate data, or perform unauthorized actions, bypassing security controls by operating under a stolen or forged identity.

How Authenticated Delegation Improves Agentic Security

Authenticated delegation directly addresses each of the IAM-specific threats identified in the OWASP Agentic AI threat model. The following tables demonstrate how specific mechanisms within the authenticated delegation framework counter these security risks.

Implementation Case Study: Financial Assistant Agent

To illustrate how authenticated delegation addresses agentic threats in practice, consider a financial assistant agent that helps users manage investments and make transactions. The following diagram illustrates this detailed flow, focusing specifically on how the User ID, Agent ID, and the crucial Delegation Token interact during the setup and action phases. Refer to the step-by-step explanation immediately following the diagram for a breakdown of each numbered interaction.

@startuml
title Financial Assistant Agent - Authenticated Delegation Flow (with Explicit Tokens)

actor User
participant "Financial AI Agent" as Agent
participant "Auth & Delegation Server\n(e.g., Bank's IDP)" as ADS
participant "Financial Service API\n(e.g., Bank's Resource API)" as FinAPI

autonumber "<b>[0]"

== 1. Delegation Setup Phase ==

User -> ADS: Initiates Login / Task Requiring Delegation
ADS -> User: Authentication Prompt
User -> ADS: Authenticates (e.g., username/password, MFA)
ADS -> ADS: Validate User Credentials
ADS --> User: Authentication Success \n(Conceptually issues/validates **User ID Token**)
note right of ADS: User authenticated;\nUser ID Token claims available

User -> Agent: "Transfer $50 to savings"
Agent -> ADS: Initiate Delegation Request\n(Presents **Agent ID Token** or Client Credentials,\nRequests Scope: transfer.internal, accounts.read)
note left of Agent: Agent identifies itself using its\npre-established Agent ID Token\nor other verifiable credentials.

ADS -> User: Redirect/Prompt for Consent\n(Shows: User, Agent Identity [from Agent ID],\nRequested Scope)
User -> ADS: Grants Consent for Requested Scope

ADS -> ADS: **Create Delegation Token**\n(Binds User ID Ref, Agent ID Ref, Scope,\nConstraints [e.g., MaxTransfer=$1000], Validity)
note right of ADS: **Delegation Token** created, linking\nUser, Agent, and specific permissions.

ADS --> Agent: Issue **Delegation Token**
note right of Agent: Agent now holds the specific Delegation Token\nauthorizing it for the consented scope.

== 2. Delegated Action Phase ==

Agent -> FinAPI: POST /transfers (Amount: $50, From: Checking, To: Savings)\n**Authorization: Bearer [DelegationToken]**
note left of Agent: Agent uses the **Delegation Token**\nto authorize the API call.

FinAPI -> FinAPI: **Verify Delegation Token, Identity Linkage & Scope**
note right of FinAPI
  1. Check Delegation Token Signature & Validity
  2. Extract/Verify User & Agent References within Token
  3. **Confirm Action (POST /transfers) matches Scope ([transfer.internal])**
  4. **Confirm Amount ($50) <= Constraint ($1000) from Token**
end note

alt Verification Successful
    FinAPI -> FinAPI: Execute Internal Transfer
    FinAPI --> Agent: Success (Transfer ID: 123)
    Agent --> User: "Successfully transferred $50 to savings."
else Verification Failed (e.g., Scope Violation, Constraint Breach, Invalid Token)
    FinAPI --> Agent: Error 403: Forbidden / Insufficient Scope
    Agent --> User: "Sorry, I couldn't complete the transfer due to permission issues."
end

@enduml

This diagram illustrates the authenticated delegation process for the Financial Assistant Agent scenario, highlighting the roles of different identity tokens:

Phase 1: Delegation Setup Phase

1. (Steps 0-1): User Authentication: The User initiates a login or a task requiring delegated permissions with the Authentication & Delegation Server (ADS), typically their bank's Identity Provider. After successful authentication (e.g., password, MFA), the ADS conceptually validates or has access to the claims within the User ID Token, verifying the user's identity.

2. (Steps 2-3): Task Initiation: The User instructs the AI Agent to perform a task (e.g., "Transfer $50").

3. (Step 4): Delegation Request: The Agent contacts the ADS to initiate the delegation flow. It identifies itself using its Agent ID Token (or equivalent verifiable credentials) and specifies the scope (permissions like transfer.internal, accounts.read) required for the task.

4. (Steps 5-6): User Consent: The ADS prompts the User for explicit consent, clearly showing which Agent is requesting access and the specific permissions (scope) being requested. The User reviews and grants consent.

5. (Step 7): Delegation Token Creation: The ADS, having validated the User (via User ID Token claims), the Agent (via Agent ID Token), and received User consent, creates the Delegation Token. This crucial token cryptographically binds references to the User's identity, the Agent's identity, the approved scope, and any additional constraints (like transaction limits or validity periods).

6. (Step 8): Token Issuance: The ADS issues the newly created Delegation Token to the AI Agent. The Agent now holds a specific, verifiable credential authorizing it to act on the User's behalf within the consented boundaries.

Phase 2: Delegated Action Phase

1. (Step 9): API Call with Delegation Token: The Agent makes the required API call to the Financial Service API (e.g., initiating the $50 transfer). It presents the Delegation Token in the Authorization header.

2. (Step 10): Verification by Resource Server: The Financial Service API receives the request and performs rigorous verification on the Delegation Token:

   • Checks the token's signature and validity (e.g., expiration).
   • Extracts and verifies the linked User and Agent identities within the token.
   • Crucially, confirms that the requested action (POST /transfers) is permitted by the scope defined in the token (e.g., transfer.internal).
   • Additionally, confirms that request parameters (Amount: $50) adhere to any constraints defined in the token (e.g., <= $1000 limit).

3. (Steps 11-15): Action Execution (Conditional):

   • If verification succeeds: The Financial Service API executes the requested action (the transfer). It returns a success response to the Agent, which then informs the User.
   • If verification fails (due to invalid token, insufficient scope, or constraint violation): The Financial Service API rejects the request (e.g., with a 403 Forbidden error). It returns an error response to the Agent, which then informs the User about the failure.

This flow demonstrates how the Delegation Token acts as the central element, enabling the Agent to securely perform actions based on verified User identity and explicit consent, while allowing the Resource Server (Financial API) to strictly enforce the delegated boundaries.

Here’s how the security posture differs drastically with and without authenticated delegation:

Conclusion: The Imperative of Authenticated Delegation

AI agents will become increasingly integrated into critical systems. Authenticated delegation emerges is an essential security foundation that addresses the core IAM challenges identified in the OWASP agentic threat model—including confused deputy vulnerabilities, non-human identity management, tools misuse, and memory poisoning. This framework enables organizations to safely deploy AI agents while maintaining appropriate security boundaries and accountability.

The concept of authenticated delegation fulfills a critical need in agentic security by extending existing standards like OAuth 2.0 and OpenID Connect with agent-specific mechanisms. It creates verifiable chains of authority from human principals to AI agents, with explicit scope limitations and accountability measures that directly counter the unique security threats these systems present.

For organizations developing or deploying AI agents, implementing authenticated delegation should be considered a foundational security requirement rather than an optional enhancement. As the OWASP ASI notes, “IAM security challenges” including “violation of intended trust boundaries” represent some of the most critical risks in agentic environments. Authenticated delegation provides a comprehensive, standards-based approach to addressing these challenges. While strong Workload Identity (covered later in this series) is essential for establishing a verifiable identity for the agent, it does not convey who authorized a particular action, why, or under what scope. Workload Identity alone lacks the necessary linkage between a specific human user, the agent acting on their behalf, and the fine-grained, time-bound permissions that apply to a particular task. Authenticated Delegation fills this critical gap by cryptographically binding all three into a verifiable chain of trust. Similarly, while robust API security is critical, it lacks the mechanism to bind agent actions back to the original delegating user and their consented scope. Authenticated Delegation provides this crucial missing link.

In the next paper in this series, we will explore practical implementation patterns for authenticated delegation across different agentic architectures, demonstrating how organizations can adapt this framework to various deployment scenarios while maintaining security and accountability.

References

• Authenticated Delegation South, T., Marro, S., Hardjono, T., et al. "Authenticated Delegation and Authorized AI Agents".

• OWASP ASI OWASP Agentic Security Initiative. "Agentic AI - Threats and Mitigations", Version 1.0.