TL;DR: Model Context Protocol centralizes AI tool connections, logging, and authorization, which can reduce shadow tools, excessive permissions, and prompt-injection exposure, according to Noma Security. The governance problem shifts to whether teams can trust each MCP server, scope tool access tightly, and monitor behaviour before AI agents inherit broad access.
At a glance
What this is: This analysis argues that MCP can improve AI tool governance by centralizing access, but it also concentrates trust in the MCP server and its supply chain.
Why it matters: IAM, NHI, and AI security teams need to treat MCP as a governance layer, not just an integration pattern, because tool access, logging, and server trust now share the same control plane.
Context
Model Context Protocol is a standard way to connect AI systems to internal data sources and external tools through a shared access layer. In this article, the governance problem is not the protocol itself but whether the server behind it can be trusted, scoped, and monitored like any other privileged integration point.
For identity teams, MCP matters because it sits where AI systems inherit tool permissions, rate limits, and logging controls. That makes it relevant to NHI governance, especially when AI assistants or agents are given access to enterprise systems through centrally managed connectors.
The article also raises a supply chain issue: a centralized protocol can reduce tool sprawl, but it can also make a single untrusted MCP server an attractive place for abuse. That is a governance concentration problem, not just a transport problem.
Key questions
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.
Q: Why do MCP servers create governance problems for AI workloads?
A: Because they mediate tool access for AI systems while often leaving little trace of what happened inside the interaction. That makes it harder to prove safe use, investigate failures, or confirm that permissions stayed within intended bounds. For security teams, the lack of evidence is itself a control weakness.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.
Q: Should organisations treat MCP access like third-party software risk or IAM risk?
A: Both. MCP server onboarding is a third-party trust decision, while tool permissions, authorization, and revocation are identity governance decisions. If either side is handled in isolation, the organisation can approve a connector that still gives AI systems too much practical access.
Technical breakdown
How MCP centralizes tool governance
MCP creates a standard communication layer between AI systems and the tools they use, similar to an API gateway for agentic access. Instead of every application wiring bespoke connections, the protocol can centralize inventory, authentication, authorization, logging, and rate limiting. That matters because tool governance becomes enforceable at one access plane rather than scattered across codebases. In identity terms, MCP turns tool access into a governable entitlement surface, which is especially useful when AI assistants would otherwise accumulate ad hoc permissions across multiple integrations.
Practical implication: treat MCP as a control point for entitlement review, logging, and authorization policy enforcement.
Why untrusted MCP servers create supply chain risk
An MCP server is not just a connector. It is a dependency that can mediate sensitive requests, expose tools, and influence how AI systems interact with data. If that server is untrusted, compromised, or poorly governed, the risk is comparable to introducing an unaudited third-party library into a privileged workflow. The control problem is not simply tool access, but the trust chain behind the server, its update path, and any upstream code or configuration that can alter behaviour without clear oversight.
Practical implication: classify MCP servers as privileged third-party dependencies and review them with supply chain controls, not only access controls.
How centralized logging changes prompt injection response
MCP’s logging and monitoring model matters because it creates a shared record of tool usage, requests, and unusual behavior. That is valuable when malicious prompts try to steer an AI system toward unsafe tool use, data exposure, or resource abuse. The point is not that logging blocks prompt injection by itself. The point is that centralized telemetry gives defenders a baseline for detecting abnormal tool invocation patterns, failed authorization attempts, or unexpected shifts in tool selection that may indicate manipulation.
Practical implication: build anomaly detection around MCP tool activity, not just around model prompts or API traffic.
Threat narrative
Attacker objective: The objective is to use a trusted AI integration layer to gain broader tool access, data exposure, or downstream control than the organisation intended.
- Entry occurs when an organisation connects AI systems to an untrusted MCP server that mediates tool access.
- Credential or permission abuse follows when the server exposes permissions, data paths, or tool calls beyond what teams intended.
- Impact emerges when the compromised or malicious server becomes a trusted route into downstream tools and sensitive systems.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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 creates a governance concentration point, not just an integration standard. Once tool access, authorization, logging, and discovery converge in one protocol layer, that layer becomes part of the identity control plane. The value is real, but so is the blast radius if the server, connector, or integration chain is not trusted. Practitioners should treat MCP as privileged identity infrastructure, not middleware.
Trust in the MCP server is the new control boundary. The article is right to frame untrusted servers as supply chain risk because the server can sit between the model and every downstream tool. That makes server provenance, update integrity, and ownership clarity more important than the connector count itself. Identity teams should re-evaluate whether their current third-party access governance is strong enough for AI-mediated tool use.
Centralized tool inventories expose shadow AI in the same way CMDB discipline exposed shadow IT. MCP can reveal where tools, permissions, and agents have proliferated without governance, but it also creates a single place where overreach becomes visible. That visibility is valuable only if teams can actually reconcile it against approved access paths. The practical conclusion is that inventory without lifecycle control is only partial governance.
Prompt injection is only one failure mode; tool abuse is the wider one. The deeper problem is that AI systems can inherit tool authority faster than teams can verify whether each tool, server, and permission still fits the intended use case. This is where NHI governance and AI governance meet: access must be bounded at issuance, not merely observed after the fact. Teams should rethink whether their review cycles are fast enough for AI-mediated access patterns.
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.
- 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.
- Read next: MCP Security Guide
What this signals
MCP creates a new control plane for AI tool access. That control plane only helps if teams can see every server, every connector, and every permission path. Without that inventory discipline, the protocol reduces integration sprawl while leaving governance sprawl intact.
Ephemeral AI trust is still built on static infrastructure decisions. The article’s real warning is that a centralized protocol does not remove the need to verify server ownership, update integrity, and authorization scope. 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.
For practitioners
- Inventory every MCP server and connector Record each server, owning team, business purpose, and tool scope so hidden integrations and duplicated access paths can be removed.
- Validate server trust before onboarding Require provenance, patch ownership, and update review for every untrusted MCP server before it is allowed to mediate tool access.
- Scope AI tool permissions by use case Bind each AI workflow to the minimum tool set needed for that task, then separate browse, data, and execution permissions.
- Centralize logging for tool invocation Capture request, response, and authorization events for MCP-mediated actions so abnormal tool use can be detected early.
- Test for prompt injection and tool abuse Exercise MCP-connected workflows with malicious prompts, oversized requests, and unsafe tool combinations to see where guardrails fail.
Key takeaways
- MCP can simplify AI tool governance, but it also creates a privileged trust layer that must be managed as carefully as any other identity control point.
- The main security concern is not centralized access alone, but whether each MCP server, connector, and update path is trustworthy and properly bounded.
- Teams that adopt MCP without inventory, authorization, and logging discipline may reduce tool sprawl while leaving supply chain and over-privilege risk in place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP can concentrate tool authority and privilege in agent-mediated workflows. |
| ASI02 — Tool Misuse | Centralized tool access can still be abused if the server or workflow is not governed. | |
| Recommendation — Bound agent tool access to the minimum privilege needed for each task and audit inherited permissions. Restrict tool selection to approved workflows and monitor for unsafe or unexpected tool invocation. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Untrusted MCP servers function as third-party identity dependencies in the AI stack. |
| NHI-05 — Overprivileged NHI | The article warns that MCP can centralize excessive permissions if scope is not tight. | |
| Recommendation — Assess MCP servers as third-party NHIs and verify provenance, ownership, and lifecycle control before use. Review MCP-mediated permissions and remove any tool access that exceeds the workflow's actual need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | A compromised MCP server can expose credentials and become a path into downstream tools. |
| Recommendation — Map MCP server compromise paths to credential access and lateral movement in detection engineering. | ||
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.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Tool Governance: Tool governance is the control of the APIs, service accounts, connectors, and permissions an agent uses to reach other systems. It focuses on the delegated paths that convert agent intent into action, because those paths often hold the real security risk and the broadest privilege exposure.
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org