MCP security exposes the identity gaps in agentic AI workflows

At a glance

What this is: This analysis explains why Model Context Protocol changes the security model for AI agents and why identity-first governance becomes necessary.

Why it matters: It matters because practitioners now have to govern agentic AI, workload identity, and tool access in the same control plane rather than treating MCP as a simple integration layer.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Aembit's analysis of MCP security for agentic AI workflows

Context

Model Context Protocol, or MCP, is a standard way for AI agents to connect to tools, data sources, and services. The governance problem is that these connections are no longer simple API calls made by fixed applications. When an agent can discover tools, chain actions, and maintain state across interactions, identity and authorisation have to follow the runtime behaviour, not just the initial login.

For identity and access teams, MCP turns agentic AI into an NHI governance issue with a broader blast radius. Existing controls built around static service accounts, brittle API keys, and one-time authentication do not fully address context sharing, dynamic tool discovery, or audit requirements across autonomous workflows.

Key questions

Q: How should security teams govern AI agents that use MCP to reach multiple tools?

A: Treat the agent as a governed workload with runtime privileges, not as a one-time authenticated caller. Scope which tools it can discover, limit what context it can carry forward, and require per-action policy evaluation so one successful step does not grant the rest of the chain. That is how MCP becomes manageable rather than open-ended.

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 breaks when teams rely on static API keys for agentic workflows?

A: Static keys cannot express session-level intent, tool-specific limits, or changing context. Once a key is embedded in an agent workflow, it can be reused far beyond the original purpose and is difficult to constrain when the agent starts chaining actions. That makes revocation, traceability, and least privilege much harder to enforce.

Q: How do organisations know whether MCP controls are working?

A: They should be able to reconstruct every session, including tool discovery, policy decisions, context changes, and data returned. If they cannot answer who used which tool, why the policy allowed it, and what data moved through the chain, then the control set is incomplete.

Technical breakdown

How MCP changes the trust boundary for agent identity

MCP defines a common protocol for agent-to-tool communication, but the security meaning is bigger than interoperability. The agent is not only requesting data, it is also negotiating context, capabilities, and follow-on actions through a persistent session. That shifts the trust boundary from a single request to a conversation with state, metadata, and delegated authority. In practice, this makes identity binding and capability scoping central to security design. If the protocol allows the agent to discover tools dynamically, the control problem becomes who can discover what, under what conditions, and with what context attached.

Practical implication: treat MCP sessions as governed identity relationships, not as ordinary API transactions.

Context injection and tool chaining in agentic AI workflows

Context injection occurs when malicious or misleading content enters the agent’s decision path and influences which tools it calls or what data it exposes. In MCP environments, that risk is amplified because the agent can chain multiple tool invocations in one flow, moving from benign lookup to privileged action without a human gate. A single compromised context source can therefore alter the rest of the session. This is why tool chaining matters: once the agent accepts poisoned input, the protocol can carry the effect across systems, turning a narrow exposure into a broader execution path.

Practical implication: isolate high-trust tools from low-trust context sources and log each tool transition explicitly.

Why continuous authorisation is the real control requirement

Traditional authentication proves identity once, but MCP-driven agents operate over longer-lived interactions that change state as they execute. Continuous authorisation means evaluating access at each meaningful action, not only at connection start. That requires policy inputs such as environment posture, tool sensitivity, data classification, and session history. RBAC alone is too coarse because an agent may be entitled to one tool but not to the next step in the chain. The result is a need for runtime policy enforcement that can react to session drift and limit escalation before context leakage or unauthorised tool use compounds.

Practical implication: enforce per-action policy checks and audit every tool invocation, not just the session start.

Threat narrative

Attacker objective: The objective is to turn a legitimate agent workflow into a trusted path for data exposure, privilege escalation, or unauthorised action across connected systems.

1. Entry occurs when an attacker or poisoned input reaches an MCP-enabled agent through a user prompt, another system, or a third-party tool feed.
2. Escalation happens when the agent uses legitimate MCP access to chain into additional tools, expose context, or request actions beyond the original intent.
3. Impact follows when sensitive data, credentials, or privileged actions are carried through the toolchain and the session produces unauthorised access or disclosure.

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

