Notifications
Clear all
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.
NHIMG editorial — based on content published by Obot: MCP governance now depends on enforcement, not just protocol design
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
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 deployments complicate NHI governance?
A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Build a live MCP inventory Track approved servers, exposed tools, owners, versions, credentials, and downstream systems in a record that updates when the server changes.
- Enforce authorization at every call Check server, tool, arguments, target resource, agent identity, and user identity at invocation time.
- Preserve end-to-end identity lineage Log the full path from human initiator to agent, MCP server, tool invocation, and downstream resource so investigators can reconstruct who authorized and what executed.
What's in the full article
Obot's full analysis covers the operational detail this post intentionally leaves for the source:
- The MCP server catalog and proxy architecture used to broker OAuth without exposing raw credentials to the server.
- The specific header-based enforcement changes that allow gateways and policy systems to inspect tool and method calls.
- The vendor's implementation approach for logging every call with enough context for audit and investigation.
- How Obot maps access controls to agent-scoped tool sets and server-level permissions in practice.
👉 Read Obot's analysis of MCP governance and runtime enforcement →
MCP server governance: what teams need to enforce now?
Explore further
18/08/2026 3:05 pm
MCP governance is now an enforcement problem, not a protocol problem. The protocol can describe how tools connect, but it deliberately does not enforce the security principles enterprises need. That leaves identity, access, and logging controls to surrounding systems that many deployments still treat as optional. The implication is that MCP teams must stop thinking in terms of approved integrations and start thinking in terms of continuously governed runtime access.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- A second finding from the same research shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions.
A question worth separating out:
Q: Who is accountable when an MCP session misuses tools or data?
A: Accountability sits with the organisation that defined the policy, the control plane that granted the session, and the team that owns logging and revocation. If those responsibilities are split, investigation and containment become slow, and the governance gap becomes part of the incident itself.
👉 Read our full editorial: MCP governance now depends on enforcement, not just protocol design
