Notifications
Clear all
Topic starter
18/08/2026 2:22 pm
TL;DR: Enterprise AI governance frameworks such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001 were built to govern models, but they leave MCP tool calls outside the review boundary, according to Obot. The practical problem is not model oversight but runtime tool governance: once an agent can discover and call tools, organisations need policy, registration vetting, monitoring, and audit trails for the tool layer.
NHIMG editorial — based on content published by Obot: MCP governance beyond the model boundary
By the numbers:
- Only 19% of organisations have full visibility into AI usage.
- 80% of business leaders cite explainability, ethics, bias, or trust as a major roadblock to generative AI adoption.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
Questions worth separating out
Q: How should security teams govern MCP agents that can switch between tool calls and generated code?
A: Security teams should treat tool calls and generated code as separate execution modes with different control requirements.
Q: Why do model governance frameworks miss MCP risk?
A: Because they were designed to classify and review models, not the runtime actions that happen after a model discovers a tool.
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.
Practitioner guidance
- Inventory every reachable MCP server Build a live register of every server an agent can discover or call, including owner, purpose, data reach, and change history.
- Classify tools by reach and side effects Assign risk based on what each tool can touch, whether it can write state, and what approvals are needed before execution.
- Separate model approval from tool approval Keep model review, tool registration, and entitlement approval as distinct governance steps so an approved model cannot implicitly inherit unreviewed tool access.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- A layer-by-layer MCP governance model showing how policy, registration, runtime monitoring, and audit trails fit together.
- A practical maturity model for organisations that need to decide which MCP servers require stricter approval and monitoring.
- Specific discussion of CVE-2026-32211 and why a model-level governance programme would miss the control failure it exposed.
- Implementation detail on how Obot positions gateway-layer enforcement, credential brokering, and exportable logs for MCP.
👉 Read Obot's analysis of MCP governance beyond the model boundary →
MCP governance gaps: are your agent tool controls keeping up?
Explore further
18/08/2026 3:13 pm
Model governance without MCP governance is an incomplete control plane. The article is right to separate governance of the model from governance of the tool layer because the runtime decision to call a server is a different identity event. EU AI Act, NIST AI RMF, and ISO/IEC 42001 all help with model accountability, but they do not by themselves answer who approved a tool call or what side effect it produced. For practitioners, that means the programme boundary must move from model review to action governance.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Who should own MCP gateway governance in an enterprise AI programme?
A: Ownership should sit with the teams responsible for identity, security architecture, and platform governance together, because MCP gateways span access control, routing, and observability. Treating the gateway as only a network component leaves policy gaps. Treating it as only an AI platform feature leaves accountability unclear.
👉 Read our full editorial: MCP governance stops at the model boundary: what teams miss
