Securing Agentic Systems with Authenticated Delegation - Part II

In the first part of this series, we explored the concept of authenticated delegation and its critical role in securing AI agents. As these systems become more autonomous, capable, and interconnected, they introduce new operational paradigms and security challenges. This second installment focuses on how AI agents operate within single-agent and multi-agent frameworks, the execution patterns that define their workflows, and the identity and access management (IAM) requirements these patterns entail.

Building on that foundation, this paper examines how the authenticated delegation model—with its distinct User ID, Agent ID, and Delegation Tokens—provides the necessary IAM controls for various agent operating patterns. We will analyze the specific requirements of single and multi-agent architectures and demonstrate how protocols such as the Model Context Protocol (MCP) can leverage authenticated delegation to securely connect agents, tools, and services, ensuring actions remain linked to a verifiable chain of user authority. Finally, we’ll explore how MCP aligns with enterprise security standards like OAuth 2.1 and discuss why workload identity principles are increasingly relevant for agentic systems.

Single-Agent Patterns: Understanding Services, Tools, Memory, and LLMs

Single-agent systems are the most straightforward implementation of agentic AI. These agents operate independently to complete tasks by reasoning about user input, leveraging external tools or services, and maintaining context through memory, all while operating under the authority granted by a human principal.

Key Components of Single-Agent Systems

1. Services: External APIs or platforms providing data or actions (e.g., Google Calendar API, CRM). Accessing these requires the agent to present proof of its delegated authority.
2. Tools: Functions or APIs extending agent capabilities (e.g., send email, query database). Securely invoking tools necessitates validating the agent's permission for that specific function derived from its delegation.
3. Memory: Mechanisms for maintaining context across interactions:
   • Short-term memory uses the language model’s context window to track recent exchanges.
   • Long-term memory: Stores information persistently (e.g., vector DBs). Accessing or updating persistent memory often requires authorization checks to prevent context violations or poisoning, potentially managed via context-specific Delegation Tokens.
4. LLMs (Large Language Models): The core reasoning engine. While the LLM itself doesn't typically hold credentials, its outputs might trigger actions requiring delegated authority

IAM Requirements for Single-Agent Systems** (via Authenticated Delegation)

From an IAM perspective, single-agent systems require robust controls, which authenticated delegation provides:

• Granular Authorization: Achieved by resource servers verifying the agent's presented Delegation Token. This token cryptographically links the specific authenticated user (via User ID reference) to the verified agent (via Agent ID reference) and explicitly defines the authorized actions or resources.

• Scoped Permissions: Enforced via the specific scope and constraints embedded within the Delegation Token. This token is issued only after user consent for that agent and scope, and the resource server must validate it before granting access.

• Audibility: Ensured by logging agent actions against the verifiable identifiers (User, Agent, Token IDs) bound within the Delegation Token, creating a clear, cryptographic chain of accountability from user intent to agent action.

Example Use Case: Imagine a customer support agent needing CRM access. Instead of broad access, the agent, upon user request, would initiate a flow with the CRM's Authentication & Delegation Server. The user authenticates (verifying their User ID) and consents to the agent (identified by its Agent ID) accessing specific CRM scopes (e.g., customer_record.read). The server then issues a Delegation Token containing these bindings and scope. The agent presents this Delegation Token to the CRM API, which verifies the token and its linkage and enforces the authorized scope (e.g., only allowing reads, not writes), preventing actions beyond the explicitly delegated permissions.

Multi-Agent Patterns: Collaboration at Scale

While single-agent systems are powerful, multi-agent systems enable collaboration among specialized agents, demanding sophisticated management of delegated authority across workflows.

Execution Patterns in Multi-Agent Systems

Chaining

• Tasks are broken into sequential steps, where each step informs the next.
  • For example:
    • Step 1: Extract user intent.
    • Step 2: Query a database.
    • Step 3: Generate a response.
  • IAM Implications: Requires mechanisms for securely propagating or re-validating the original user's delegated authority across sequential steps. A key challenge is determining how Agent B obtains its authorization: does it receive a new Delegation Token authorized by Agent A (acting under the user's initial delegation, requiring careful validation of this chained authority), or must Agent B initiate a flow to obtain its own Delegation Token directly linked to the user? Maintaining the original User ID provenance and ensuring scope reduction (least privilege) throughout the chain are critical security concerns. The core challenge lies in preserving the integrity and intended scope limitations of the initial user delegation as the authority is potentially transferred or re-asserted across agent boundaries, necessitating secure mechanisms for token propagation, transformation, or re-validation against the originating user context. The complexities of managing this token lifecycle securely, especially ensuring traceability and preventing privilege escalation in chained flows, share similarities with challenges in workload identity propagation, a topic we will explore further in this series.

