Who Is This Agent? The AI Identity Crisis

Your AI agent just accessed your production database. It read customer PII, called three external APIs, and wrote results to a shared drive.

Quick question: which agent was it?

Not which user triggered it. Not which service account it borrowed. Which agent. Can you prove it was the agent you think it was, and not something pretending to be that agent?

In most real deployments today, you cannot attribute agent actions with strong, interoperable identity guarantees across tools, runtimes, and frameworks.

The Missing Layer

In human IAM, we have mature patterns for identity and proof: Kerberos, SAML, OIDC, mTLS. In modern service-to-service environments, we also have strong service identity patterns such as workload identity, SPIFFE/SPIRE, and service mesh mTLS.

AI agents rarely get the equivalent treatment.

In practice, many teams deploy agents using two common patterns:

Pattern 1: The agent borrows human credentials. The agent runs as you. It uses your OAuth token, your API key, and your session cookie. Downstream systems observe only your identity. There is no reliable way to distinguish "Gus accessed the database" from "Gus's agent accessed the database" from "a compromised agent acting inside Gus's session accessed the database." The audit log shows one thing: Gus's credentials were used.

Pattern 2: The agent uses shared service accounts. The agent authenticates as a generic service principal: agent-service@company.iam.gserviceaccount.com. Multiple agents share the same credentials. You cannot easily attribute actions to a specific agent instance. You cannot revoke access to one agent without breaking others. You cannot audit what a specific agent did because they all look identical to your infrastructure.

These patterns are not agent identity. They are workarounds. And they create a security gap that grows every time another agent is deployed.

How the Frameworks Actually Work

I pulled apart the authentication mechanisms and identity semantics in major agent frameworks and emerging agent protocols. Here's what I found.

MCP (Model Context Protocol)

Model Context Protocol introduced an authorization specification based on OAuth 2.1. This is real progress. But here's the critical gap: MCP authorization primarily authenticates the client application to the server. It does not, by itself, provide a portable notion of per-agent instance identity that downstream systems can verify.

If multiple agents share one MCP client, an MCP server may not be able to distinguish them without additional, implementation-specific signals. And for STDIO transports, which is how many local MCP servers run today, the guidance is to retrieve credentials from the environment. Translation: use whatever API keys and tokens are available to the process.

Google's A2A (Agent2Agent Protocol)

Agent2Agent Protocol (A2A) was introduced by Google in April 2025 with a promising interoperability approach. Each agent publishes an AgentCard describing its capabilities and how to connect securely. AgentCards declare authentication schemes via securitySchemes, and A2A leans on standard transport security practices like TLS certificate validation.

But credential acquisition is explicitly out of band, and A2A generally relies on existing mechanisms for authentication and authorization rather than standardizing a universal, per-agent-instance cryptographic identity model for every exchange across arbitrary runtimes.

LangChain and LangGraph

LangChain and LangGraph systems commonly authenticate to external services using whatever credentials developers provide: API keys from environment variables, OAuth tokens from the user's session, or secrets in configuration. The framework does not impose an interoperable, cryptographically verifiable agent identity layer across tool calls and downstream systems.

CrewAI

CrewAI defines agents with names and roles and includes runtime-level identifiers (for example, fingerprints) that help internal traceability. However, runtime identifiers are not automatically equivalent to cryptographic identity guarantees across process boundaries, tool calls, and external services.

AutoGen

AutoGen uses structured agent identifiers inside its runtime (for example, AgentId) which is helpful for routing and internal attribution. But that runtime identity does not automatically extend to cryptographic proof of who sent a message or made an external request once you cross trust boundaries. If you need message authenticity across boundaries, you still have to add that layer.

Copilot Studio and similar "OAuth delegated tool access" platforms

Microsoft Copilot Studio and other agent platforms often use OAuth to connect to external services on behalf of users. This is a good delegated access practice. But it typically identifies the user, not the agent instance. Two different agents acting on behalf of the same user can look identical to the API unless the system adds additional, verifiable agent-level identity signals.

