MCP security is becoming a CIAM problem, not just an API problem

At a glance

What this is: MCP is redefining AI agent connectivity as an identity governance problem because agents are acting on behalf of customers across real accounts and transactions.

Why it matters: IAM, CIAM, and security teams need to govern delegated access, consent, and audit trails as one control plane when non-human actors can trigger customer-impacting actions.

👉 Read Strivacity's analysis of MCP security, CIAM, and AI agent identity

Context

Model Context Protocol, or MCP, is a standard way for AI agents to connect to tools and data sources at runtime. The security issue is not the transport itself, but the identity and authorization chain created when an agent acts on a customer’s behalf across multiple systems. For practitioners, that puts MCP squarely into CIAM, delegated access, and auditability territory.

The article’s central point is that existing customer identity models assume a human is the active session holder. Once an AI agent is making tool calls, consent, scope, and attribution must be explicit rather than inferred. That changes how teams think about authorization debt, revocation, and proof of who authorised what.

Key questions

Q: How should security teams govern MCP access for customer-facing AI agents?

A: They should govern MCP access as delegated customer identity, not as simple API authentication. That means the customer, the agent, and the permitted action scope must be bound in an auditable authorization record, with revocation and expiry enforced at the identity layer. Without that, the system can prove login, but not consent or accountability.

Q: Why do AI agents create consent and audit problems in CIAM?

A: AI agents can chain multiple tool calls across systems in one session, so a human login no longer tells you what was actually authorised. Consent must be explicit, versioned, and tied to the exact scope of delegated action. Audit trails also need token-level attribution so investigators can reconstruct who acted on behalf of whom.

Q: What breaks when MCP agents are given broad permissions?

A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity. The agent can read, write, and trigger actions beyond the original workflow, which makes tool poisoning, credential theft, and accidental misuse far more damaging. Least privilege is the control that limits how far the delegation chain can spread.

Q: What is the difference between agent authentication and agent authorization in MCP?

A: Authentication proves the agent is the registered actor you expected to trust, while authorization defines what that agent may do on behalf of the customer. In MCP, teams need both, because a correctly authenticated agent can still be over-scoped or drift outside consent. Governance fails when those two controls are treated as one.

Technical breakdown

MCP delegation chains and token exchange

MCP creates a delegation chain in which an agent discovers tools, selects one, and executes actions across systems under a token issued from a customer session. The security issue is that a session token proves authentication, not delegated consent. The stronger model is structured delegation, where OAuth Rich Authorization Requests express scope and OAuth token exchange preserves attribution with an act_as claim. Without that linkage, a single token can mask who authorised the action, what the agent was allowed to do, and how far the permission propagated across tool calls.

Practical implication: treat every MCP token as a delegated identity artifact and require explicit consent records, not just successful authentication.

Tool poisoning and authorization scope

Tool poisoning is an MCP-specific risk where a tool response or embedded content influences the agent’s next action. The agent does not need the infrastructure to be compromised for the workflow to be redirected, because the prompt or returned data can steer the agent into exfiltration, unauthorized tool invocation, or skipped checks. This is why least privilege matters more in agentic workflows than in simple API integrations. If the agent can only reach the tools and records needed for one workflow, tool poisoning has less room to expand into a broad incident.

Practical implication: scope agent permissions to the minimum workflow path and assume tool output can become part of the attack surface.

Know your agent for authentication and behaviour monitoring

Know your agent has two different governance jobs. First, authenticate the agent’s registered identity before trust is extended. Second, monitor behaviour after delegation to detect scope drift, unusual transaction volumes, or tool sequences that do not match the intended workflow. Those are different control problems and they need different telemetry. Conflating them creates a gap where the agent is formally trusted but operationally unbounded, which is exactly where authorization debt accumulates.

Practical implication: separate agent identity verification from behavioural monitoring and route both into the same identity governance workflow.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CIAM is becoming the control plane for delegated AI action. MCP turns an agent session into a customer-facing authorization chain, not just an integration event. That means customer identity, consent records, and tool access now need to be governed together rather than split across application, API, and AI layers. Practitioners should treat delegated agent access as a first-class CIAM design problem, not an adjacent infrastructure issue.

Consent is the governance gap that MCP exposes most clearly. A logged-in customer session does not prove the customer authorised an AI agent to initiate transfers, query sensitive records, or chain actions across multiple tools. The missing premise is that authentication and consent are equivalent, which they are not. The implication is that delegated access needs a versioned, auditable authorization record tied to the customer, the agent, and the scope of action.