Routing

• Input is dynamically routed to the most appropriate agent based on classification.
  • For example:
  • A customer query about billing is routed to a finance-specific agent.
• IAM Implications: The router must verify the initial Delegation Token's broad intent. It might then direct the initiating agent/user to acquire a new, more narrowly scoped Delegation Token specifically for the specialist agent and task it's being routed to, ensuring least privilege. Routing decisions impacting authority must be auditable via token chains.

Parallelism

• Multiple tasks are executed simultaneously to reduce latency.
• For example:
  • An agent retrieves data from multiple APIs in parallel before synthesizing a response.
• IAM Implications: Each parallel agent or task might require its own specific Delegation Token, possibly derived from a master user consent or initial delegation, to prevent cross-task scope creep and ensure actions remain tied to the correct sub-task authority. Secure handling is needed to prevent Delegation Token theft or misuse between parallel processes.

Orchestration

• An orchestrator coordinates multiple agents or tasks dynamically.
• For example:
  • A code generation system orchestrates agents specializing in syntax validation, testing, and deployment.
• IAM Implications: The orchestrator potentially acts as a trusted intermediary, managing the lifecycle of Delegation Tokens for sub-agents based on the overarching user delegation. Designing this orchestration securely is complex: it must ensure sub-agents receive only necessary, time-bound permissions traceable back to the original User ID and Agent ID of the orchestrator (or potentially the initial user), maintaining the principle of least privilege derived from the initial delegation, and without becoming a single point of compromise or creating overly complex delegation chains. Secure patterns for delegated token issuance and management in orchestrated workflows will be discussed later, drawing parallels with established practices like workload identity federation.

Model Context Protocol (MCP): Connecting Agents and Services Securely

The Model Context Protocol (MCP) provides a standardized framework, representing an important specification still evolving within the community for securely connecting AI agents to tools, services, and data sources. It is a “universal adapter” that simplifies how agents interact with external resources while maintaining robust security controls. It also acts as a potential implementation layer for parts of the authenticated delegation flow.

When viewed through the lens of authenticated delegation, key MCP features must operate under specific security constraints:

1. Context Sharing: MCP facilitates sharing necessary context with agents. However, this access must be governed by the scope defined within the agent's authenticated **Delegation Token** to prevent unauthorized information access beyond explicitly delegated permissions.
2. Tool Integration: MCP offers standardized interfaces for tool invocation. Secure operation requires that access to each tool is gated by verifying the presented **Delegation Token explicitly permits its use**, aligning with the principle of least privilege defined in the delegation.
3. State Management: While MCP can manage session state for continuity, this state must be protected according to the sensitivity implied by the **Delegation Token's* context and potentially tied to the token's lifespan* to prevent stale state misuse or information leakage after authority expires.

These features highlight the need for a robust authorization mechanism within MCP, built upon authenticated delegation principles.

MCP Authorization Architecture - Implementing Agent-Specific Delegation

A secure MCP implementation aligns naturally with the authenticated delegation model. The MCP server can be a resource server (providing tools) and potentially part of the delegation infrastructure.

• MCP Server as Authorization Delegation Server: The MCP server can function similarly to the Authentication & Delegation Server. When an agent (MCP client) connects:

  • It may trigger an OAuth 2.1 flow to authenticate the User (via an upstream IDP, providing a User ID Token).
  • The agent identifies itself (providing its Agent ID Token or credentials).
  • The User consents to the agent accessing specific tools/resources this MCP server exposes.
  • The MCP server then issues a scoped Delegation Token (functionally representing an OAuth 2.1 access token enriched with the specific delegation claims linking user, agent, and scope) back to the agent.

• Token Validation: The MCP server must validate the presented Delegation Token on subsequent requests to invoke tools, enforcing the embedded scope. This provides "Transport-Level Enforcement" based on delegated authority.