OpenClaw

OpenClaw is an open-source, self-hosted personal AI assistant that connects messaging channels such as WhatsApp, Telegram, Slack, and Discord to a Gateway control plane and tool-enabled agent runs. Its security posture is primarily built around inbound access control and operational hardening. The project emphasizes pairing and allowlists for who can talk to the bot, device identity checks for the Control UI in secure contexts, and explicit warnings against insecure configurations. Session transcripts are stored on disk under the OpenClaw state directory, which makes local filesystem permissions part of the trust boundary.

OpenClaw also integrates with pieces of the pi-mono ecosystem. Project documentation describes a Pi agent runtime component in RPC mode, and the docs also state that OpenClaw reuses pi-mono code for models and tools while keeping session management, discovery, and tool wiring OpenClaw-owned.

For outbound actions, downstream services generally see whatever OAuth tokens, API keys, or other credentials the host process or configuration provides. Without an additional identity layer you add on purpose, external systems do not receive a universal, cryptographically verifiable per-agent identity signal that travels with tool calls across trust boundaries.

OpenAI Agents SDK

OpenAI's Agents SDK provides primitives for tools, handoffs between agents, guardrails, and tracing. In the SDK, a handoff is implemented as a type of tool: an agent can call a handoff function and control transfers to the next agent. This is excellent for orchestration and observability, but it is not the same as cryptographic inter-agent identity and message authenticity across boundaries. If you need verified agent-to-agent identity guarantees, you still need to layer them into your design.

Anthropic Agent SDK

Anthropic's Agent SDK provides primitives for building multi-agent systems with tools, handoffs, and guardrails. Tool execution happens in your application (you run the tools, you provide the credentials, you return results). The model is not an authenticated principal in downstream systems. If the host process has access to a database, the tool execution path does too. Agent identity remains application-defined unless you add a verifiable identity layer.

Pi Monorepo (pi-mono)

pi-mono is a TypeScript monorepo that includes a unified multi-provider LLM API, an agent runtime package with tool calling and state management, and an interactive coding agent CLI, plus related components like a Slack bot.

In OpenClaw, pi-mono is used as an integration point for model and tool components, while OpenClaw manages its own sessions and does not consult the Pi coding agent's settings directories.

As with many agent toolkits, identities such as agent names or runtime identifiers are useful for internal routing and traceability, but they do not automatically become cryptographic proof across process boundaries or external service calls. Provider credentials are supplied via configuration and environment, so per-agent cryptographic identity and verifiable delegation across trust boundaries requires extra integration beyond the toolkit defaults.

The Spoofing Problem

Here's where this gets dangerous.

In many multi-agent systems, "agent identity" is treated as a runtime label: a name, a role, or a declared sender field. That can be fine inside a single trusted runtime, but it becomes fragile when messages and actions cross boundaries.

If agent-to-agent messages are not cryptographically bound to an agent identity and verified by the receiver, spoofing becomes a practical risk:

• An agent can claim to be another agent by asserting a sender name.
• A compromised agent can emit messages that look like approvals.
• A prompt injection can cause an agent to fabricate messages that appear to come from a different role.

Consider a typical workflow:

1. A user requests a code deployment.
2. PlannerAgent breaks it into steps.
3. CodeReviewAgent reviews the changes.
4. SecurityAgent approves the security posture.
5. DeployAgent pushes to production.

What happens if an attacker compromises the review or approval step? A payload injected via prompt injection in a code comment might cause CodeReviewAgent to report "approved" regardless of findings. Or worse, it might cause the compromised agent to impersonate SecurityAgent and send a fake approval message directly to DeployAgent.

If DeployAgent has no way to verify that an approval actually came from SecurityAgent, it is operating on an honor system.

This is not a theoretical concern. Modern agent systems increasingly have access to real tools, real APIs, and real infrastructure: SSH, browser automation, filesystem access, cloud credentials, and enterprise SaaS tokens. If identity and message authenticity are not designed in, the blast radius of a compromise becomes enormous.

