TL;DR: MCP has become a de facto standard for connecting LLMs to tools, but the protocol intentionally does not enforce authentication, authorization, or audit controls, according to Obot’s analysis. The result is an enforcement gap that leaves enterprises responsible for inventory, lineage, call-time access checks, and reconstructable logs across rapidly changing MCP servers.
At a glance
What this is: This analysis argues that MCP’s rapid adoption has outpaced the controls needed to govern it, because the protocol itself does not enforce authentication, authorization, or auditability.
Why it matters: IAM, PAM, and NHI teams need to treat MCP as an enforcement problem, not just a protocol choice, because delegated tool use changes inventory, lineage, and call-time authorisation requirements.
Context
MCP governance fails when teams treat protocol adoption as control enforcement. The article argues that the model context protocol can define how tools connect to LLMs, but it does not itself guarantee identity lineage, authorisation at invocation, or reconstructable logging.
For identity programmes, the issue is not only non-human identity scope but also how delegated execution is checked at runtime. Once agents or services can call tools dynamically, governance has to follow the call, the tool, and the target resource, not just the approved connection.
The article frames this as a control gap that appears whenever inventories, permissions, and audit trails are built for stable systems rather than rapidly changing MCP servers. That is becoming a common pattern as MCP moves from niche adoption into broader production use.
Key questions
Q: What breaks when MCP servers are approved once but allowed to change later?
A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.
Q: Why do MCP controls need call-time authorisation instead of connection approval?
A: Connection approval only says a server may be reached. Call-time authorisation decides whether a specific tool, argument set, and target resource should be allowed now, which is the point where delegated access can be bounded, revoked, and audited with precision.
Q: What do security teams need to verify before exposing an MCP server to users?
A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions. If any of those links are vague, the MCP server can expand access beyond the user’s intent or the organisation’s policy. Auditability should be built in before go-live.
Q: How should teams audit MCP governance across LLM apps and agents?
A: Use the AI layer that matches the risk. Model-layer issues belong with LLM application controls, agent behaviour belongs with agentic controls, and server and tool enforcement belongs with MCP governance. If those layers are collapsed into one review, gaps appear at the handoff points.
Technical breakdown
Why MCP needs an external enforcement layer
MCP defines a transport and tool-access pattern, but it does not natively enforce authentication, authorisation, or audit policy at protocol level. That means the security boundary has to move into gateways, proxies, identity providers, and logging layers that sit around the server. In practice, this is closer to securing a federated control plane than securing a single API endpoint. The important detail is that the policy decision must be made at invocation time, with awareness of the caller, tool, arguments, and downstream resource. Without that, the protocol can describe access while the environment silently absorbs the governance burden.
Practical implication: Treat MCP as an integration surface that must inherit controls from adjacent enforcement points rather than from the protocol itself.
Inventory, lineage, and call-time authorisation in MCP
The article’s governance model depends on four checks: what servers exist, who or what is acting, what is allowed right now, and what can be reconstructed later. Inventory is not a one-time approval record because MCP servers can change tools, owners, and backends after initial approval. Lineage matters because a human may delegate to a client or agent that should not inherit standing permissions in full. Call-time authorisation is essential because connection approval does not equal permission for every tool invocation. Auditability closes the loop by preserving enough context to explain the decision path after the fact.
Practical implication: Design MCP governance around mutable inventory, delegated identity lineage, and invocation-level authorisation rather than static server approval.
How the OWASP AI layers map to MCP governance
The article positions MCP as one layer in a broader AI risk stack that also includes LLM applications and agentic systems. That matters because the control failure is not always at the model, agent, or protocol layer alone. Some risks start in agentic behaviour such as tool misuse or privilege abuse, while MCP-specific failures arise when server provenance, scope drift, and authorisation enforcement are weak. The practical value of the OWASP mapping is that it separates where the risk originates from where it must be enforced. Security teams need both views to avoid putting controls in the wrong layer.
Practical implication: Map each AI risk to the layer where it originates, then enforce it at the layer where it can actually be controlled.
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 governance is now an enforcement discipline, not a protocol-selection exercise. The article shows that the protocol boundary intentionally stops short of authentication, authorisation, and audit enforcement. That means the real control surface moves to identity providers, gateways, proxies, and logging systems that sit in front of the server. Practitioners should treat MCP approval as permission to integrate, not permission to trust.
Mutable tool servers break static inventory assumptions. A server approved today can expose different tools, owners, and downstream resources later without a new approval event. That is a governance failure mode, not just a hygiene problem, because the control evidence no longer matches the live risk. The implication is that MCP inventories must track runtime state, not only procurement or review state.
Identity lineage becomes the missing control variable in delegated MCP use. Human identity alone does not explain which agent or client actually exercised authority, yet many log chains still stop at a service principal. That breaks accountability across human → client or agent → server → tool execution paths. Practitioners need lineage that preserves the delegation chain, because audit without lineage cannot explain privilege use.
Runtime authorisation is the named control gap that matters most. Call-time authorisation: MCP policy only works if the decision is made against the exact server, tool, arguments, and target resource at invocation. The article’s central warning is that connection approval is not enough once capabilities can drift after onboarding. Security teams should see invocation-time enforcement as the point where governance either exists or does not.
The OWASP mapping now needs to be read as a cross-layer governance map. OWASP’s separation of LLM, agentic, and MCP risk is useful because it prevents teams from over-focusing on prompt-layer issues alone. The stronger lesson is that a mature AI control model will distribute enforcement across model, agent, and protocol boundaries. Practitioners should align policy ownership to the layer where each risk can actually be stopped.
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.
- 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
- Read next: NHI Lifecycle Management Guide
What this signals
Call-time enforcement is the control boundary that matters. MCP adoption changes the governance question from whether a server was approved to whether each invocation was authorised against the live identity, tool, and resource context. Programmes that keep relying on connection approval will miss the exact moment authority is exercised.
Runtime inventory is now a governance requirement. A static list of MCP servers cannot keep pace with servers whose tools and backends mutate after onboarding. Teams should expect inventory drift, capability drift, and ownership drift to show up together, which makes lifecycle management and audit evidence inseparable.
7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey. That uncertainty is the same pattern MCP governance exposes when call-time decision points are not logged and reviewed.
For practitioners
- Define an MCP server inventory that tracks live state Record approved servers, tools, owners, versions, credentials, and downstream systems, then verify that the record changes when the server’s tool set or backend changes.
- Enforce invocation-time authorisation for every MCP call Check the server, tool, arguments, target resource, agent identity, and user identity at the moment of use, not only when the connection is first established.
- Preserve end-to-end identity lineage Log the delegation chain from human to client or agent to MCP server to tool and downstream resource so investigators can reconstruct who exercised authority.
- Centralise reconstructable audit logging Capture policy evaluated, decision returned, tool invoked, and downstream resource touched, then make the logs searchable for security and audit review.
- Reassess approval when server capability drifts Treat new tools, changed backends, or altered ownership as events that require revalidation rather than assuming prior approval still covers the live server.
Key takeaways
- MCP governance fails when teams confuse protocol support with enforcement, because authentication, authorisation, and audit must be applied outside the spec.
- The main operational risk is drift: approved servers can change tools, owners, and backends after review, which invalidates static inventory and approval records.
- Practitioners should move to invocation-level controls, identity lineage, and reconstructable logging if they want MCP adoption to remain governable.
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 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 servers lacking enforced authentication at the protocol boundary. |
| NHI-05 — Overprivileged NHI | Delegated tool access and server drift can expand effective privilege beyond intended scope. | |
| NHI-01 — Improper Offboarding | Servers, tools, and delegated access must be revoked when ownership or use changes. | |
| Recommendation — Enforce authenticated MCP access at the gateway rather than trusting protocol participation alone. Review MCP tool scopes against live usage and remove access that exceeds delegated need. Revoke MCP server and tool access when the approved ownership or purpose no longer applies. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on evaluating access at invocation time and limiting entitlements precisely. |
| Recommendation — Apply entitlement checks at each MCP invocation instead of relying on one-time connection approval. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes how unchecked MCP access can enable credential use and movement across tools. |
| Recommendation — Map unchecked MCP tool access to credential access and lateral movement detections in your monitoring. | ||
Key terms
- MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
- Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
- Invocation-Time Authorisation: Invocation-time authorisation is the decision to allow or deny a specific action at the moment it is executed. For MCP, that means checking the exact server, tool, arguments, and target resource at call time rather than assuming earlier approval still applies.
- Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
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 August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org