MCP security is really workload identity governance for autonomous tool use. The protocol does not create the identity problem, but it makes the problem operational at runtime by letting agents discover and use tools dynamically. That means the control plane has to govern who the agent is, what it can reach, and how far delegated authority can travel across a session. Practitioners should treat MCP as identity infrastructure with execution consequences, not as a developer convenience layer.

Context leakage is the first governance failure pattern MCP makes visible. Agents carry state between tools, which means one bad input, one over-shared response, or one insecure log path can spread sensitive context across the session. This is not just data loss, it is delegated context persistence that widens the blast radius of a single compromise. The implication is that tool access review now has to include context handling, not just credential issuance.

Static trust assumptions break when the agent chooses tools at runtime. Access models designed for predefined application paths assume the execution route is known in advance. That assumption fails when an agent independently selects the next tool, combines responses, and decides whether to continue. The implication is that least privilege must be evaluated as a runtime boundary problem, not only as a provisioning problem.

Identity blast radius is the right concept for MCP governance. Once an agent can access multiple tools through one protocol layer, a weak control in one connector can expose the rest of the chain. This is why standard API hardening is not enough: the relevant unit of risk is the connected identity session, not the endpoint in isolation. Practitioners should redesign policy around the full reachable tool graph.

Auditability becomes the deciding control for enterprise adoption. If every tool call, context change, and policy decision is not traceable, MCP creates an accountability gap that teams will not be able to defend in incident response or compliance review. That is a NIST-CSF issue first and an AI governance issue second. The practical conclusion is simple: if you cannot reconstruct the session, you do not yet control it.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The governance lesson extends forward into tooling choices, and OWASP Agentic Applications Top 10 is the right next framework to pressure-test agentic access paths.

What this signals

Identity blast radius will become the metric that matters most for MCP deployments. As agentic workflows spread, the practical question is no longer whether the agent can authenticate, but how far one authenticated session can reach before policy intervenes. Organisations that cannot bound the tool graph will find that a single integration error creates cross-system exposure faster than legacy IAM review cycles can react.

The immediate programme signal is to bring MCP under the same governance discipline used for workload identity and privileged access, including session visibility, policy logging, and route restriction. That also means aligning controls with the NIST AI Risk Management Framework where autonomous behaviour changes the risk profile. If the control set cannot reconstruct action chains, it is not ready for production agent use.

Context persistence is the hidden risk multiplier: the longer an agent carries state across tools, the more likely one bad input or unsafe output will contaminate the rest of the session. In practical terms, teams should expect the weakest link to be the handoff between context sources and privileged actions, not the model itself. That is why the new governance boundary sits between context handling and tool execution, not inside either system alone.

For practitioners

• Define MCP trust zones Separate low-trust inputs, regulated data sources, and high-impact tools so the agent cannot move freely between them inside one session.
• Bind agent identity to every tool call Use cryptographic identity and continuous authorisation so each MCP action can be traced to a verified workload rather than a one-time login.
• Instrument context handling end to end Log what context entered the session, what was forwarded to each tool, and where sensitive data was returned or stored.
• Review tool graphs for escalation paths Map which MCP-enabled tools can chain into others, then remove unnecessary reachability where one connector could expose the wider environment.

Key takeaways

• MCP turns agentic AI into a governance problem about runtime identity, not just integration design.
• The main risks are context injection, tool chaining, and session-level privilege expansion that legacy API security does not fully constrain.
• Teams need continuous authorisation, tool-graph visibility, and full audit trails before MCP-enabled workflows can be treated as production-grade.

Key terms

• Model Context Protocol: A standard that lets AI agents connect to tools, data sources, and services through a common interface. In security terms, it changes the identity problem from a single API call to a stateful session where discovery, context, and follow-on actions all need governance.
• Context Injection: A failure mode where malicious or misleading content enters an agent's decision path and affects what it does next. In MCP environments, the injected context can alter tool selection, broaden data exposure, or trigger unsafe follow-on actions across multiple systems.
• Tool Graph: The set of tools, services, and connectors an agent can discover and reach during execution. It matters because risk is not isolated to one endpoint. A weak control on one node can create an access path into the rest of the connected environment.
• Continuous Authorisation: A control approach that evaluates access at each meaningful action rather than only at login or connection start. For agentic workflows, it is the difference between checking identity once and governing how privilege changes as the session unfolds.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: MCP security for agentic AI workflows and the identity gaps it exposes. Read the original.