Securing Enterprise AI Agents with Unique Identities in the Model Context Protocol (MCP)

The adoption of agentic architectures is shifting the paradigm of application development. Instead of monolithic applications, enterprises are deploying specialized AI agents autonomous software entities that utilize tools to access internal business resources, often mediated by a communication standard known as the Model Context Protocol (MCP)¹. MCP defines how an Agent interacts with the set of available Tools and how a Large Language Model (LLM) facilitates the decision-making process.

However, this paradigm shift creates a security vulnerability gap. Recent reports highlight that a high percentage of organizations lack proper AI governance and access controls, identifying AI as a critical security risk ². As these agents gain the capability to make decisions and act upon them autonomously or on behalf of human users, securing their interactions with core enterprise systems is non-negotiable.

The core issue is identity: an agent's behavior is often a hybrid of a user, an application, and a workflow. It can act entirely on its own using pre-granted permissions, or it can act as a delegate for an authenticated user. To responsibly enable access to business resources, every agent must be uniquely identified, authenticated, authorized, and made accountable.

The Imperative for First-Class Agent Identity

The lack of proper identity for an AI agent is a direct path to critical security failures, including privilege escalation and compliance violations. An agent operating without a unique identity is indistinguishable from a generic application or, worse, completely untraceable.

To address this, the approach involves establishing the AI agent as a first-class entity within the enterprise’s IAM system, distinct from the human user who initiates the request. This provides the necessary technical and governance foundation for the following critical security capabilities:

1. Unique Identification & Lifecycle Management: Every agent instance receives a unique system-wide identifier. The IAM platform manages its entire lifecycle, including onboarding, storing essential metadata (attributes, capabilities), and offboarding .

2. Agent-Friendly Credential Issuance: Agents require machine-to-machine authentication methods, such as Private Key JWTs or mTLS (Mutual Transport Layer Security), which are more secure than simple API keys.

3. Granular Access Control: By having a unique identity, agents can be assigned roles and permissions (RBAC - Role-Based Access Control) independent of the users they serve. This allows enterprises to control what tools and data an agent can access, and what operations it can perform (e.g., read-only access to HR records).

4. Auditing and Accountability: A unique identity creates an auditable trail. When an event occurs, the system must know not just who was acted upon, but what agent performed the action and on whose behalf. This is essential for debugging, optimization, and non-repudiation in regulated industries.

The overall security posture is enforced across two primary dimensions: first, the access level of the agent to business resources (tools); and second, the control over which users or systems can trigger or interact with the agent. Treating the agent itself as a protected resource is an important governance requirement.

Governing Agent Access with MCP Use Cases

In an MCP-enabled enterprise, agents access business capabilities through discoverable and consumable Tools exposed by the MCP Server. The integration of unique agent identities allows for sophisticated authorization models across different agent behaviors.

1. Delegated Access (On Behalf of a User)

The most common scenario in user-facing applications (like the "Urban Bites" ordering assistant discussed in the talk³) involves an agent acting on behalf of an authenticated human user. In this case, the agent requires the user's permission to perform actions, but the system must also track the agent that executed the action.

The access decision becomes a complex matrix:

• The user must have permission to request the action.

• The agent must have permission to use the tool.

• The final operation’s privilege can be the intersection of the user’s and the agent’s permissions (most secure), the union (least secure), or a subset defined by policy.

• For example, a user may have access to a delete_order tool, but the agent assisting them (e.g., an "HR Agent") may not have been granted the delete_order tool permission. The system can block the request, preventing an unauthorized operation even though the user is privileged.

2. Autonomous Background Agents

Not all agents interact with users. Backend agents are often used for internal business optimization or automation (e.g., an inventory management agent or a delivery assignment agent).

• These agents do not require delegated access from a human user.

• They rely solely on their own pre-granted identity and token, established during their lifecycle management, to interact with the MCP server and its tools.

• In this scenario, their access is determined strictly by the privileges assigned to their unique agent ID (e.g., inventory_agent@corp.com).

3. Securing the LLM Layer

Beyond the agent-to-tool connection via MCP, the communication between the agent and the underlying LLM (the "brain") also presents a security vector.

It is recommended to place an AI Gateway between the agent and the LLM provider. The gateway can:

• Inspect the request, identifying the agent and user.

• Apply global policies, such as rate limiting, based on the specific agent identity .

