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.
Editorial analysis by NHI Mgmt Group, based on content published by Strivacity: “MCP servers and identity: what the Model Context Protocol means for security”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP turns AI agents into delegated actors, so the main security question is who authorised the action and whether that authority is traceable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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
11/06/2026 12:29 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
12/06/2026 2:01 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security is becoming a CIAM problem, not just an API problem