MCP changes the security model for agentic workflows and access

At a glance

What this is: This analysis argues that treating Model Context Protocol like a normal API misses the security issues created by continuous context sharing, autonomous tool use, and blended human-plus-agent authority.

Why it matters: IAM and NHI teams need to reframe MCP as an identity and authorization problem, not just an API hardening problem, or they will miss where privilege and context can be abused.

👉 Read Aembit’s analysis of MCP security and agent identity controls

Context

Model Context Protocol creates a security gap because it turns access into a continuous, stateful interaction instead of a single request to a fixed endpoint. That matters for MCP and NHI governance because the actor is often an autonomous agent, not a human caller, and the permissions it exercises can evolve during the workflow.

Traditional API controls assume predictable inputs, stable identities, and isolated transactions. MCP breaks those assumptions by letting agents carry context across tools, make decisions at runtime, and inherit some authority from the human session that launched them. That makes the primary question one of runtime governance, not endpoint filtering.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do traditional API controls fall short for MCP?

A: Traditional API controls assume fixed callers, predictable requests, and isolated transactions. MCP introduces autonomous decision-making, continuous context flow, and orchestrated tool chains, which means a valid request can still be unsafe. Security teams need controls that evaluate identity, context, and intent at runtime instead of only validating schema and tokens.

Q: What is the difference between API security and MCP security?

A: API security focuses on protecting known endpoints and request boundaries. MCP security must also govern the agent’s state, the context it carries, and the sequence of tool actions it can trigger. In practice, that means moving from endpoint-centric controls to workflow-centric access policy and continuous enforcement.

Q: When does MCP create more risk than it reduces?

A: MCP creates more risk when agents can access multiple tools with inherited authority, long-lived credentials, or weak audit trails. That combination turns a single compromise into a broader chain of actions. If you cannot explain who acted, what context they carried, and which tool calls were allowed, the risk is already too high.

Technical breakdown

Why MCP breaks traditional API security assumptions

REST and GraphQL security models assume a caller, a request, and a bounded response. MCP instead supports a context-rich session in which an agent may consult multiple tools, pass intermediate outputs forward, and choose the next action dynamically. That means request validation alone cannot determine whether the workflow is safe, because the risk sits in the sequence, not only the payload. Authorization also becomes harder, since the caller may be a non-human identity acting under blended authority rather than a fixed service principal.

Practical implication: Security teams should assess MCP by workflow path, identity provenance, and tool sequence, not by endpoint alone.

Context flow, tool orchestration, and blended identity

The article describes three shifts that matter most. First, context is persistent and stateful, so sensitive data can move through multiple tool calls. Second, tool orchestration creates lateral reach, because one allowed action can trigger several downstream actions. Third, the agent may combine its own identity with rights inherited from the human who started the session, which creates ambiguity about who is actually authorized. These are not edge cases. They are the core operating model of MCP.

Why runtime enforcement matters more than static secrets

Static secrets and post-event logs are weak controls in an MCP environment. If credentials are embedded in prompts, configs, or agent context, they can leak through logs, errors, or compromised tool chains. If logs only capture discrete API calls, they will not reconstruct how the agent reached a decision or where the context changed. Runtime enforcement is therefore the control point that can block malicious context injection, unauthorized tool use, and privilege expansion before they propagate across the workflow.

Practical implication: Prioritise runtime policy checks, short-lived credentials, and audit trails that preserve the full tool chain.

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 is not an API variant, it is an identity problem with a protocol layer on top. The control failure starts when teams treat agentic tool use as if it were a conventional request-response pattern. In practice, the agent is acting as a non-human identity with changing context and delegated authority, which means governance must move from endpoint checks to session-level policy. Practitioners should reclassify MCP programs as identity-governance projects, not integration projects.

Context is the new attack surface in agentic workflows. Traditional API security protects payloads and sessions, but MCP allows intermediate outputs, prompts, and tool results to accumulate into a working memory that can steer later actions. That creates what we would call an identity blast radius, where a single compromise can influence the full chain of tool decisions. Practitioners need controls that limit context reuse and validate what is carried forward.

