Topic starter
18/08/2026 2:13 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “OWASP Has Mapped MCP Risk. Enterprises Still Have to Govern It”.
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.
Q: Why do MCP controls need call-time authorisation instead of connection approval?
A: Connection approval only says a server may be reached.
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.
Practitioner guidance
- 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.
Bottom line: MCP governance fails when teams confuse protocol support with enforcement, because authentication, authorisation, and audit must be applied outside the spec.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP governance now depends on enforcement, not just protocol design