MCP changes the control plane for agentic AI identities

At a glance

What this is: This is an explainer on Model Context Protocol, which describes MCP as a structured control layer for agentic AI tool use, memory, and context handling.

Why it matters: It matters because IAM, PAM, and security teams need to understand how standardised context and tool routing change the governance model for AI agents and the identities they use.

Context

Model Context Protocol is a structured way for AI systems to pass context, request tools, and maintain memory during a session. In identity terms, it sits in the control plane that determines what an agent can reach, when it can reach it, and why that access is allowed.

The governance gap is that many teams still treat agent access as if it were a static integration problem. Once an agent can select tools dynamically, the security question shifts from integration convenience to auditable authority, scope, and boundary enforcement.

That makes MCP relevant to agentic AI programmes, but only where the agent is actually making independent runtime decisions about tool use and execution timing. If the workflow remains human-approved or tightly scripted, the identity problem stays closer to conventional NHI governance than autonomous control.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do enterprise AI agents create governance risk even when MCP is approved?

A: MCP is only one path an agent can use. Agents may also run CLIs, execute Skills, or generate code that calls APIs directly, which can bypass narrow controls if governance is tied only to one interface. Organisations need a control plane that spans all agent actions, with logging, access review, and clear approval boundaries.

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Should organisations standardise on MCP for all AI agents?

A: No. Standardising on MCP for every case can add unnecessary complexity for local developer workflows that do not need multi-user governance. The better approach is to use MCP where the agent acts for someone else and CLI where the task remains tightly bound to a single operator’s environment.

Technical breakdown

How MCP structures tool calls and memory

MCP standardises how an AI system packages context, invokes tools, and carries state across turns. Instead of ad hoc prompt stuffing or bespoke adapters, the protocol creates a common envelope for function calls, data sources, memory, and instruction history. That matters because the identity and access decision is no longer embedded only in application code. It is distributed across the protocol layer, the tool boundary, and the policies that decide which context is visible to the model at runtime. In practice, MCP turns context into an access surface that can be traced, constrained, and audited, but only if the organisation treats it as governance infrastructure rather than integration plumbing.Practical implication: Map MCP-connected tools, context sources, and memory stores to explicit ownership and authorisation boundaries.

Practical implication: Map MCP-connected tools, context sources, and memory stores to explicit ownership and authorisation boundaries.

Why MCP changes the identity model for AI agents

Agentic systems differ from ordinary automation because they can choose actions and tools during execution, not just follow a fixed script. MCP becomes the coordination layer that lets those decisions happen against structured context, which means the governing question is no longer only who authenticated, but what authority the agent can exercise once it is inside the session. That shifts attention toward runtime authorization, context provenance, and the boundaries around tool invocation. For security teams, the important change is that the agent's effective privilege may be assembled from context, not merely assigned at provisioning time. That complicates traditional least-privilege assumptions because the actual access path is shaped dynamically by the session.Practical implication: Review whether your authorization model can express tool-by-tool authority at runtime instead of only at onboarding.

Practical implication: Review whether your authorization model can express tool-by-tool authority at runtime instead of only at onboarding.

Where custom adapters become governance risk

The article notes that many environments still rely on custom adapter layers or mappings for proprietary and internal APIs. That creates a governance problem because every bespoke connector becomes a separate place where context can be rewritten, permissions can drift, and logging can become inconsistent. MCP promises standardisation, but standardisation does not eliminate risk if the underlying tools, memory stores, and data sources remain unevenly controlled. The real issue is not whether the protocol exists, but whether organisations can prove which context reached which tool, under what policy, and with what audit evidence. Without that, the connector layer becomes the hidden control plane for agent behaviour.Practical implication: Inventory every custom adapter as a governance control point, not just a software integration.

Practical implication: Inventory every custom adapter as a governance control point, not just a software integration.

Threat narrative

Attacker objective: The objective is to abuse agentic tool access and context routing to obtain broader action authority than the organisation intended.

