TL;DR: MCP gives AI apps a standard way to reach tools and data, but the protocol still leaves enterprises exposed where authorization, inventory, and runtime inspection lag adoption, according to Aqua Security and Gartner. The governance problem is not just protocol maturity, but the fact that AI access patterns are moving faster than current identity and workload controls can reliably observe or constrain.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Aqua Security's blog post: MCP security for enterprise AI workloads is lagging adoption because authorization, inventory, and runtime visibility are not keeping pace.
Why it matters: IAM and security teams need to treat MCP as an identity and governance problem as much as an integration pattern, because exposure grows when AI systems reach tools and data faster than controls can observe or constrain them.
Context
MCP, or Model Context Protocol, standardises how AI applications connect to tools and data sources. In practice, that makes it easier for enterprises to expand AI capability, but it also creates a new control surface for identity, access, and runtime inspection across model-driven systems.
The governance gap is not simply about protocol maturity. It is about enterprises adopting AI access patterns faster than current authorization, inventory, and workload controls can reliably keep up, especially when remote MCP servers and community connectors are involved.
Key questions
Q: What breaks when an MCP server has no clear authorization boundary?
A: Without a clear authorization boundary, teams are forced to improvise trust decisions inside the server logic itself. That creates ambiguity around who issued the token, what claims are trusted, and how consent is enforced. In practice, the result is fragile integrations, inconsistent scope handling, and a much higher chance that agent requests exceed intended permissions.
Q: Why do insecure MCP servers create such a high-risk path for AI agent abuse?
A: Insecure MCP servers can turn a browser session into a bridge into local tools, files, and commands. Because MCP often connects agents to business systems over long-lived sessions, a rebinding attack can silently redirect trusted traffic to localhost. If authentication, origin checks, and session binding are weak, attackers can execute commands or exfiltrate sensitive data without needing a full system compromise.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
Q: Should organisations treat AI tool connectors as part of NHI governance?
A: Yes. Once an AI workload can invoke tools and access data, it behaves like a governed non-human identity and should be subject to lifecycle, ownership, and scope controls. The practical question is not whether the connector is clever, but whether it is inventoried, authorised, monitored, and removable when no longer needed.
Technical breakdown
Where MCP authorization fails in practice
MCP was designed to reduce custom integration sprawl, but the early protocol model did not enforce native authorization between client and server. That leaves a gap between what the AI app can reach and what the enterprise can actually govern. OAuth 2.1 support narrows that gap, yet thousands of deployed servers predate it, so mature and immature implementations coexist. In identity terms, the problem is not only authentication. It is the absence of a consistent authorization boundary around tool discovery, data access, and instruction flow.
Practical implication: Treat MCP authorization as a deployment-state problem, not a protocol assumption, and inventory every server that still lacks explicit access control.
Why MCP inventory and reputation matter to NHI governance
MCP expands the number of machine-side access paths that security teams must understand. Remote servers, local connectors, and open-source community deployments can all mediate access to business data, but their security quality varies widely. Without a complete inventory, teams cannot tell whether a connector is sanctioned, duplicated, or obsolete. In NHI terms, this is classic governance drift: the access path exists, the owner is unclear, and the trust posture is often assumed rather than verified.
Practical implication: Build a complete MCP inventory that includes ownership, deployment mode, and trust level so obsolete or unsanctioned servers can be removed from scope.
Runtime inspection is the missing control layer
MCP security cannot be evaluated only at configuration time because the risk emerges during model-driven interaction. Prompt injection, unsafe tool calls, and sensitive data exposure happen inside the session, where the AI app combines instructions, context, and tool access dynamically. That means workload-level telemetry matters as much as policy. When the enterprise cannot see prompts, responses, and tool calls together, it cannot distinguish normal behaviour from a malicious chain of execution. For AI-connected workloads, runtime visibility becomes the control that reveals whether access was actually safe.
Practical implication: Instrument AI workloads with session-level monitoring that captures prompts, tool calls, and responses so unsafe execution can be detected in context.
Threat narrative
Attacker objective: The attacker wants to turn legitimate AI connectivity into unauthorized data exposure or unsafe tool execution through the MCP path.
- Entry occurs when an AI application reaches external data or tools through an MCP server that lacks strong native authorization or is deployed with weak trust controls.
- The attacker then abuses the AI session through prompt injection or a malicious connector, causing the model to request data or invoke tools outside the intended scope.
- Impact follows when the AI workload exposes customer records, internal documents, secrets, or destructive actions through the connected tool chain.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
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 exposes an identity control problem, not just a protocol problem: the practical risk is that AI systems now reach tools and data through access paths that were not designed with consistent authorization or lifecycle governance in mind. That makes inventory, trust classification, and runtime control part of identity governance, not adjacent hygiene. The implication is that teams should stop treating MCP as a simple integration layer and start treating it as governed access infrastructure.
Ephemeral AI access does not remove governance obligations, it compresses them: once an AI workload can call tools dynamically, the trust decision moves from provisioning time into session time. That is a different operating model for IAM, because the relevant question is no longer who can log in, but what the workload can invoke, combine, and pass along while it is active. Practitioners need to recognise that access scope is now runtime-shaped.
Shadow AI becomes harder to manage when MCP tooling is invisible to traditional control planes: if teams cannot see which servers, connectors, and model paths are active, they cannot certify ownership or revoke obsolete access with confidence. This is especially material where community-maintained or internally built servers are used. The practitioner conclusion is simple: undiscovered AI tooling should be governed as unmanaged non-human access until proven otherwise.
Runtime inspection is becoming the decisive control for AI-connected workloads: static policy is not enough when the risk emerges from the interaction between prompts, tools, and data at execution time. That shifts the centre of gravity from configuration review to observability and containment in the workload itself. Security teams should expect MCP governance to converge with NHI and workload identity controls, because that is where the actual enforcement boundary is moving.
Access review assumptions are already straining under AI-assisted workflows: review cadences were designed for access that persists long enough to be enumerated and recertified. MCP-driven AI behaviour can create short-lived but high-impact access paths that are difficult to see after the fact. Practitioners should treat this as a signal that governance models built for stable access will need re-scoping for machine-driven execution.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Ephemeral AI access is now a governance problem: when tool calls happen inside model sessions, the classic assumption that access persists long enough to be reviewed starts to weaken. Teams need to shift attention from periodic certification to issuance-time control and runtime traceability.
Shadow AI inside MCP deployments is the new inventory gap: if a workload can discover and use tools without being clearly owned, sanctioned, and monitored, security teams lose the ability to decide whether the access path is legitimate. That is a non-human identity problem first and a platform problem second.
Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. The gap is not just readiness, it is a mismatch between fast-moving AI access patterns and slower identity governance models.
For practitioners
- Inventory every MCP server and connector Catalog local, remote, and fully remote MCP deployments with ownership, purpose, data scope, and trust level so unsanctioned access paths are visible.
- Require explicit authorization for each MCP path Verify that client-to-server access is protected by current authorization controls, and isolate legacy servers that still rely on implicit trust.
- Classify AI tool access as governed NHI activity Treat model-to-tool interactions as non-human identity behaviour and apply the same lifecycle discipline used for other machine access paths.
- Add runtime inspection to AI workloads Capture prompts, responses, and tool calls in the workload so prompt injection, unsafe tool use, and unintended data exposure can be investigated in context.
- Quarantine low-reputation or community MCP servers Require additional review for open-source or internally built servers that lack clear security practices, code review, or documented maintenance.
Key takeaways
- MCP expands enterprise AI capability, but it also creates a governance gap when authorization, inventory, and runtime visibility lag deployment.
- The security issue is less about the protocol itself than about unmanaged trust boundaries around tool use, data access, and session-time behaviour.
- Practitioners should treat MCP-connected AI workloads as governed non-human access and move control points closer to discovery, authorization, and runtime inspection.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP's early lack of native authorization leaves AI tool access boundary decisions weak. |
| NHI-05 — Overprivileged NHI | The article warns that low-reputation servers can grant excessive privileges to AI workloads. | |
| NHI-02 — Secret Leakage | The article links unsafe MCP usage to secret exposure and internal document leakage. | |
| Recommendation — Apply NHI-04 to enforce explicit authentication and authorization for every MCP server and client path. Map MCP connectors to NHI-05 and reduce each server to the minimum tool and data scope it actually needs. Use NHI-02 controls to detect exposed secrets in MCP paths and stop sensitive data from flowing through untrusted sessions. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP connects AI systems to external tools, creating misuse risk when prompts drive unsafe calls. |
| Recommendation — Apply ASI02 to constrain which tools an AI workload can invoke and inspect every tool call in production. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | The article describes data exposure and secret harvesting through AI-connected tool paths. |
| Recommendation — Map MCP abuse to TA0006 and TA0009 to improve detections for credential theft and sensitive data collection. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether AI-connected access paths are explicitly authorised and controlled. |
| Recommendation — Use PR.AA-05 to review entitlements for every MCP-connected workload and remove implicit trust. | ||
| NIST Zero Trust (SP 800-207) | 5.2 — Logical Resource Access | Zero Trust access decisions need to be enforced for AI-to-tool connections, not assumed. |
| Recommendation — Apply logical resource access controls to each MCP server and verify access at every request. | ||
Key terms
- MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
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 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org