Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: As enterprises connect AI agents to production systems through MCP, governance shifts from model safety to controlling which servers run, who approves them, and what they can do, according to Akto. The real issue is not hallucination but agent compromise through executable tool access and weak runtime guardrails.
NHIMG editorial — based on content published by Akto: What Is MCP Governance? A Guide to Govern MCPs (third-party and internal)
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP environments create more identity risk than standard API integrations?
A: MCP environments increase identity risk because they add tool discovery, delegated access, and multiple authentication paths on top of existing APIs.
Q: What breaks when MCP governance stops at approval and ignores runtime behaviour?
A: Approval without runtime control leaves a gap between what was reviewed and what actually executes.
Practitioner guidance
- Define a trusted MCP registry Create a single allowlist of approved MCP servers with name, owner, source, version, and approval status.
- Enforce runtime restrictions on tool-capable servers Limit each MCP server to the smallest practical OAuth scopes, isolate untrusted servers in sandboxes or containers, and log every tool execution with parameters, timestamps, and responses for SIEM review.
- Require re-approval on version or permission change Treat new releases, dependency changes, and expanded permissions as governance events.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- The exact approval workflow for third-party MCP servers, including manifest review and version pinning.
- The implementation details for runtime logging, sandboxing, and scope restriction across server types.
- The suggested lifecycle checkpoints for scanning, staging, production approval, and re-validation.
- The team roles and ownership split used to keep MCP governance accountable over time.
👉 Read Akto's guide to governing third-party and internal MCP servers →
MCP governance for AI agents: are your controls keeping up?
Explore further
02/08/2026 1:21 pm
MCP governance is becoming the missing control plane for non-human execution. When AI agents connect to enterprise systems through MCP, the issue is no longer just model output quality. The governance problem is who can connect, under what scope, and whether the server can execute actions at all. That makes MCP governance an NHI discipline with runtime consequences, not a documentation exercise. Practitioners should treat each server as a governed identity with privileged effects.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity sprawl outpaces governance maturity.
A question worth separating out:
Q: Who should be accountable for risky MCP actions in enterprise environments?
A: Accountability should follow the full delegation chain, not just the token holder. That means the delegating human, the agent or client, the policy owner, and the approver must all be visible in the audit record when a high-impact action occurs. Without that chain, compliance and incident response lose the evidence needed to explain why the action happened.
👉 Read our full editorial: MCP governance defines the new control plane for AI agents