1. Entry occurs when an agent is allowed to interact with tools and context sources through a shared protocol boundary.
2. Escalation happens when the agent can combine memory, retrieved context, and tool authority to widen its effective scope during the session.
3. Impact follows when the agent uses those combined privileges to act on data or systems without sufficiently auditable context boundaries.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

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

MCP is becoming the control plane for agentic identity, not just a transport protocol. The important shift is that access decisions for AI agents increasingly happen at the layer where context, tools, and memory are assembled. That makes the protocol part of the identity stack, because it governs what the agent can know and do in the same session. Practitioners should treat MCP boundaries as policy boundaries, not implementation detail.

Least privilege becomes harder to define when authority is assembled dynamically from context. The article's model assumes that an agent can be given the right context at the right time and then act safely. That assumption is fragile because the effective privilege of the session is shaped by what the agent can retrieve, combine, and invoke after initial authentication. The implication is that static provisioning logic is no longer enough to explain actual runtime authority.

Context provenance is now an identity control, not a documentation feature. When agents rely on structured memory and shared data sources, teams need to know who supplied the context, when it was injected, and which tools consumed it. Without that lineage, auditing the agent is impossible because the evidence trail stops at the application boundary. Practitioners should elevate context provenance to the same level as credential provenance.

Custom connectors create the hidden governance debt that standard protocols are meant to remove. Standardisation reduces integration sprawl, but only if organisations also standardise policy, logging, and review around the connector layer. Bespoke mappings for internal APIs become the place where authorisation drift and observability gaps accumulate. The practical conclusion is that MCP adoption should be paired with connector governance, or the control plane simply moves rather than improves.

Agentic AI security now depends on whether policy can travel with the action. Security models built for static systems assume the decision, the credential, and the effect are separated in time. With MCP-enabled agents, those steps compress into a single runtime path. That means identity governance has to follow the action path itself, not just the account that initiated it.

From our research library:

• According to PwC, 79% of organizations have already adopted AI agents to some degree.
• Read next: Agentic AI Security Guide

What this signals

Agentic AI programmes are moving faster than identity governance can absorb, and MCP is one of the clearest signs that the control plane is shifting from static integrations to runtime context and tool routing. Security teams should watch for connector sprawl, because that is where policy drift and audit gaps usually accumulate.

Context boundary drift: The operational risk is not only that agents can do more, but that teams may lose sight of which context influenced which action. Once that lineage is unclear, runtime authorisation has to be governed as tightly as credential issuance.

MCP will matter most in environments where agents can reach internal APIs, documents, and memory stores without a human in the loop. In those settings, access reviews alone are insufficient because the authority can be assembled and consumed within the same workflow, before governance catches up.

For practitioners

• Map MCP trust boundaries Document every MCP server, tool, memory source, and context injector as a governed trust boundary with an owner, policy, and audit trail.
• Separate context from authority Require explicit policy for which data sources can influence an agent's action path, and do not assume retrieved context is safe to act on by default.
• Inventory custom adapters Find every bespoke adapter or mapping used for proprietary or internal APIs and treat it as a security control point with logging and review requirements.
• Model agent runtime privilege Define how tool access is granted, constrained, and revoked during a live session so that runtime authority matches the task, not just the account.
• Strengthen audit evidence for context use Capture which context objects were injected, which tools consumed them, and which outputs were produced so investigators can reconstruct agent behaviour later.

Key takeaways

• MCP matters because it turns context, tool use, and memory into a governed access layer for agentic AI systems.
• The main risk is not interoperability itself but runtime authority that can outgrow static identity assumptions.
• Teams need auditability at the connector and context layers if they want agentic AI to remain governable.

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.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Session provenance: The evidence chain that links a session back to the human initiator, the non-human identity used, and the systems touched during execution. In agentic environments, provenance is what turns activity into attributable identity behaviour instead of an opaque sequence of events.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.