Autonomous AI Agents and the MCP Server Trust Problem: Inside Cisco's Open-Source Agent Identity Framework

Why Agents Are Rewriting the Rules of Identity and Access Management

When AI agents begin executing tasks autonomously at machine speed, the IAM systems that enterprises have relied on for decades face a fundamental challenge. Jhulu Panath, Product Management Director at Cisco's incubation engine OutShift, and Cindy Chiu, Senior Product Manager at Duo Security, systematically laid out the root causes of this problem and the approach to addressing it in a technical presentation.

OutShift's mission is to explore emerging markets adjacent to Cisco's core business (networking, security, observability, collaboration), with a current focus on the "Internet of Agents" revolution. Its open-source project Agency has been donated to the Linux Foundation, with the goal of establishing open standards for interoperability between agents—much like the TCP/IP protocols that underpinned the early internet.

Cindy Chiu pointed out that what makes agents unique is that they possess both human and machine attributes: they communicate in probabilistic natural language (like humans) yet operate at machine speed and scale (like software). This combination introduces three core challenges: discovery and identification (confirming whether a counterpart is trustworthy among millions of agents), secure connection (passing complex state across frameworks and platforms), and observability and evaluation (ensuring probabilistic systems work as intended without falling into conflicts or infinite loops).

Gartner's forecast underscores the urgency: by 2026, nearly half of enterprise applications will embed dedicated AI agents, compared to less than 5% today.

Why Traditional IAM Models Fail in the Face of Agents

Cindy Chiu broke down the limitations of three mainstream access control models in agent scenarios one by one:

• RBAC (Role-Based Access Control) performs excellently for humans and long-running services, but agents have no "job titles," and their actions are highly context-dependent. Coarse-grained roles cannot describe "which tool to invoke right now to complete which task."
• ABAC (Attribute-Based Access Control) introduces dynamic attributes such as location, department, and data sensitivity, offering greater flexibility—but policy conditions expand exponentially as attributes increase, making them difficult to manage, understand, and debug at machine speed.
• ReBAC (Relationship-Based Access Control) excels at modeling collaborative relationships of "who is connected to whom," but it cannot express the specific task an agent is executing and lacks the fine-grained control required for dynamic tool interactions.

The common blind spot across these models is that they answer "can this person access it," whereas agents need to answer "what permissions does this unit of work require."

The One-Way Trust Gap in the MCP Protocol and Three Types of Attack Surface

Cindy Chiu steered the discussion toward the Model Context Protocol (MCP). MCP provides a standardized framework for AI applications to connect to external data sources, APIs, and tools, but current mainstream implementations follow the traditional client-server model—AI clients authenticate to MCP servers, and trust flows essentially in one direction.

This means AI agents often cannot cryptographically verify whether an MCP server is legitimate or whether the resources it claims to offer are genuine. This gives rise to three types of attack surface: server forgery (attackers setting up impersonating servers), man-in-the-middle attacks (lack of mutual authentication leading to intercepted or tampered communications), and privilege escalation (compromised servers exposing resources that should not be accessible).

It is worth emphasizing that the problem is not limited to MCP—any system in which AI agents autonomously access external resources has the same one-way trust issue. When operating across organizational boundaries, one-way trust must be upgraded to mutual authentication.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to provide a standardized way for large language models to connect with external data sources, tools, and APIs. It adopts a client-server architecture: AI applications (clients) initiate requests to MCP servers via the MCP protocol to obtain data or perform operations. MCP addressed the fragmentation problem in which every AI application previously needed custom integration code for different tools, and the industry has likened it to "the USB-C port of the AI world." However, as noted in this article, in current mainstream MCP implementations, authentication and trust establishment occur primarily in the client-to-server direction, and the server itself lacks a cryptographic mechanism to prove its legitimacy to the client. This asymmetric trust model poses significant security risks in agent interactions across organizations and in open environments.

The Agency Agent Identity Framework: Prove It, Govern It, Scale It

Jhulu Panath took over to introduce Agency's approach. The framework's design principles can be condensed into a three-step formula: Prove it, Govern it, Scale it.

Cryptographic Identity: Making Agents Impossible to Impersonate

Each agent receives a cryptographically verifiable identity—no shared user accounts, no anonymous services. Identity is bound to agent registration, anchored in tamper-proof trust nodes, and managed throughout the lifecycle. This fundamentally blocks the possibility of agents impersonating one another or exceeding their authority without detection, and also prevents credential sprawl.

