MCP servers and identity: what the Model Context Protocol means for security

If you're thinking about or actively building with AI agents, you've most certainly run into the Model Context Protocol (MCP). It is now the de facto standard for connecting AI agents to external tools, APIs, and data sources. It's also a new identity surface that most security teams aren't ready for.

Don’t ignore that it also lands squarely in CIAM territory. Many of the identities being extended to AI agents are customer identities. Agents are today acting on behalf of real people, accessing real accounts, triggering real transactions. That makes this a customer identity problem. And with that, an infrastructure problem.

Here's what you need to understand about MCP security before your agents start taking actions you didn't anticipate.

What is the Model Context Protocol (MCP)?

MCP is an open protocol, originally developed by Anthropic, that defines how AI agents connect to external systems. Think of it as a USB standard for AI: instead of every agent needing custom integration code for every tool, MCP provides a common interface that any compliant tool can plug into.

An MCP server exposes a set of tools, which are functions the AI agent can call. The agent discovers what's available, decides which tool to invoke, sends parameters, and gets back a result. From the AI's perspective, it's a clean, consistent way to interact with the outside world. From a security perspective, it's an agent acting on your systems with whatever permissions it was handed at the start of the session.

That last part is where things get interesting.

Why MCP security is a CIAM problem, too

CIAM exists to govern how customers authenticate, what they're authorized to access, and how their consent and data are managed. Every one of those functions becomes more complex the moment an AI agent enters the picture.

The questions MCP raises aren't primarily about network security or data encryption. Those problems are well-understood. The hard questions are identity questions:

• Who authorized this agent to act on a customer's behalf?
• What customer data is it allowed to touch?
• Did the customer actually consent to this specific action?
• Can you produce a clean audit trail that answers all three?

Traditional CIAM assumes a human is on the other end of a session. That human authenticates, establishes a session, and the system trusts subsequent requests within that session. MCP breaks that assumption. An agent might invoke dozens of tools across multiple systems in a single orchestrated workflow, and none of those systems may have any direct relationship with the customer who kicked the workflow off.

The result is a credential and authorization chain that's much harder to reason about than anything CIAM was originally designed for. The agent needs an identity. The agent's permissions need to be scoped correctly. And somewhere in your audit trail, you need a clear line back to the customer who granted it authority in the first place.

How MCP creates new attack surfaces

There are four places where things can go wrong in an MCP architecture.

1. Agent credential theft. If your agent authenticates to an MCP server using a long-lived API key or static token, that credential becomes a high-value target. A compromised agent credential doesn't just expose one system. It may expose every tool the agent was authorized to reach, and potentially every customer record it could access.
2. Over-permissioned agents. It's tempting to give an agent broad permissions during development and clean it up later. Later doesn't always happen. An agent that can read and write across your customer data store, trigger communications workflows, and modify account settings is a significant blast radius if something goes wrong.
3. Tool poisoning. Tool poisoning deserves more attention than it typically gets, because it's the attack vector that doesn't require compromising your infrastructure at all. In an MCP context, a tool response itself can carry embedded instructions. An agent querying a customer record that contains a carefully crafted string could be redirected to exfiltrate data, skip authorization checks, or invoke tools outside the intended workflow. No content-filtering heuristic reliably catches this today. What limits the blast radius is the governance layer: an agent with tightly scoped permissions, operating under a well-defined authorization chain, can only do so much damage even when it's been manipulated. Least privilege isn't just a credential hygiene practice in agentic systems, it's the primary mitigation for a class of attacks your firewall won't see. 
4. Consent gaps. If a customer delegates authority to an agent, the scope of that delegation needs to be explicit and auditable. The customer logged in is not the same as the customer consented to this agent accessing their financial history and initiating transfers on their behalf. The distinction matters legally and practically, and regulators are starting to pay attention.

Three governance requirements for secure MCP architecture