• Leveraging Key OAuth 2.1 Standards for Security: To implement this securely, MCP relies on specific elements of the modern OAuth 2.1 framework and associated security best practices like secure token handling and rotation (recommended via SHOULD in the MCP spec but essential for enterprise security), which are crucial for mitigating the threats discussed previously:

  • OAuth 2.1 Foundation: MCP adopts the current best practices defined in the OAuth 2.1 draft, which mandates stricter security defaults than original OAuth 2.0. This includes requiring authorization codes, disallowing the insecure implicit grant, and enforcing exact redirect URI matching.
  • PKCE (Proof Key for Code Exchange - RFC 7636): This is mandatory for MCP clients (agents). PKCE prevents authorization code interception attacks during the browser redirect flow. Even if an attacker intercepts the authorization code, they cannot exchange it for a token without the secret code_verifier. This directly mitigates risks of Identity Spoofing and unauthorized token acquisition that could lead to Privilege Escalation or Tool Misuse.
  • HTTPS Enforcement: All communication with authorization endpoints (token, registration, etc.) must be over HTTPS, protecting credentials and tokens from eavesdropping and tampering in transit.
    • Server Metadata (RFC 8414): The MCP specification recommends (SHOULD) that MCP servers implement Authorization Server Metadata, with clients required (MUST) to use it if available for discovering endpoints like the authorization and token endpoints. **For enterprise scale and security, relying on this standardized metadata discovery is a vital best practice. It significantly reduces the risk of configuration errors and enhances interoperability compared to relying on hardcoded or default fallback URLs, ensuring agents connect to legitimate endpoints.
  • Dynamic Client Registration (RFC 7591): The MCP specification also recommends (SHOULD) support for Dynamic Client Registration. In practice, automated registration becomes a crucial enabler for seamless and secure agent onboarding in dynamic enterprise environments, especially those with many MCP servers or tools. It eliminates manual credential management friction and the security risks associated with pre-distributing or hardcoding client secrets, helping manage Non-Human Identities more effectively and securely at scale. However, implementers should be aware that despite the specification's recommendation and the benefits of automation, some service providers acting as MCP Servers may prefer or require manual client registration via their developer portals for greater control over client vetting and security policies.
  • Scoped Access Tokens (Delegation Tokens): The core OAuth concept of scope is central. The Delegation Token issued by the MCP server carries only the permissions explicitly consented to by the user for that specific agent and session. This is the primary defense against Confused Deputy vulnerabilities, Excessive Agency, and Privilege Escalation, as the resource server (the tool/API itself or the MCP server gating access) enforces these strict boundaries based on the token, regardless of the agent's potentially flawed reasoning.
  • Bearer Token Usage (RFC 6750): Tokens are presented using the standard Authorization: Bearer header, ensuring compatibility with existing resource server infrastructure.
  • Secure Token Handling: Adherence to OAuth 2.1 best practices for securely storing tokens, enforcing expiration, and implementing rotation (SHOULD requirements in the MCP spec) are fundamental security hygiene requirements in any enterprise deployment using token-based authentication. Regularly rotated, short-lived tokens significantly minimize the window for token compromise and abuse.
  • Sender-Constrained Tokens (Highly Recommended): While the basic flow issues bearer tokens, security is significantly enhanced by employing sender-constrained tokens where feasible. Mechanisms like Demonstrating Proof-of-Possession (DPoP) [RFC9449] or Mutual TLS Client Certificate-Bound Access Tokens [RFC8705] cryptographically bind the token to the specific client (Agent) that requested it. This prevents a stolen token from being successfully replayed by an attacker, providing a critical defense against token leakage. Implementations SHOULD support and utilize sender constraint mechanisms for Delegation Tokens whenever the client (Agent) and server (ADS/MCP Server/RS) infrastructure allows.

- Binding User, Agent, and Scope: The essential goal remains securely binding the verified User identity, the verified Agent identity, and the specific consented scope into the verifiable Delegation Token. The Model Context Protocol (MCP) provides a standardized way for agents to interact with tools and services, and we see implementations emerging, for instance, within LLM gateways and proxy servers, primarily focused on streamlining tool connectivity.

However, while valuable, basic MCP connectivity alone does not fulfill the requirements for secure, accountable Authenticated Delegation (AD) needed in enterprise environments. The MCP specification acknowledges this by including an OPTIONAL authorization mechanism based on OAuth 2.1, including a crucial provision for delegating authorization to a third-party authorization server (MCP Spec Sec 2.9).