Authorization debt is what accumulates when agent scope is left broad. The article describes a common pattern: broad tokens are issued first, then cleanup is deferred. That creates a standing permission layer that can be reused far beyond the original workflow. Practitioners should treat over-permissioned agent access as accumulated governance debt, because every extra permission expands the blast radius of a future compromise or misuse.

Token-level attribution is the difference between useful auditability and log noise. In multi-tool MCP workflows, local logs without delegation context cannot answer who acted, for whom, and under what authority. The field needs identity-layer audit trails that survive tool hops and system boundaries. Practitioners should assume post-hoc log stitching will fail when regulators, auditors, or incident responders need a complete chain of custody.

Implicit trust breaks down when autonomous tool use enters CIAM. The article’s named concept is the delegated customer action surface: the area where customer identity, agent identity, and tool permissions intersect. That surface expands every time a workflow spans systems without explicit consent binding and revocation. The implication is that identity governance for MCP must be designed around delegated action, not just login events.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• For a broader control lens, the Ultimate Guide to NHIs shows how lifecycle and access governance need to extend beyond human identities.

What this signals

Delegated AI action will force CIAM teams to treat consent as a governed object, not a login side effect. The practical shift is toward explicit authorization records, revocation paths, and audit trails that survive tool hops. As agentic workflows spread, identity teams will need one control model for human sessions and one for customer-authorised machine actions, with the second increasingly driving design decisions.

Authorization debt is the right concept for broad MCP permissions. When teams defer cleanup of agent scopes, they accumulate permissions that outlive the workflow that justified them. That debt becomes visible only when an incident or compliance request forces the organisation to reconstruct delegated access across systems, which is why agent governance has to be designed up front.

With 52% of companies able to track and audit the data their AI agents access, the other 48% are already operating with a compliance blind spot, according to SailPoint research. That is a governance signal, not just a maturity metric. Teams that cannot trace delegated agent actions end up unable to prove consent, explain scope, or support incident response when customer data is touched.

For practitioners

• Inventory every MCP-connected tool path Map every MCP server, the tools it exposes, the customer data it can touch, and the credentials used for each connection. Focus on where a single agent token can fan out into multiple systems and where those systems lack a shared delegation record.
• Bind delegated access to explicit consent records Use structured authorization so the customer identity, agent identity, and approved scope are captured together. If your current flow treats a session token as consent, redesign it so revocation and expiry are visible at the identity layer, not hidden inside application logic.
• Scope agent permissions to one workflow at a time Remove broad read-write combinations, cross-domain access, and unused tool permissions from agent tokens. Limit each agent to the smallest set of tools and customer records needed for the specific task it performs.
• Separate agent authentication from behaviour monitoring Verify that the agent’s registered identity matches the delegated actor before any tool use, then monitor for unusual tool sequences, transaction spikes, or out-of-scope data access after delegation begins. Route both signals into the same governance process so they are not treated as unrelated events.
• Build revocation paths before scaling production use Make sure customers can revoke an agent’s delegated access without opening a ticket or waiting for support intervention. Revocation must terminate the delegated scope across all connected tools, not just invalidate one token in one system.

Key takeaways

• MCP is not just an integration layer. It is a delegated identity surface that changes how customer consent, agent scope, and auditability must be governed.
• The main risk is not the protocol itself but the governance gap between login, delegated permission, and traceable action across multiple tools.
• Teams that scope agent access tightly, preserve token-level attribution, and build revocation into CIAM will be better placed to manage AI agent adoption safely.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools, APIs, and data sources through a common interface. In security terms, it creates a delegated action layer where the agent’s identity, scope, and audit trail matter as much as the endpoint it calls.
• Delegated Access: Access granted to one identity to act on behalf of another within a defined scope and duration. For MCP and agentic workflows, delegated access must be explicit, revocable, and auditable, or the organisation cannot prove what the customer actually authorised.
• Token-Level Attribution: The practice of binding each action token to the originating identity and authorisation context. It allows investigators and auditors to trace what an AI agent did, for whom, and under what consent, even when the workflow spans multiple systems and tool calls.
• Authorization Debt: Accumulated over-permissioning that persists after the original need for access has changed. In agentic systems, it grows when teams grant broad scope first and defer cleanup, leaving permissions that can outlive the workflow, the customer context, or the intended use case.

Deepen your knowledge

MCP security and delegated AI identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending CIAM into agentic workflows, it is worth exploring.

This post draws on content published by Strivacity: MCP security and why AI agents make CIAM the control plane. Read the original.