The field doesn't have a settled security standard for MCP yet. But the governance requirements aren't actually new, they're the same requirements that have always applied to delegated access, applied to a more complex delegation chain. Any organization deploying MCP servers at scale needs to think through three things.

1. Consent and secure delegation

The most important question an MCP-aware identity system has to answer is: what did the customer actually authorize, and does the agent's access faithfully reflect that authorization?

This sounds obvious. In practice, most early agentic deployments get it wrong. An agent is given a broad token that was generated during a customer session, and that token is treated as evidence of customer consent. It isn't. A token proves authentication. Consent is something else, it's a versioned, auditable record of what was permitted, under what conditions, and for how long.

Proper delegation flows through OAuth's Rich Authorization Requests (RFC 9396), which allow the authorization scope to be expressed in structured, machine-readable detail rather than as a flat list of string scopes. The delegation should bind three things together: the customer's identity, the agent's identity, and the specific permissions granted. When those three things are explicitly linked, you have delegation. When any one of them is implicit or assumed, you have a consent gap.

Customers also need the ability to see which agents are acting on their behalf and revoke that access without requiring a support ticket. That's not a feature, it's a baseline expectation as agentic workflows proliferate. Any MCP governance architecture that doesn't give customers visibility into and control over their delegated agents will face regulatory and trust problems as AI adoption grows.

2. A unified audit trail

Every tool an agent calls through MCP may be an action taken on behalf of a customer. That means every one of those actions needs to be traceable back to the originating authorization, not just logged at the application layer, but captured at the identity layer in a form that answers: which agent did this, acting for which customer, under which authorization, at what time.

This is harder than it sounds in a multi-tool, multi-system MCP workflow. An agent might call five tools across three different systems in a single session. If each system logs locally and none of them records the delegation chain, you end up with five separate log entries with no way to connect them. That's not an audit trail. That's five islands of data that become useless the moment you need to answer a compliance question or investigate an incident.

The pattern that works is token-level attribution. Delegated tokens should carry an act_as claim (defined in RFC 8693, OAuth 2.0 Token Exchange) that ties the agent's actions to the originating customer's identity. That claim travels with the token through every system the agent touches, so every tool call is attributed regardless of which MCP server processed it. The audit trail isn't assembled after the fact, it's structural.

Regulators are beginning to catch up with this. GDPR already requires data controllers to demonstrate a lawful basis for processing. The EU AI Act adds traceability requirements specifically for AI-driven decisions. An audit trail that can't answer "which AI agent accessed this customer's record and under whose authorization" isn't going to be sufficient for long.

3. Know your agent

"Know Your Agent" means two distinct things in practice, and conflating them leads to governance gaps.

The first is agent authentication: verifying that the agent is who it claims to be before it's trusted to act. This is an identity infrastructure problem. The agent has a registered identity tied to whoever built and operates it. At the point of delegation, that identity is verified, does this agent's stated identity match its registered identity, and has the customer explicitly authorized it to act on their behalf? Without that verification step, you're extending trust based on assumption, which is exactly how authorization debt accumulates.

The second is agent behavior monitoring: detecting when an agent operates outside the scope it was authorized for. This is closer to anomaly detection. Even a properly authenticated agent with a clean delegation chain can behave in ways that weren't anticipated, accessing records outside the customer segments it was authorized for, triggering unusually high transaction volumes, or invoking tools in sequences that don't match the intended workflow. The response to those signals isn't necessarily to block the agent outright. Adaptive access controls can step up verification requirements, require a human approval step, or pause execution pending review.

Both matter. But they require different mechanisms and sit in different parts of your stack. Treating them as a single "agent governance" problem is how organizations end up with a solution that handles one well and leaves the other unaddressed.

The architecture implication

These three requirements: consent and delegation, unified audit trail, and agent verification aren't independent. They're interdependent. A rigorous consent model is only meaningful if the audit trail captures whether the agent stayed within the consented scope. Agent verification is only useful if it feeds into the same authorization chain that governs delegation. When you implement them separately, in different systems with different data models, the seams between them become security gaps.