Cryptographic identity typically relies on public key infrastructure (PKI) or decentralized identifier (DID) systems for implementation. Each agent holds a unique private key and proves its identity to interacting parties through a public key or verifiable credential. Unlike traditional usernames/passwords or API keys, cryptographic identity does not depend on shared secrets, so there is no risk of impersonation after credential leakage, and there is no need to distribute and rotate keys among multiple parties. In agent scenarios, this mechanism also supports anchoring an agent's "birth certificate"—that is, binding its registration information to its public key and recording it on a tamper-proof ledger or trust node, so that any party can independently verify that the agent was indeed created by the claimed entity and remains under its management. This provides an auditable trust foundation for agent interoperability across organizational boundaries.

TBAC: Authorizing the "Work," Not the "Person"

This is the most innovative part of the entire framework. TBAC (Task-Based Access Control) does not replace RBAC/ABAC/ReBAC but adds a capability layer on top of them. It progressively narrows permissions: from the broad intent (task), to the systems and APIs that need to be reached, and finally to the precise, auditable transaction. Together, these three form a temporary, just-in-time permission envelope—effective only while the task is active, containing only the minimum necessary tools, and automatically revoked once the task is complete.

This is fundamentally different from delegation or impersonation: TBAC authorizes the unit of work itself rather than pretending the agent is a particular user.

Interoperability and Human Fallback

The identity service supports integration with existing IDPs such as Duo and Okta, so enterprises do not need to rebuild their authentication stack. It also supports decentralized identity, allowing identity to flow with agents across systems and organizations. In high-risk scenarios, human-in-the-loop approval can be triggered.

Demo Verification: From 403 to an Approved Transaction

The speakers conducted an end-to-end demo using a multi-agent currency exchange application: the OASF financial assistant agent communicates with a currency exchange agent via the A2A protocol, and the latter accesses two tools on a currency exchange MCP server via the MCP protocol—querying exchange rates and executing exchanges.

With no policies configured initially, the assistant's request for an exchange rate immediately received a 403 Forbidden. After creating a TBAC policy for the OASF agent that allows access only to the GetCurrencyExchangeRate tool, queries returned to normal.

When the user requested an exchange of 1,000 USD, a 403 was returned again because the A2A agent had not been authorized to be invoked. After adding two policies—one allowing the A2A agent to access the TradeCurrencyExchange tool and another allowing the OASF agent to invoke the A2A agent—the exchange completed successfully.

Finally came the human-in-the-loop step: after marking the exchange rule as "requires approval," when the agent attempted to invoke the trading tool, the registered mobile device received a push notification and had to allow or deny within 60 seconds, with automatic denial upon timeout. Denial returned a 403; approval completed the transaction. This chain turns "least privilege" and "human in the loop" into an operational engineering implementation.

What This Means

Agency's path offers a paradigm worth watching: the core of agent security is not issuing an account to an agent, but rebuilding the entire authorization logic around the "unit of work." TBAC currently focuses on the tool level, while task-level and transaction-level policies are still being explored. The project has been open-sourced and placed under the neutral governance of the Linux Foundation, which provides an accessible entry point for teams that want to participate in standards development.

For enterprises introducing agents into production environments, the takeaway from this approach is: identity must be cryptographically anchored, permissions must be just-in-time and task-bound, and trust must be mutual. If any one of the three is missing, autonomy becomes an exposure to risk.

Background Notes

TBAC (Task-Based Access Control) is not an entirely new concept—it has long been discussed academically in traditional workflow management and database systems, with the core idea of binding access permissions to task instances in a business process rather than to static subject identities. In the agent context, TBAC takes on new meaning: a "task" is triggered by an agent's intent and, after being parsed by a policy engine, generates a temporary permission envelope that precisely lists the tools, APIs, and transaction scope allowed to be invoked during that task's lifecycle. This just-in-time granting mechanism aligns closely with the "least privilege" principle in zero-trust architecture, but goes further—it not only limits "what can be accessed" but also defines "in what task context access occurs" and "how long access lasts." Permissions automatically expire once the task is complete, fundamentally shrinking the window for credential leakage or privilege abuse.

One-line Summary

Agent autonomy challenges traditional IAM; the Agency framework rebuilds authorization logic with cryptographic identity and TBAC.

Paragraph Summary

The article explores the fundamental challenge AI agents pose to traditional identity and access management (IAM) systems. Experts from Cisco OutShift and Duo Security point out that agents combine human-like probabilistic communication with machine-speed scale, rendering the three mainstream access control models—RBAC, ABAC, and ReBAC—incapable of expressing their task context and dynamic tool invocation needs. The current client-server one-way trust model of the MCP protocol suffers from three attack surfaces: server forgery, man-in-the-middle attacks, and privilege escalation. To address this, the Agency Agent Identity framework proposes a three-step principle of "Prove it, Govern it, Scale it," using cryptographic identity anchoring, TBAC (Task-Based Access Control) just-in-time authorization, and identity interoperability to narrow permissions from broad tasks down to precise transactions, with automatic revocation upon task completion. The demo verified the complete chain of policies precisely controlling tool access and high-risk transactions triggering mobile human approval.