Blended human and agent authority complicates least privilege. If an agent inherits rights from the initiating user, then entitlement reviews must account for two identities at once. That makes RBAC and ABAC necessary but insufficient, because the policy decision now depends on session intent, environment, and tool scope. Teams should assume that static roles will underconstrain some workflows and overgrant others.

Runtime enforcement becomes the decisive control plane for MCP. Static secrets, delayed logging, and perimeter checks cannot reliably distinguish valid tool use from unsafe autonomous action. The more an agent can choose its own path, the more security depends on verifying identity and policy at the moment of execution. Practitioners should design for short-lived access, continuous evaluation, and revocation that happens during the workflow, not after it.

Named concept: identity blast radius. MCP expands the impact of a compromised agent because one identity can chain multiple tools, preserve context, and exercise inherited rights across systems. The governance question is no longer whether a credential is valid, but how far that credential can move before it is stopped. Practitioners should measure blast radius explicitly and reduce it at the workflow design stage.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, leaving a large gap between concern and operational control.
• For a broader identity lens, see Ultimate Guide to NHIs for the visibility and privilege risks that appear as agent populations expand.

What this signals

The practical signal for IAM programmes is that MCP adoption will expose where access policy still assumes a human caller. As agent use expands, teams will need identity telemetry, session-level authorisation, and review processes that can distinguish delegated authority from autonomous action. The control gap is structural, not a tuning issue.

Identity blast radius: once an agent can chain tools and retain context, the scope of a single compromised identity grows quickly. That means security leaders should measure how far an agent can move across systems, not just whether a token was issued correctly. The right response is to shrink that blast radius through shorter sessions, narrower scopes, and stronger runtime checks.

For practitioners

• Define MCP as an NHI governance scope Map every agent, tool, and MCP server to an owner, an access policy, and a review cycle. Treat the agent as a non-human identity with its own lifecycle, not as a byproduct of the application stack.
• Enforce policy at each tool invocation Require runtime authorization for every MCP tool call, including checks for context, environment, and session intent. Block tool chains that exceed the approved workflow, even if the initial authentication succeeded.
• Remove long-lived secrets from agent workflows Replace embedded API keys and stored credentials with short-lived, just-in-time access where possible. Reduce exposure in logs, prompts, and configuration files by limiting where secrets can appear.
• Separate human intent from agent action Record which user initiated the workflow, which authority the agent inherited, and which actions the agent completed autonomously. Use that separation during audit, incident response, and entitlement review.
• Test context injection and tool-chain abuse Exercise MCP workflows with malicious prompts, poisoned intermediate outputs, and unsafe tool sequences. Validate that controls stop context from propagating into downstream access decisions.

Key takeaways

• MCP changes the security model because the risk sits in continuous context and autonomous tool use, not just in API requests.
• Agentic workflows increase identity blast radius when permissions, context, and inherited authority are not tightly governed.
• Practitioners should move MCP controls toward runtime identity verification, just-in-time access, and per-tool policy enforcement.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard that lets AI agents connect to tools and data sources in a structured way. In security terms, it changes access from single API calls to continuous, stateful interactions that must be governed as autonomous machine activity.
• Non-Human Identity: A Non-Human Identity is any digital identity used by software rather than a person, including service accounts, tokens, certificates, API keys, and AI agents. These identities need lifecycle governance because they can authenticate, request access, and create blast radius just like human accounts.
• Identity blast radius: Identity blast radius is the amount of damage an identity can cause if it is misused or compromised. In agentic systems, the concept includes context carryover, inherited authority, and chained tool access, which can expand impact beyond a single credential or endpoint.

Deepen your knowledge

MCP security and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from API security to agentic workflow controls, it is worth exploring.

This post draws on content published by Aembit: MCP vs. traditional API security and the controls required for agentic workflows. Read the original.