This is the core architectural argument for handling human and AI agent identities in the same governance layer. Customer data lives in your CIAM platform. Agent credentials shouldn't live somewhere else. Consent records shouldn't be split across two systems. Audit trails shouldn't require post-hoc reconciliation to be useful.

Most CIAM platforms weren't built with non-human identities in mind  and that's fine, because MCP didn't exist a few years ago. But the extension is a design decision, not just an integration project. Teams that treat agent identity as a bolt-on will find the governance requirements harder to meet than teams that treat it as a native concern from the start.

What to do right now

If you're already deploying AI agents, or planning to, start here:

Inventory every MCP server your agents can reach. Understand what tools are exposed, what customer data they touch, and what credentials they use to authenticate.

Audit agent permissions. If an agent's access token can do more than the specific workflow requires, that's a problem to fix now. Least privilege applies to agents, not just humans.

Map your delegation model. For every agentic workflow, ask: which customer authorized this? Does that authorization flow formally through your identity layer with an explicit consent record, or is it implicit?

Check whether your CIAM platform supports agent identity natively. Meaning token exchange, act_as claims, delegated authorization, and agent-level audit logging. If the answer is "we'd need to build something," understand what that build actually entails before you scale.

Build a revocation path. Customers need to be able to revoke agent access. That path should exist before agents are in production, not after a complaint triggers it.

MCP is a standard part of AI infrastructure. The organizations that govern it well for both their customers and the agents acting on their behalf will be the ones that can scale with confidence. The ones that don't will be cleaning up authorization debt for years.

Frequently asked questions

What is an MCP server? An MCP server is a service that exposes a set of tools, callable functions, that an AI agent can discover and invoke at runtime. MCPl defines a standard interface for this interaction, so any compliant agent can connect to any compliant server without custom integration code for each pairing. In practice, an MCP server might expose tools for querying a database, triggering a workflow, reading a customer record, or initiating a transaction.

What is MCP security? MCP security is the discipline of governing what AI agents are permitted to do when they operate through the Model Context Protocol and ensuring those permissions are tied to verifiable, auditable identity. It's distinct from API security because the threat model includes delegation chains, consent gaps, and non-human actors taking actions on behalf of real customers. The hard problems aren't at the transport layer. They're at the identity layer. 

Are MCP servers safe to use? The question is less about whether MCP servers are safe and more about whether your identity governance is ready for them. The protocol is sound. The risk is in how organizations deploy it: long-lived credentials, over-permissioned agents, and implicit consent assumptions that wouldn't survive regulatory scrutiny. Get those three things right and MCP is no more dangerous than any other delegated access pattern.

What's the difference between MCP security and API security? API security asks: is this request authenticated and authorized? MCP security has to ask for a harder follow-up: authorized by whom, on whose behalf, and does that authorization accurately reflect what the customer actually consented to? An API call is a transaction. An agent workflow is a delegation chain and that chain needs to be governed end to end, not just at the entry point. 

How does CIAM relate to MCP and AI agent identity? CIAM was built to govern customer identities: authentication, authorization, consent, and data access. AI agents don't replace that need, they extend it. When an agent acts on a customer's behalf, it inherits the governance requirements that would apply to the customer directly. The practical implication is that agent credentials, consent records, and audit trails belong in the same platform that manages human identities, not bolted on separately where the seams become security gaps. 

What is delegation in the context of AI agents? Delegation is a mechanism for formally binding a customer's consent to an agent's authorization to act. When a customer grants an agent permission to perform specific actions on their behalf, that delegation is captured as a structured authorization object tied to the customer's identity, the agent's identity, the permitted scope, and an expiration date. This creates an auditable record of what was authorized and prevents agents from exceeding the permissions they were actually granted. RFC 9396 (OAuth Rich Authorization Requests) and RFC 8693 (OAuth Token Exchange) are relevant standards gaining traction.