TL;DR: MCP is turning AI agents into delegated actors that touch real customer accounts, data, and transactions, which makes identity, consent, and auditability the core security problems, according to Strivacity. Existing CIAM assumptions break when an agent can chain tool calls across systems, so authorization debt and consent gaps become the practical risk.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Strivacity's blog post: MCP turns AI agents into delegated actors that can touch customer accounts, data, and transactions, making CIAM controls central to MCP security.
Why it matters: It matters because IAM teams must govern customer consent, agent authorization, and auditability when machine-driven workflows act on behalf of real users.
Context
MCP is a protocol for connecting AI agents to tools and data sources, but the security problem is not just how requests move across the wire. The deeper issue is that agent-driven workflows now sit inside customer identity and consent flows, which shifts MCP from an API integration question to an identity governance problem.
Traditional CIAM assumes a human authenticates, establishes a session, and then stays behind the subsequent activity. MCP breaks that model when an agent can chain tool calls across systems, use customer credentials or delegated authority, and trigger actions that the customer may not have explicitly reviewed in context.
Key questions
Q: What breaks when an MCP workflow relies on a human-session model for customer identity?
A: The model breaks when the system assumes a logged-in customer is the same thing as explicit agent delegation. MCP can drive many tool calls across multiple systems in one session, so authentication alone does not prove authority for each action. Teams need machine-readable consent, scoped delegation, and traceable attribution for every downstream call.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.
Q: When should organisations treat MCP as a CIAM issue instead of only an API issue?
A: As soon as agents are acting on behalf of real customers, touching customer data, or initiating transactions. At that point, the question is no longer only whether the request is technically valid. It is whether the customer authorised the agent, the scope is correct, and the action can be audited end to end.
Technical breakdown
Why MCP changes the authorization model for customer identities
MCP standardises how an agent discovers tools, selects one, passes parameters, and receives output, which makes it easier for the agent to act across multiple systems in one workflow. That convenience also creates a delegation chain that is longer than a normal API transaction. In CIAM terms, the problem is not only whether a request is authenticated, but whether the agent is authorised to act on behalf of a specific customer for a specific purpose. When that chain is implicit, authorization debt accumulates quickly.
Practical implication: treat every MCP workflow as a delegated access path and verify who authorised it, what scope was granted, and where that scope is enforced.
How consent, token exchange, and act_as claims carry identity context
The article points to structured delegation through OAuth Rich Authorization Requests and OAuth token exchange, because flat scopes do not capture enough context for agentic activity. A delegated token needs to tie the customer, the agent, and the permitted action together so downstream systems can read the same authorization context. The act_as claim matters because it preserves attribution as the token moves through multiple tools and servers. Without that structure, logs may show activity, but they will not show legitimate authority.
Practical implication: use structured delegation objects and token-level attribution so each tool call remains tied to the originating customer authorization.
Why least privilege becomes the primary control in MCP environments
The article describes over-permissioned agents, credential theft, and tool poisoning as the main ways MCP deployments expand blast radius. That is because an agent often receives a token once and then uses it repeatedly across several tools, so any weakness in scoping can expose customer data, workflow controls, or account settings. Least privilege is not a generic policy slogan here. It is the control that limits how far a compromised credential or manipulated tool response can propagate across the delegation chain.
Practical implication: scope agent permissions to the narrowest workflow boundary and remove broad access that would let one token reach unrelated customer actions.
Threat narrative
Attacker objective: The objective is to abuse delegated agent access so a single compromised identity can expose customer data, expand control across tools, and trigger unwanted actions.
- Entry begins when an agent authenticates to an MCP server with a long-lived API key or other static token that can be reused across multiple tools.
- Escalation occurs when the same delegated credential carries excessive permissions, allowing the agent or an attacker controlling it to read, write, or trigger actions beyond the intended workflow.
- Impact follows when tool poisoning or credential theft lets the agent take unauthorised customer actions, access sensitive records, or initiate transactions at scale.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CIAM is now the control plane for MCP security: When AI agents act on behalf of real customers, the identity problem moves from API access to customer delegation. Authentication alone is insufficient because the critical question is whether the agent was authorised for that exact act, for that exact customer, under that exact scope. That makes consent records, scoped delegation, and auditability part of the security boundary, not post-event evidence.
Authorization debt is the new MCP risk accumulator: Early deployments often hand agents broad tokens to make workflows work quickly, then assume they can tighten controls later. That assumption fails because agentic workflows fan out across tools immediately, and every extra permission widens the blast radius of a compromised token or manipulated tool response. Practitioners should treat over-scoping as the defect, not as a tuning issue.
Consent without structural attribution is not governance: A customer being logged in does not mean the customer authorised every agent action that follows. The delegation must be machine-readable, versioned, and carried through the entire tool chain so each action can be traced back to the original consent event. Otherwise, the organisation may have authentication telemetry but no defensible record of authority.
Know your agent must cover identity and behaviour: Verifying that an agent is registered is only one half of the problem. The second half is detecting when a properly authenticated agent operates outside the authorised customer context, such as by invoking unexpected tools or touching segments it was not meant to reach. Those are different governance functions and should not be collapsed into one control assumption.
Delegated access is becoming a customer-trust issue, not just a platform issue: The named concept here is consent-gap governance, the gap between a customer being authenticated and an agent being explicitly authorised for the exact action performed. That gap is where CIAM, audit, and regulatory exposure converge. Teams that close it will be able to scale MCP with defensible trust; teams that do not will accumulate opaque delegation chains.
From our research library:
- A May 2025 Gartner poll of 147 CIOs and IT leaders found that 24% had already deployed AI agents, 50% were experimenting and 17% planned to deploy by the end of 2026.
- Read next: AI Agent Authorisation Guide
What this signals
Consent-gap governance: MCP exposes the gap between customer authentication and explicit delegated authority. Once agents can act across multiple tools in one run, identity teams need a governance model that records what the customer actually authorised and enforces that scope everywhere it travels.
The practical shift is toward identity-layer attribution, not just application logs. If audit evidence cannot tie each tool call back to a named customer authorization, CIAM has not kept pace with agentic workflows.
A stronger posture separates agent authentication, delegated consent, and behaviour monitoring into distinct controls. That separation matters because a registered agent can still exceed scope, and a well-scoped agent can still be manipulated through poisoned tool output.
For practitioners
- Inventory every MCP-delegated workflow Map which MCP servers each agent can reach, what tools they expose, what customer data they touch, and which credentials the agent uses to authenticate to them.
- Replace flat scopes with structured delegation Use explicit authorization records that bind the customer identity, agent identity, and permitted action so consent is machine-readable and auditable.
- Scope agent permissions to a single workflow Remove broad read and write access that is not required for the specific delegated task, especially where one token can traverse multiple tools.
- Build revocation paths before production rollout Give customers a direct way to revoke agent authority without a support ticket, and make that revocation propagate through every system holding delegated access.
- Separate agent authentication from behaviour monitoring Treat registration and identity proofing as one control, then monitor for unexpected tool sequences, unusual transaction volume, or access outside the authorised customer context.
Key takeaways
- MCP turns AI agents into delegated actors, so the main security question is who authorised the action and whether that authority is traceable.
- The biggest failure mode is authorization debt, where broad tokens and implicit consent let a single agent reach too much customer data and too many tools.
- CIAM teams need structured delegation, least privilege, and revocation paths that work at the agent level, not just the human login level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on delegated agent authentication and token trust across MCP workflows. |
| NHI-05 — Overprivileged NHI | Over-permissioned agents are one of the article's main blast-radius risks. | |
| NHI-07 — Long-Lived Secrets | Static API keys and long-lived tokens are called out as a high-value compromise path. | |
| Recommendation — Bind agent authentication to explicit delegation and reject tokens that do not preserve customer authority. Reduce agent privileges to the minimum workflow scope and remove broad customer-data access. Replace reusable agent secrets with short-lived, tightly bound credentials wherever possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether permissions and authorizations match delegated intent. |
| Recommendation — Validate that customer-facing agent permissions match the approved scope before enabling production use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and token handling are central to the article's exposure model. |
| Recommendation — Manage agent authenticators so static tokens and reused secrets do not persist beyond need. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes credential theft and customer-data exposure through delegated agents. |
| Recommendation — Map MCP exposure to credential access and exfiltration paths in threat detection and response. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The article distinguishes valid API transport from insufficient identity assurance for agent actions. |
| Recommendation — Verify that every MCP call is authenticated and attributable to the correct delegated identity. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
- Act As Claim: A token attribute that identifies the original subject on whose behalf a request is being made. It preserves attribution as delegated actions move across systems, which is critical when AI agents perform multiple tool calls and the organisation needs a defensible audit trail.
- Consent Enforcement Gap: A consent enforcement gap is the mismatch between what a user has requested and what downstream systems still do with the data. It appears when a valid opt-out is recorded at the edge, but activation, analytics, or vendor workflows continue processing the same record without suppression.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org