The Credential Delegation Problem

It gets worse when agents delegate to other agents.

Say Agent A needs to call an API but doesn't have direct access. It asks Agent B, which does have access, to make the call. Agent B complies.

What just happened?

Agent A effectively accessed a resource it wasn't authorized for, by persuading an authorized agent to do it. If the system does not capture and enforce delegation semantics, you get:

• No explicit delegation chain.
• No audit trail showing Agent B acted on behalf of Agent A.
• No policy engine that evaluates whether Agent B is allowed to act when delegated by Agent A.

This is a confused deputy problem at a new scale. Every agent with broad permissions can become a proxy for every other agent that can talk to it. Permissions become transitive. The effective permission set of any agent in a multi-agent system can approach the union of permissions of all agents it can influence.

Traditional IAM would not accept this for humans without explicit delegation policies, scoping, and logging. But that is exactly what many agent systems implicitly allow today.

What Standards Exist

For human identity: SAML, OIDC, OAuth 2.0 and 2.1, Kerberos, X.509, FIDO2, and WebAuthn.

For service identity: SPIFFE/SPIRE, mTLS, Kubernetes ServiceAccounts, cloud IAM roles, and workload identity.

For agent identity: there is no widely adopted, cross-framework standard that provides both consistent identification and cryptographic verification across transports, runtimes, and tool calls.

There are early warnings and real-world signals:

• ISACA warned about an authorization crisis for agentic AI and argued that traditional IAM assumptions break when the actor is not human.
• Obsidian Security's agent security landscape identifies identity spoofing as a primary risk.
• The Langflow CVE (CVE-2025-34291) demonstrated how weak or misconfigured authentication in agent platforms can lead to account takeover and remote code execution.

Some vendors are beginning to introduce platform-managed agent identities. These are important steps, but they are not yet an interoperable standard across frameworks.

We saw this gap and proposed a standard to start filling it. The AI Agent Identification Protocol (AAIP) is a transport-agnostic format for agents to declare their identity in a structured, verifiable way. The format looks like: Vendor/Model (Application; Version) [aid=<agent-id>]. AAIP covers identity strings, capabilities declaration, delegation chains via [delegated=<parent>], and optional verification extensions including signed headers, JWT, and mTLS.

AAIP is a first step, not a complete solution. It gives agents a way to identify themselves consistently across HTTP, WebSocket, STDIO, and other transports. The verification extensions provide a path toward cryptographic proof. But a protocol on paper does not help unless frameworks actually implement it. Today, none of the major agent frameworks support AAIP or anything like it. The standard exists. The adoption does not.

What Agent Identity Would Actually Require

If we build agent identity right, it needs at a minimum:

Cryptographic agent identifiers. Each agent instance receives a unique key pair at creation time. The private key never leaves the agent runtime. The public key is registered with an identity provider. Every message and action that crosses a trust boundary is signed, and recipients verify signatures.

Agent certificates. Certificates issued by a trusted CA bind an agent's public key to identity attributes: organization, framework, runtime, permissions, creation time, and expiry. Think X.509 concepts applied to agents.

Mutual authentication for agent-to-agent communication. Before Agent A sends a message to Agent B, both sides prove identity using cryptographic challenges. This is not a string in a JSON field. It is verifiable proof.

Delegation chains. When Agent A delegates to Agent B, the delegation is explicit, signed, scoped, and time-limited. Downstream requests carry proof that B is acting on behalf of A, and policy engines can evaluate whether that delegation is permitted.

Runtime attestation. Identity alone is not enough. High-trust environments also need assurance that the agent running now is the agent that was issued identity: code integrity, system prompt integrity, authorized toolset, and non-tampered runtime state.

The building blocks exist. But nobody has assembled the full, interoperable stack.

What We're Building

We're not waiting for a standard to arrive fully formed. We're releasing an open-source tool called Agent Identity Auditor (AIA) that maps the authentication reality of your agent deployments.

AIA does three things:

1. Trust Chain Mapping. Point it at a multi-agent system, and it maps every authentication relationship. Which agents authenticate to which services? What credentials do they use? Are credentials shared? Where do tokens originate, and how do they flow? The output is a graph showing your actual trust topology, not the one you assume.

2. Identity Spoofing Detection. AIA analyzes your agent system for identity spoofing risks through static analysis. It detects missing mutual authentication, self-asserted identity without verification, absent inter-agent auth, and prompt injection vectors that could enable impersonation. Where are agents trusting unverified sender claims? Where could a compromised agent forge identity? This is the analysis that most teams have never run on their agent deployments.

3. Credential Scope Analysis. For every credential an agent holds, AIA maps what it can actually access versus what the agent needs. The difference is your excess privilege surface. In systems we've analyzed, that gap is frequently large.

The tool targets ten frameworks and protocols: MCP, Google A2A, LangChain/LangGraph, CrewAI, AutoGen, OpenClaw, OpenAI Agents SDK, Anthropic Agent SDK, Microsoft Copilot Studio, and Pi toolkit configurations. A plugin architecture is planned for additional frameworks. Output includes structured JSON reports and visual trust chain graphs in both ASCII and Graphviz DOT format.

AIA is open source. Try it on your own devices: https://github.com/j-mchugh/AIA

Install via pip (once published):

pip install aia


If you're running agents in production, you need to know what your trust topology actually looks like before someone else maps it for you.

The Bottom Line

We are deploying agents into production systems with real consequences. These agents access databases, write code, manage infrastructure, handle PII, and move money. Yet the question "who is this agent, really?" often has no verifiable, interoperable answer across the systems that matter.

MCP added OAuth-based authorization, but not a universal agent identity layer. A2A added AgentCards and strong guidance for transport security, but still relies on existing auth mechanisms and does not standardize per-agent-instance cryptographic identity semantics across all exchanges. Many popular frameworks provide runtime-level IDs and labels, but those do not automatically become cryptographic proof across trust boundaries.

If you're in security leadership, add agent identity and delegation to your risk register now. Audit what credentials your agents hold and how they authenticate. Assume any agent can spoof another role until you can prove otherwise.

If you're building agent systems, do not wait. Implement signed messages between agents. Use unique, least-privilege credentials per agent instance. Log verifiable agent identity signals alongside every action, not just the human or service account used.

If you're a framework maintainer, this is your responsibility. The frameworks that ship verifiable agent identity, delegation, and message authenticity will win the enterprise market. The ones that do not will ship the next generation of breaches.

The identity layer is not where it needs to be. Let's build it.

Implications for AAIP

Writing this post forced us to pressure-test our own standard. AAIP addresses consistent identification, but real attack patterns reveal areas where the spec should evolve.

Delegation chains need more depth. A single delegated=<parent> field handles one-hop delegation. But real workflows involve chains: A delegates to B delegates to C. Future revisions should support ordered delegation arrays with per-hop scope and TTL.

Runtime attestation should have an extension path. AAIP can describe who an agent claims to be at request time. It says nothing about whether code, prompts, or toolsets were tampered with. A future AAIP extension should allow attaching or referencing an attestation measurement.

Framework binding guides are critical. Transport-agnostic design is correct, but adoption requires concrete framework guidance. Priority targets: MCP, LangChain, CrewAI, AutoGen.

Credential scope should be declarable or linkable. Identity without an enforceable scope invites over-privilege. AAIP should allow expressing a scope claim or referencing an external policy document that can be enforced.

Multi-agent workflows need a session concept. When multiple agents collaborate on a user request, correlation matters. AAIP should consider a workflow=<id> or session=<id> field to tie actions together for auditability.

These are natural next steps, not indictments. Publishing research alongside a standard is how the research sharpens the spec.

Part of Preamble's "Smashing the AI Stack" research series.

Want to test your agent deployments? The Agent Identity Auditor (AIA) is open source: github.com/j-mchugh/AIA

‍