This third-party delegation pattern is vital for enterprise integration. Organizations can avoid reimplementing complex delegation logic within every MCP-enabled tool or gateway. Instead, when an agent attempts to access a protected MCP resource or tool. :

1. The MCP server can redirect the agent (via the client) to the organization's central Auth & Delegation Server (ADS) – the specialized component designed to handle the sophisticated AD logic detailed throughout this series.

2. This central ADS performs the full AD process: verifying the user (via the enterprise User IDP), verifying the agent (via its Workload Identity/DID), managing granular user consent, evaluating fine-grained policies (via a PDP), and ultimately issuing the rich Delegation Token containing the verified User ID, Agent ID, and consented Scope.

3. The agent then returns this Delegation Token within the MCP interaction.

4. The MCP server, now acting as a gatekeeper, validates this token against the trusted ADS before granting access to the underlying tool or resource.

This pattern is also flexible. Beyond integrating with a central enterprise ADS, the MCP specification's third-party flow can facilitate scenarios where the MCP Server must act as an OAuth client to access external, user-permissioned resources hosted elsewhere (e.g., code repositories, SaaS APIs).

This architecture effectively leverages MCP for standardized connectivity while ensuring authorization relies on a dedicated, enterprise-grade delegation service embodying the AD principles. It cleanly separates the concerns of protocol interaction (MCP) from sophisticated, context-aware authorization (AD via the ADS), providing the verifiable linkage essential for secure agent operation.

Adherence to AD principles within MCP prevents reasoning-layer bypasses, as authorization based on the Delegation Token happens before the agent's request reaches the tool logic. Best practices include using short-lived Delegation Tokens, PKCE, rigorous redirect URI validation, and potentially continuous access evaluation based on token validity and context.

Platforms are beginning to provide tooling that is aligned with these principles. For instance, Cloudflare has introduced components Ref: Cloudflare Blog Post designed to facilitate the deployment of remote, authenticated MCP servers on their infrastructure, handling aspects of the OAuth 2.1 flow and agent state management needed to issue and enforce such delegated permissions.

Bridging Agentic IAM with Workload Identity

The requirements for securing AI agents using authenticated delegation (verifiable identity, scoped/revocable permissions tied to specific tasks, auditability) closely mirror the principles of Workload Identity used for securing non-human service accounts in cloud environments.

Authenticated delegation provides the dynamic, user-centric authorization layer often needed on top of more static workload identity mechanisms when agents act on behalf of users. This linkage will be explored in detail in our next article.

Conclusion: Building Secure Foundations for Agentic Systems**

As AI agents become integral, their operational complexity demands robust IAM solutions. Authenticated delegation, with its framework of User ID, Agent ID, and Delegation Tokens, provides the essential controls for single-agent and complex multi-agent patterns (Chaining, Routing, etc.). It ensures granular authorization, enforces scoped permissions for tools and services, and enables comprehensive auditability by maintaining a verifiable chain of authority.

The Model Context Protocol (MCP) offers a promising standard for agent-service interaction, but its security relies on implementing or leveraging an authenticated delegation model aligned with enterprise standards like OAuth 2.1. Organizations that implement these patterns now will be better positioned to scale agentic systems confidently — with enforceable, auditable boundaries that align with compliance, risk, and operational integrity requirements. Authenticated Delegation and its integration with MCP and OAuth 2.1 can form the architectural backbone of secure AI automation.

In the next paper, we’ll dive deeper into workload identity management—exploring how its principles intersect with and complement authenticated delegation for securing dynamic AI-driven workloads in enterprise environments.

References

• Authenticated Delegation  South, T., Marro, S., Hardjono, T., et al. "Authenticated Delegation and Authorized AI Agents". (Basis for applying AD to single/multi-agent patterns).

• MCP Auth Spec Model Context Protocol Specification - Authorization Section (Revision 2025-03-26). (Source for the OAuth 2.1 requirements/recommendations (PKCE, HTTPS, Metadata, Dynamic Registration) discussed in the context of MCP).

• Cloudflare MCP Blog Irvine-Broque, B., Kozlov, D., Maddern, G. "Build and deploy Remote Model Context Protocol (MCP) servers to Cloudflare"

• LiteLLM Docs LiteLLM Documentation: "/mcp [BETA] - Model Context Protocol"

• WIMSE Practices Draft IETF Draft: "Workload Identity Practices"

• WIMSE Arch Draft IETF Draft: "Workload Identity in a Multi System Environment (WIMSE) Architecture"