• Enforce logging and auditing for every prompt and response, attributing the activity back to a specific entity.

Behind the Scenes / How It Works: MCP Logic and Token Exchange

Securing delegated access for an agent acting on a user's behalf requires modifying the standard OAuth 2.0 flow to embed the agent's identity alongside the user's. This relies on the OAuth 2.0 Token Exchange (RFC 8698) and a proposed draft extension to handle dynamic actor delegation ⁴.

The Delegated Authorization Flow

The process begins when an agent (the client application) needs permission to access tools on the MCP server using the logged-in user's privileges:

1. Initial Authorization Request: The agent initiates the standard OAuth 2.0 authorization code grant flow. Crucially, the agent includes an additional, non-standard parameter in the request to the Authorization Server (AS):

   GET /authorize?response_type=code &client_id=urban_bites_agent_client &scope=orders:read orders:create &redirect_uri=... &requested_actor=agent_id_1234 # <--- NEW ACTOR PARAMETER

   The requested_actor claim identifies the unique ID of the AI agent requesting authorization from the user.

2. User Authentication & Consent: The user authenticates with the AS and provides consent for the agent to act on their behalf. The AS tracks that this consent is granted for the specific agent identified by the requested_actor.

3. Token Exchange with Actor Token: After receiving the authorization code, the agent exchanges it for a final access token. In this step, the agent also presents its own, previously acquired, machine-to-machine token, the Actor Token.

   # Example using Python SDK (Illustrative) import wso2_agent_sdk # 1. Agent authenticates itself to get an Actor Token (e.g., via mTLS or client credentials) actor_token = wso2_agent_sdk.get_actor_token(agent_id="agent_id_1234", credentials=...) # 2. Agent exchanges Auth Code and Actor Token for the final access token access_token = wso2_agent_sdk.exchange_token( auth_code=received_code, actor_token=actor_token, grant_type="urn:ietf:params:oauth:grant-type:token-exchange" )

The Resulting JWT Structure

The Authorization Server combines the two identities, the user and the agent, into a single JSON Web Token (JWT), which is then sent with every request to the MCP server. This JWT contains two critical claims that adhere to the delegation semantic:

When the MCP Server's gateway or the Tool endpoint validates this token, it gains clear visibility into the entire chain of action: user smith delegated permission to agent 1234 to perform an action. This dual identity allows for precise, fine-grained access control policy enforcement, auditing, and real-time monitoring of agent behavior.

My Thoughts: Commentary, Limitations, and Future Improvements

The integration of first-class agent identity into the MCP ecosystem is a mandatory step toward responsible enterprise AI adoption. The technical approach of piggybacking on the robust OAuth 2.0 framework, specifically leveraging token exchange semantics, is sound, enabling seamless integration with existing IAM infrastructure ⁵.

However, the primary complexity shifts from authentication to fine-grained authorization. The policy decision, whether to apply the intersection, union, or a complex subset of privileges, requires careful architectural design and governance. A human user might consent to allow an agent to access their calendar, but the underlying policy must prevent a general-purpose agent from accessing HR tools on the user's behalf simply because the agent's pre-granted permissions were too broad. The unique agent ID provides the hook for this control, but the policy definition itself remains an implementation challenge.

Future improvements will likely focus on:

1. Standardization: The adoption of the proposed requested_actor and the corresponding JWT claim across the industry is vital for interoperability.

2. Adaptive Policies: Developing policies that can dynamically adjust an agent’s privileges based on the context of the prompt or the tool interaction itself (e.g., de-scoping permissions after a certain task is complete).

3. Decentralized Identity: Exploring how verifiable credentials and decentralized identifiers (DIDs) could be used to manage agent identity and credentials in highly distributed multi-agent systems.

Ultimately, the ability to generate a clear, unambiguous audit log that answers "Who, acting through which Agent, did What" is the paramount value proposition of this architecture, moving AI agents from a high-risk liability to a securely governed extension of the enterprise workforce.

Acknowledgements

Gratitude is extended to Ayesha Dissanayaka (WSO2) for presenting this crucial work on agent identity and security. This discussion was presented at the MCP Developers Summit during the talk, "Securing AI Agents with Unique Identities | Ayesha Dissanayaka (WSO2) on MCP & IAM." Thank you to the broader MCP and AI community for their continued work on security and protocol standardization.

References