MCP security gaps are exposing AI agent access paths at runtime

At a glance

What this is: This is an analysis of how Model Context Protocol design choices create new AI agent access risks, especially when approved connections can later expand into sensitive actions without fresh review.

Why it matters: For IAM, NHI, and agent governance teams, the issue is that runtime access paths and trust boundaries now matter as much as initial authentication and provisioning.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Cakewalk's analysis of the NSA warning on MCP security

Context

Model Context Protocol, or MCP, is the layer that lets AI agents connect to tools, apps, and data sources at runtime. The governance problem is not simply that more integrations exist, but that the protocol can collapse traditional client-server assumptions and create access paths that are difficult to trace, scope, or review once an agent is in motion.

Cakewalk’s reading of the NSA guidance is that the security gap sits in the operational model, not in one isolated implementation flaw. That matters for NHI and agentic AI programmes because any protocol that allows dynamic tool use without strong trust boundaries turns identity into a runtime control problem, not just an onboarding problem.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

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: How do security teams know whether MCP authorization is actually working?

A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.

Q: How can organisations reduce MCP-related identity risk?

A: Use continuous authorisation, strict trust zoning, and detailed transaction logging for every agent interaction. Then limit the agent process to the smallest access set needed for each task so that a benign integration cannot quietly become a broad execution channel.

Technical breakdown

Why MCP changes the agent trust model

MCP is designed to standardise how agents discover and use tools, but that convenience creates an identity problem when the protocol assumes trust across multiple participants. The NSA’s concern is that some implementations invert the usual control flow, letting servers query or act for the client, which blurs who is initiating access and who is responsible for authorisation. If authentication is absent, weak, or implicit, the protocol can move an agent from approved integration to unreviewed resource reach without a fresh decision point.

Practical implication: Practitioners need explicit trust boundaries between agents, tools, models, and users before MCP reaches production.

How approved access becomes runtime escalation

The critical failure mode is not initial compromise alone, but the way a previously benign connection can later access more sensitive resources on demand. That is a governance issue because approval at install time does not guarantee safe behaviour at execution time. Long-lived context, reused sessions, and inherited permissions can let one task bleed into another, especially when the agent trusts tool output without verification and the protocol lacks a built-in RBAC exchange.

Practical implication: Security teams should treat runtime authorisation as mandatory whenever MCP clients can change scope after approval.

Why least privilege must be enforced on agent processes

The NSA’s recommendations point toward runtime-scoped least privilege rather than broad trust in the agentic environment. In practice, that means the agent process, its tools, and its data paths all need their own access checks, not just a one-time onboarding review. Dynamic tool discovery is especially risky if a new capability can be invoked implicitly, because the access decision is being made after the original policy choice.

Practical implication: Teams should deny any access path the agent does not need and re-check authorisation whenever tools or context change.

Threat narrative

Attacker objective: The attacker’s objective is to convert a trusted AI integration into a persistent runtime access path for data exposure, action execution, or lateral movement.

1. Entry begins when an AI agent connects through an MCP integration that may lack strong authentication or explicit trust boundaries.
2. Escalation follows when the approved agent later reaches additional tools or repositories on demand without a new review, turning benign access into broader operational reach.
3. Impact occurs when the agent can read, write, or act across sensitive systems in ways that are difficult to trace or contain.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 creates a runtime trust problem, not just an integration problem. The protocol can make access look authorised at connection time while changing the real security posture during execution. That means identity governance has to follow the session, the tool, and the decision path, not only the initial enrolment event. For practitioners, MCP should be managed as a live trust boundary that can expand or contract as the agent works.

Runtime-scoped least privilege is the only defensible control model for MCP. Static permission reviews cannot see enough of the agentic environment when the agent can discover tools dynamically or reuse context across tasks. The control gap is not simply excess privilege, but excess privilege that becomes usable without a new decision point. That is why access checks must be tied to execution time, not just provisioning time.

Dynamic tool discovery without authorisation checks is a governance failure mode. The security assumption that a tool is safe because it is available inside the environment breaks when an agent can select it on demand. This is the same class of problem that appears in NHI estates when secret scope and operational scope drift apart. Practitioners should treat tool discovery as access creation, because that is effectively what it becomes.

Identity boundaries must extend across agents, plugins, models, and users. The NSA guidance reinforces that MCP security cannot be delegated to a single endpoint or application owner. When one actor can query or act for another, attribution and accountability become shared unless the boundaries are explicit. The implication for IAM teams is clear: governance must move from one-time approval to continuous authorisation and traceability.

Runtime access drift: The dangerous pattern here is not a bad login, but a trusted agent whose usable scope expands after approval. That failure mode already echoes across NHI governance, and MCP makes it more visible because access can be exercised through tools rather than direct credentials. Practitioners need to recognise that the security question is no longer who connected, but what the connected actor can still do right now.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which leaves 48% with a compliance and investigation blind spot, according to the same SailPoint report.
• For a forward view on agent governance, see OWASP Agentic AI Top 10, which helps teams map runtime agent risk to controls.

What this signals

MCP adoption is likely to force a sharper separation between onboarding approvals and runtime control enforcement. When agents can discover tools and expand their reachable scope during execution, governance teams will need continuous authorisation and better traceability than most current IAM review cycles provide.

Runtime access drift: this is the governance pattern practitioners should watch closely. It describes the point where an initially approved integration starts behaving like a broader execution channel, which means access reviews, PAM assumptions, and traditional service-account controls all need re-evaluation in agentic environments.

For practitioners

• Define explicit trust boundaries for every MCP deployment Separate agents, plugins, models, and human users into distinct trust zones, then require authorisation at each boundary where data or action scope can expand.
• Enforce runtime authorisation for tool discovery Block implicit access to newly discovered tools unless the request is re-approved at execution time and tied to the specific agent process and task context.
• Scope MCP agent processes to minimum necessary privileges Limit each agent process to the narrowest repository, data, and action set needed for the current task, then remove access paths the agent does not require.
• Instrument traceability across agent-driven actions Log which agent, tool, and data source were involved in every MCP transaction so security and compliance teams can reconstruct the access path later.
• Review dynamic integration points before broad rollout Test whether MCP integrations allow context reuse, silent scope expansion, or cross-task trust inheritance before approving production use.

Key takeaways

• MCP risk is a governance problem at runtime, because approved AI connections can expand into new access paths after the initial review.
• The strongest control signal is not endpoint hardening alone, but explicit trust boundaries and per-action authorisation across agents, tools, models, and users.
• Practitioners should assume dynamic tool discovery can behave like access creation unless it is continuously rechecked and tightly scoped.

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.
• 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.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Dynamic Tool Discovery: A runtime pattern where an agent asks a registry or directory what tools are available before deciding what to use. This differs from hardcoded integration because the tool list can change without redeploying the agent. The governance challenge is keeping discovery aligned to least privilege.

What's in the full article

Cakewalk's full article covers the operational detail this post intentionally leaves for the source:

• The specific NSA security considerations for MCP deployments and how they map to runtime trust boundaries.
• Examples of implementation failures, including authentication gaps and unreviewed access expansion across connected tools.
• The practical recommendations Cakewalk quotes from the NSA for scoping agent processes and limiting implicit trust.
• The source context behind the MCP guidance and how practitioners are expected to interpret it in production environments.

👉 The full Cakewalk article covers the NSA guidance, protocol risks, and runtime access implications in more detail.

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