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.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “What Is AI Governance: A Framework for Enterprise MCP Teams”.
Key questions
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task.
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
- Define MCP approval criteria Specify who can register servers, what disclosures are required, and what changes force re-review before an agent can reach the tool.
- Inventory every reachable MCP server Track approved and informal servers together so shadow tool access does not sit outside governance or audit scope.
- Scope access by server reach Classify each server by the systems it can touch, then set access boundaries based on that reach rather than on model identity alone.
Bottom line: Mainstream AI governance can still leave MCP tool calls outside the control boundary, which means approved models may operate through unvetted runtime actions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Model-centric AI governance is structurally incomplete once agents can call tools. The common assumption in current programmes is that governance ends where the model ends, because that is where most risk reviews were designed to operate. MCP breaks that boundary by moving decisions into a runtime tool layer. The implication is not that AI governance is wrong, but that it is incomplete unless tool invocation is treated as part of the governed identity surface.
A few things that frame the scale:
- 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, according to the 2026 Infrastructure Identity Survey.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should organisations do when an AI agent can call tools outside the model boundary?
A: They should add a separate governance layer for tool registration, runtime monitoring, and audit trails. The question is not whether the model is safe in isolation, but whether the agent can take an action through an external server without explicit oversight. If the answer is yes, the AI programme is incomplete.
👉 Read our full editorial: MCP governance stops at the model boundary: what teams miss