Notifications
Clear all
Topic starter
09/06/2026 11:10 pm
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.
NHIMG editorial — based on content published by Strivacity: MCP security and why AI agents make CIAM the control plane
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Bind delegated access to explicit consent records Use structured authorization so the customer identity, agent identity, and approved scope are captured together.
- Scope agent permissions to one workflow at a time Remove broad read-write combinations, cross-domain access, and unused tool permissions from agent tokens.
What's in the full article
Strivacity's full blog post covers the operational detail this post intentionally leaves for the source:
- OAuth Rich Authorization Requests flow examples for delegated customer consent
- Token exchange and act_as claim handling across multi-tool MCP workflows
- Practical revocation and audit logging considerations for CIAM teams
- Identity-layer controls for customer-authorised agent actions
👉 Read Strivacity's analysis of MCP security, CIAM, and AI agent identity →
MCP and customer identity: what IAM teams are missing?
Explore further
10/06/2026 1:24 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security is becoming a CIAM problem, not just an API problem
