MCP changes the security model for agentic workflows and access

At a glance

What this is: This is an analysis of why MCP creates a different access model from traditional APIs, with the key finding that continuous context, autonomous tool use, and non-human identities break assumptions built into familiar security controls.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as a runtime identity and policy problem because static request controls do not govern agent behaviour, blended authority, or context carry-over safely.

Context

Model Context Protocol is a way for AI agents to share context and invoke tools, but that also means identity and access control are no longer limited to one request at a time. The first-order problem is that traditional API security assumes a caller, a payload, and a discrete transaction. MCP introduces continuous context flow, tool chaining, and agent-driven decisions that change what access means.

That shift matters for identity governance because the actor is often a non-human identity operating with machine authority and, in some cases, human-derived entitlements. Existing API gateways, OAuth patterns, and static secrets can still protect conventional APIs, but they do not by themselves govern the agent’s runtime behaviour, the context it carries, or the sequence of tools it can assemble.

The article’s starting point is typical for the category: most organisations already understand API security well, which is precisely why MCP can be misclassified early and left under-governed.

Key questions

Q: What breaks when MCP security is tested like a standard API?

A: Standard API testing misses relationship-based failures such as confused deputy abuse, token passthrough, and trust-boundary violations between clients and servers. MCP security depends on per-client consent, exact token audience validation, and request-level checks, so endpoint-only scans can report false confidence while the protocol remains exploitable.

Q: Why do MCP agents increase access risk compared with conventional service accounts?

A: MCP agents can make runtime tool choices and may carry human-derived entitlements, so their effective authority is not fixed at provisioning time. That makes least privilege harder to define with static roles alone and increases the chance that one workflow can reach more resources than expected.

Q: What are the warning signs that MCP access is not properly controlled?

A: Warning signs include hard-coded credentials in server files, broad tool permissions, no per-tool ownership, and logs that cannot show which agent made a call. If teams cannot trace a tool action back to an identity, policy, and purpose, the access model is too loose to trust.

Q: Should security teams use API gateways alone to control MCP access?

A: No. API gateways can still validate schemas and rate-limit calls, but they do not judge agent intent, blended authority, or context integrity. MCP needs identity-first enforcement at runtime, with policy decisions tied to the agent, the human-derived attributes it carries, and the specific tool invocation.

Technical breakdown

Why continuous context changes the attack surface

Traditional APIs exchange discrete requests and responses, so security tools can validate schema, inspect parameters, and make a decision per call. MCP instead carries conversation state, previous tool output, and sensitive data forward across the session. That persistent context is not just transport data, it becomes part of the control surface because later tool decisions depend on earlier context. If malicious input alters that state, the attack is no longer confined to one endpoint. The control problem shifts from request validation to context integrity, which is much harder to express with conventional API controls.

Practical implication: treat context integrity as a security boundary and decide where context can be modified, inherited, or reused.

How autonomous tool chains break endpoint-by-endpoint governance

API security usually governs each endpoint independently, with separate authentication, authorization, and logging around each call. MCP workflows do not behave that way. An agent can read from one server, process the result, and write to another as one logical task, which means the security decision cannot be made in isolation at each endpoint. The real risk is compounded by orchestration, where a trusted first step becomes a path into downstream tools. That is why tool-chain awareness matters more than individual endpoint hardening.

Practical implication: evaluate authorization at the workflow level, not just at the endpoint level.

Non-human identities and blended authority in MCP

MCP agents operate as non-human identities, but the article also describes a blended model where the agent may inherit rights from the human who initiated the session. That combination creates a governance problem because the effective authority is not always equal to the agent’s own baseline identity. Static secrets, long-lived tokens, and human-centric OAuth assumptions do not capture this hybrid state well. Security teams need to know which permissions are native to the agent and which are inherited, because those are different risk sources with different audit expectations.

Practical implication: inventory native and inherited authority separately before allowing agents to access production tools.

Threat narrative

Attacker objective: The attacker wants to steer an agentic workflow so that a trusted non-human identity executes unauthorized tool actions and exposes data or access across the chain.

1. Entry occurs when an attacker or malicious instruction reaches the agent through injected context or compromised workflow input, rather than through a single API request.
2. Credential exposure or misuse follows when static secrets, tokens, or inherited entitlements travel with the agent across multiple tools and logs.
3. Escalation happens as the agent chains tools together and expands the effect of one compromised decision into downstream access or broader resource use.
4. Impact is achieved when the attacker influences the full interaction chain, not just one call, allowing unauthorized access, data exposure, or workflow abuse.

Breaches seen in the wild

• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous context is the new access primitive in MCP. The older assumption is that security can inspect a request, decide, and move on. That assumption fails when the actor carries state across multiple tool invocations and the security decision must follow the context, not just the endpoint. The implication is that governance now has to account for how identity, data, and intent travel together through a workflow.

Least privilege stops being static when an agent decides its own tool path. In traditional IAM, privilege can often be defined at provisioning time because the expected workflow is known. In MCP, the agent may choose tools at runtime, which makes intent less predictable and scope harder to predefine. The implication is that access governance must focus on decision-time authorisation, not only on role assignment.

Blended identity exposes a distinct governance gap. The article shows an agent that can act under its own non-human identity while also carrying human-derived entitlements. That means the old separation between user identity and service identity is no longer sufficient as a governance model. The implication is that practitioners must distinguish native machine authority from inherited authority before they can reason about audit, approval, or accountability.

Runtime enforcement becomes the decisive control plane for MCP. API gateways and WAFs still matter, but they were designed to block request patterns, not to govern agent intent, tool orchestration, or context integrity. This creates a runtime governance gap rather than just a missing feature. The implication is that MCP security belongs in identity-first policy enforcement, not in perimeter-style request filtering.

MCP creates identity blast radius rather than endpoint risk. A single compromised context or poorly governed token can extend across a whole tool chain, which changes how practitioners should think about exposure. The security problem is not whether one API call is allowed, but how far one agentic decision can propagate. The implication is that teams need to measure and constrain workflow blast radius, not just protect individual services.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: MCP Security Guide

What this signals

Identity blast radius: MCP turns access governance into a propagation problem, because one decision can cascade through multiple tools and data sources. Teams that still optimise only for request-level validation will miss the broader question of how far an agentic action can travel before it is contained.

Security programmes should expect MCP to force a shift from static entitlement review to runtime policy enforcement. That means the control plane has to understand both the agent’s own non-human identity and any authority inherited from the human who started the session.

For practitioners

• Model MCP as a runtime identity problem Classify every agent, server, and tool as a governed non-human identity and document what authority each one can exercise at runtime.
• Separate inherited and native permissions Record which entitlements belong to the agent itself and which are inherited from the human who initiated the workflow, then review both before production use.
• Move authorisation to decision time Evaluate each tool invocation with current context, posture, and identity state instead of relying on roles or scopes assigned before the session began.
• Eliminate static secrets from agent workflows Use short-lived credentials and secretless access patterns so API keys and tokens are not stored in prompts, logs, or context streams.

Key takeaways

• MCP changes the security problem from request handling to workflow governance, because the relevant unit of control is the agentic chain rather than the single API call.
• The main exposure is not one endpoint but the way context, entitlements, and tool use propagate together across a session.
• Practitioners need runtime identity verification and policy enforcement if they want to keep agent behaviour within approved boundaries.

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.
• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 programme, it is worth exploring.