TL;DR: MCP standardises how AI agents connect to tools and data, but it also expands trust boundaries, introduces context-injection and privilege-escalation risks, and demands continuous identity verification and auditability, according to Aembit. The security problem is no longer integration convenience, but whether existing IAM and NHI controls can govern runtime tool use by autonomous systems.
At a glance
What this is: This analysis explains why MCP turns agentic AI integration into an identity and access problem, not just an interoperability problem, and why context injection, privilege escalation, and weak auditability emerge as the key failure modes.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat agent-to-tool communication as governed workload identity because autonomous tool use changes how trust, authorization, and traceability must work.
Context
MCP, the Model Context Protocol, standardises how AI agents connect to tools, data sources, and services. That standardisation matters because the problem is no longer simple integration, but whether identity and access governance can keep pace with autonomous systems that choose tools at runtime.
Most traditional API security assumes predictable, user-initiated requests. MCP breaks that assumption by introducing stateful, bidirectional agent interactions, which means access control, auditability, and trust boundaries must be designed for non-human identities rather than retrofitted after deployment.
Key questions
Q: How should security teams govern MCP model-agent interactions?
A: Security teams should govern MCP by treating the model-to-agent boundary as an authorization point, not just an integration point. That means strict schemas, validation gateways, scoped credentials, freshness checks, and logging on every privileged request. If the agent can touch production systems, the model must never be able to turn raw text directly into action.
Q: Why do MCP-based assistants increase the risk of privilege escalation?
A: Because they can combine prompt-driven behaviour with real tool execution and inherited access. A weak tool boundary can let a normal interaction reach internal services, local files, or privileged commands. The risk rises when the assistant’s effective authority is broader than the user’s intent or the application’s visible permission model.
Q: What breaks when AI agents rely on long-lived API keys?
A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.
Technical breakdown
How MCP changes the identity boundary for agentic AI
MCP turns the agent, the server, and the exposed tool into participants in a workload-to-workload trust model. Instead of a human logging into an application and triggering a bounded API call, an AI agent can discover tools, chain actions, and maintain context across multiple exchanges. That changes the identity boundary from a single authenticated request to a runtime relationship that can expand during the session. In practice, the control question becomes whether the agent's identity, the tool's identity, and the data path are all separately governed. If not, the protocol itself becomes a force multiplier for overreach.
Practical implication: Treat MCP participants as governed workload identities, not as ordinary API clients.
Why context injection is different from ordinary prompt injection
Context injection in MCP is a protocol-level attack pattern. The attacker is not merely trying to influence the model's text output, but to manipulate the agent's tool selection, data requests, or downstream actions through crafted messages and shared context. Because MCP supports richer metadata and bidirectional interaction, malicious input can travel farther than a single prompt and affect multiple tool calls. That makes the failure mode closer to policy bypass than content corruption. The operational concern is whether the agent can be induced to request unauthorised context or pass sensitive data into the wrong tool chain.
Practical implication: Constrain which context fields can reach tools and validate every capability request against policy.
Why continuous authorization matters more than initial login
MCP workflows often use long-lived connections and repeated tool invocations, so one-time authentication is not enough. A valid connection does not prove that each subsequent action still matches the original intent, the current policy state, or the agent's environment. That is why the article frames continuous identity verification and real-time authorization as essential. Static roles are too blunt when the agent can decide which tool to invoke next, and audit logs alone only explain what happened after the fact. The control point has to move closer to each invocation and each capability discovery event.
Practical implication: Recheck authorization at each tool invocation and capability discovery point, not only at session start.
Threat narrative
Attacker objective: The objective is to manipulate agentic workflows into unauthorized tool use or data exposure while bypassing the controls that were meant to contain the session.
- Entry occurs when an AI agent connects to MCP-backed tools using brittle authentication patterns, including hardcoded API keys and other weak non-human credentials.
- Escalation follows when the agent discovers additional tools or capabilities and is steered through context injection into actions beyond its original scope.
- Impact emerges when privileged context leaks or unauthorized tool use exposes data, expands the compromise across the toolchain, or undermines auditability.
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.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
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 now an identity governance problem disguised as an integration pattern. The protocol standardises agent-to-tool communication, but standardisation does not create trust. Once agents can discover, request, and chain tool use at runtime, the core question becomes who or what is authorised to act at each step. That pushes MCP into the same governance domain as NHI, workload identity, and privileged access, not into a narrow API-security box.
Context injection is the clearest example of an identity boundary failing under agentic behaviour. Traditional API controls assume the request is the boundary and the caller's intent is already known. MCP breaks that premise because the agent can change its next action based on context delivered mid-session. The implication is that policy must govern the action path, not just the initial request.
Long-lived API keys and ad hoc agent credentials create credential trust debt. The article's criticism of brittle authentication patterns aligns with a broader pattern in which teams inherit old secrets practices and apply them to autonomous systems. That works only until the agent starts composing tools and contexts in ways the original credential model never anticipated. Practitioners should read this as a signal that credential lifetime, discoverability, and revocation are now runtime governance issues, not back-office hygiene.
Access review processes assume a human or service identity persists long enough to be certified, but MCP sessions can change the effective privilege surface in real time. That assumption fails when a single agent session can discover tools, expand context, and invoke new capabilities without a human operator intervening. The implication is that governance must move from periodic review to continuous authorization and traceable policy enforcement.
Named concept: identity blast radius. MCP increases identity blast radius by linking one authenticated agent to multiple tools, data sources, and context-bearing exchanges. Once that linkage exists, a single compromise can extend far beyond the original integration point. The practitioner takeaway is to design for smallest-possible tool scope and to treat every new MCP connector as a multiplier on the agent's effective privilege.
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.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
MCP forces identity teams to stop thinking about a single authenticated request and start thinking about a governed action path. Once an agent can discover tools and continue acting inside the same session, periodic review models lose precision, and access control has to move closer to issuance and invocation.
Identity blast radius: MCP can multiply the damage from one compromised agent credential because the same session may span multiple tools, data sources, and context-bearing exchanges. That is why continuous authorization and scoped tool discovery matter more than broad trust in the connection itself.
For practitioners
- Define MCP workload identities Issue distinct identities for agents, servers, and tools so each participant can be authenticated and traced independently across sessions.
- Replace brittle secrets patterns Eliminate hardcoded API keys and other long-lived credentials from agent integrations, then map every remaining secret to an owner and revocation path.
- Enforce per-invocation authorization Evaluate every tool call, capability discovery step, and context handoff against policy rather than relying on a one-time session grant.
- Restrict context propagation Block sensitive context from flowing into tools that do not need it, and log the exact data elements exposed during each MCP exchange.
- Instrument audit trails for agent actions Record which agent accessed which tool, what context was shared, which policy was evaluated, and what action was approved or denied.
Key takeaways
- MCP changes the governance problem from integration convenience to runtime control over non-human actors.
- The main failure modes are context injection, privilege escalation through tool chaining, and sensitive context leakage.
- Teams that keep using brittle secrets and one-time authentication for MCP will struggle to prove who did what, when, and under which policy.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article highlights hardcoded API keys and leaked context as primary exposure paths. |
| NHI-04 — Insecure Authentication | MCP security depends on cryptographic identity proof, not brittle bearer-key patterns. | |
| NHI-05 — Overprivileged NHI | The article warns that agents can discover and invoke tools beyond their original scope. | |
| Recommendation — Scan MCP integrations for leaked secrets and remove any long-lived credentials from agent workflows. Replace weak agent authentication with verifiable, workload-grade identity controls. Limit each agent to the smallest tool set and privilege scope required for its task. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The protocol enables agents to expand privilege through tool discovery and chained actions. |
| Recommendation — Constrain agent privilege expansion and re-check authorisation before each tool use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article directly criticises API keys and other brittle authentication patterns. |
| Recommendation — Apply authenticator lifecycle controls to replace static agent secrets with governed credential management. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack patterns described center on credential abuse and moving across connected tools. |
| Recommendation — Map MCP risk to credential access and lateral movement to improve detection and containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP requires fine-grained permissioning for agent tool use and context sharing. |
| Recommendation — Define and enforce explicit entitlements for every agent-to-tool interaction. | ||
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.
- 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.
- 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.
- Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org