TL;DR: The NSA’s MCP guidance says the protocol’s design can create new and poorly traced attack paths because many implementations skip authentication, lack built-in RBAC exchange, and allow approved agents to reach sensitive resources later without review, according to Cakewalk’s analysis of the May 2026 security note. Runtime-scoped access, explicit trust boundaries, and rechecked authorisation now matter more than endpoint patching alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: Under NSA guidance, MCP's design can create poorly traced runtime access paths for AI agents when authentication, RBAC exchange, and rechecked authorisation are missing.
Why it matters: IAM and security teams need to govern agent access at runtime, because MCP can let previously approved AI services reach sensitive resources outside the review assumptions used for human or static machine access.
Context
MCP connects AI agents to external tools and data sources, but the security model is not keeping pace with adoption. The problem is not a single implementation bug; it is the gap between how the protocol routes requests and how identity teams assume access should be granted, traced, and reviewed.
For IAM and NHI programmes, the question is whether agent access is being governed as a living runtime relationship or as a one-time approval. When agents can discover tools dynamically and continue to act across task boundaries, traditional role assignment and review cadences lose precision.
Key questions
Q: What breaks when MCP implementations skip authentication and RBAC exchange?
A: Access decisions stop being enforceable at the point of action. An agent may reach tools or data because the protocol connection exists, not because the current request is authorised. That creates a governance gap where approved access can drift into sensitive activity without a fresh permission check or a reliable audit trail.
Q: Why do MCP-connected agents increase AI data leakage risk?
A: MCP-connected agents can retrieve data directly from enterprise systems, so sensitive information may enter AI workflows without a person copying it into a prompt. That creates a delegated retrieval path, which expands the attack and compliance surface. Organisations need policy controls on what the agent may retrieve and what may be passed onward to the model.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.
Q: When should organisations treat an approved agent as no longer authorised?
A: When the task changes, the context expands, or the agent can reach a new tool set that was not part of the original approval. In MCP environments, approval is not permanent and should not survive changes that alter the scope of data, action, or delegation.
Technical breakdown
Why runtime-scoped access is the real control point
The central architectural problem is that MCP access can expand after an agent is already approved. If a benign service later reaches sensitive resources on demand without fresh review, the control boundary has shifted from provisioning time to runtime, where the actual action occurs. That is why endpoint hardening alone is insufficient. Security has to follow the session, the tool invocation, and the changing scope of what the agent can reach.
Practical implication: Scope agent privileges at execution time and re-evaluate access whenever the agent’s tool set or target data changes.
Threat narrative
Attacker objective: Obtain durable, poorly traced access to sensitive systems through an approved agent pathway that continues to function beyond its intended scope.
- Entry occurs when an AI agent connects through MCP to tools or data sources and the implementation omits robust authentication or permission exchange.
- Escalation follows when dynamic tool discovery or long-lived context lets the agent reach additional resources beyond the originally intended scope.
- Impact occurs when a previously approved service later accesses sensitive resources on demand without triggering a new review or authorisation step.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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 security fails when identity is assumed to be static after approval: The protocol’s risk is not just weak onboarding, but the assumption that a connected agent will continue to behave within the permissions originally granted. That assumption is false when the agent can discover tools dynamically and re-enter sensitive workflows later without a fresh trust decision. The practitioner implication is that runtime access governance must replace one-time approval logic for agent-connected systems.
Runtime access is now the control plane for MCP-governed agents: The NSA’s guidance effectively shifts security from endpoint focus to execution-time enforcement. When a previously benign service can later reach sensitive resources on demand, the decisive control is no longer patch status but whether access is rechecked at the moment of use. Practitioners should treat that as a governance boundary, not a tooling detail.
RBAC alone does not solve MCP because the protocol does not reliably carry the permission context: Role assignment is only useful when the consuming system can enforce it at the point of action. In MCP environments, agent output, server behaviour, and long-lived context can all distort the original role intent. The implication is that identity teams must validate how permissions are exchanged, not just who was provisioned.
Ephemeral trust debt is the right way to describe MCP risk: Approved access does not stay harmless just because it began as legitimate access. Once context, tools, and target resources can change inside the same agentic workflow, the organisation inherits trust that was never re-authenticated. Practitioners need to recognise that agent approval creates a continuing obligation to scope and re-scope access, not a permanent entitlement.
MCP governance now spans NHI, agentic AI, and human oversight together: The interesting problem is not whether the agent is “trusted” in isolation, but whether the surrounding identity model can explain and constrain what happens after trust is extended. That makes MCP a cross-domain identity issue, where access lifecycle, privilege boundaries, and runtime checks have to align. Security teams should design for the delegation chain, not the connector alone.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: Zero Trust for AI Agents
What this signals
Ephemeral trust debt: MCP makes it easy to grant access once and then let that approval linger as context, tools, and resource paths expand. Security programmes should watch for places where runtime behaviour no longer matches the original authorisation record, because that is where agentic access stops being explainable.
MCP governance should now be treated as a live identity problem, not just a protocol hardening exercise. If your control model cannot re-evaluate access as the agent’s tool set changes, the approval process is already behind the runtime reality.
The practical test is simple: if you cannot explain why a given agent can still reach a sensitive resource at the exact moment of use, the trust model is too broad for the protocol you are running.
For practitioners
- Define runtime trust boundaries for every MCP connection Document which agents, tools, models, and users may interact, and require those boundaries to be enforced at the moment of tool invocation rather than only at onboarding.
- Require explicit authorisation checks for dynamic tool discovery Do not let discovered tools inherit implicit trust from the initial session. Each new capability exposed to the agent should be evaluated against current permissions and the current task scope.
- Scope agent access to the minimum viable runtime privilege Limit each agent process to only the resources it needs for the immediate task, and remove access paths that are not required for the current execution path.
- Re-review sensitive access whenever context or toolset changes Treat a change in task, context window, plugin, or data source as a governance event that can invalidate earlier approval and requires a new access decision.
Key takeaways
- MCP exposes a runtime governance problem, not just a transport or endpoint-hardening problem, because access can broaden after initial approval.
- The NSA’s guidance and Cakewalk’s analysis both point to the same issue: authentication gaps, missing RBAC exchange, and long-lived context weaken traceability.
- Practitioners should move authorisation checks to the point of tool use and re-scope agent access whenever the task, context, or tool set changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on MCP implementations that skip authentication or weaken it at runtime. |
| NHI-05 — Overprivileged NHI | Approved agents can later reach sensitive resources with more privilege than the task requires. | |
| NHI-08 — Environment Isolation | Long-lived context and shared agentic environments can blur trust across separate tasks. | |
| Recommendation — Enforce authentication at every MCP trust boundary and reject unauthenticated tool access. Limit agent permissions to the minimum runtime scope and remove unnecessary resource paths. Separate agent sessions and tool contexts so prior approvals do not bleed into new tasks. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article describes agents using granted identity pathways to reach resources beyond intended scope. |
| Recommendation — Map agent privilege paths and block actions that exceed the authorised identity context. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | MCP access paths can be abused to pivot from an approved entry point to broader resources. |
| Recommendation — Track MCP-derived access as potential credential access and lateral movement activity in detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about enforcing and rechecking entitlements as agent scope changes at runtime. |
| Recommendation — Revalidate entitlements at the point of use and retire any access that is not actively needed. | ||
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.
- Ephemeral trust debt: Ephemeral trust debt is the accumulated risk created when short-lived access, credentials, or trust relationships are issued quickly and not fully governed. In practice, it appears when temporary permissions, tokens, or sessions outlive their intended purpose, lack clear ownership, or are not revoked, audited, or rotated with enough discipline.
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.
Published by the NHIMG editorial team on August 26, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org