MCP governance defines the new control plane for AI agents

At a glance

What this is: This is an analysis of MCP governance and its role in controlling third-party and internal MCP servers that can execute actions through AI agents.

Why it matters: It matters because identity, access, and privilege controls now have to govern software actors that can call APIs, run code, and trigger automation inside enterprise systems.

👉 Read Akto's guide to governing third-party and internal MCP servers

Context

MCP governance is the control framework for Model Context Protocol servers that let AI agents use tools and data sources inside enterprise environments. The governance gap is that these servers are not passive integrations; they can execute actions, which means they create a new identity and access plane that traditional API management does not fully cover.

For IAM, PAM, and NHI teams, the practical shift is from approving static integrations to governing active execution surfaces. Third-party MCP servers need approval and provenance checks, while internal MCP servers need runtime restriction, observability, and re-validation as permissions, versions, and behaviour change.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

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. Every new tool expands the number of trust relationships and audit points. That makes lifecycle management, policy consistency, and observability harder to maintain than in a simpler API integration model.

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. A server can change version, expand permissions, or behave differently after approval, and the original review no longer reflects live risk. The result is unmanaged privilege drift.

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.

Technical breakdown

Why MCP servers create an execution surface

MCP turns an AI connection into an active tool boundary. Instead of only reading data, the server can make API calls, run code, read files, or trigger automation, which means every approved server becomes a potential execution path inside the enterprise. That is why the governance model has to treat MCP servers more like privileged software identities than simple integrations. The risk is not only misuse at install time, but behaviour drift after deployment when permissions, versions, or connected tools change.

Practical implication: treat each MCP server as a governed execution identity with explicit scope, owner, and revocation criteria.

Trusted registries and runtime controls for third-party and internal MCPs

A trusted registry is the allowlist layer that defines which servers are approved, who owns them, and under what conditions they may connect. Runtime control is the enforcement layer that limits OAuth scopes, isolates untrusted servers, and logs each tool execution with parameters and timestamps. Together, these controls separate approval from enforcement. That separation matters because an approved server can still become unsafe if its permissions expand, its code changes, or its runtime behaviour diverges from what was reviewed.

Practical implication: pair pre-approval with runtime enforcement, not one or the other.

MCP lifecycle governance is the missing operational layer

The article’s lifecycle sequence shows that governance must begin before production and continue after deployment. Submission, scanning, review, staging, approval, and continuous re-validation create an operating model for internal and third-party MCPs. This is the same pattern identity teams use for other privileged entities: define, review, restrict, observe, and revoke. The failure mode is unmanaged drift, where a server remains trusted after the conditions that justified trust have changed.

Practical implication: embed MCP review and re-validation into the same lifecycle discipline used for other high-risk non-human identities.

Threat narrative

Attacker objective: The objective is to turn trusted AI connectivity into a controllable execution path for unauthorised actions in enterprise systems.

1. Entry occurs when developers connect AI agents to production systems through an MCP server that has been added to the environment without sufficient provenance or review.
2. Escalation follows when the server is granted tool access that lets it call APIs, run code, read files, or trigger automation beyond the intended scope.
3. Impact occurs when compromised or misgoverned agent behaviour uses those permissions to move from assistance into unauthorised execution inside corporate systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Trusted approval is not the same as safe runtime behaviour. The article’s registry model addresses provenance and initial approval, but risk does not end there. Once an MCP server can call APIs or trigger automation, permission drift and behaviour drift become the real control gaps. The implication for IAM and PAM teams is that approval workflows without runtime restriction leave a false sense of containment.

Third-party and internal MCPs need different governance, but the same accountability model. Third-party servers demand vetting, version pinning, and revocation. Internal servers demand telemetry, continuous scanning, and periodic re-validation. The named concept here is execution-surface governance: treating every tool-capable MCP server as an active access boundary that must be owned, approved, observed, and removable. Practitioners should align ownership to the server lifecycle, not the AI project.

Agent security is now identity governance with tool execution attached. When an AI agent is allowed to act through MCP, the question becomes how much authority the agent can exercise and whether that authority is bounded in real time. Static approval models were designed for predictable integrations, not for software that can decide when and how to execute. Identity teams should assume the control boundary has moved closer to runtime.

From our research:

• 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.
• For lifecycle and audit context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the control model that keeps non-human access governable.

What this signals

With 71% of NHIs not rotated on time, the governance lesson is that approval-centric models fail when identity state changes faster than review cycles. MCP governance needs the same lifecycle discipline that identity teams use for service accounts, secrets, and other privileged non-human access.

Execution-surface governance: treat every tool-capable MCP server as a removable control point, not a one-time exception. That framing helps IAM, PAM, and security operations coordinate ownership, logging, and revocation without assuming the server will remain benign after approval.

For practitioners

• Define a trusted MCP registry Create a single allowlist of approved MCP servers with name, owner, source, version, and approval status. Reject any connection that is not on the list and review the registry on a fixed cadence so unused or stale entries are removed.
• 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. Re-run scanning, review signatures or hashes, and confirm the deployed server still matches the approved configuration before it reaches production.
• Assign explicit owners for every MCP server Map each server to a business or platform owner who can approve access, answer audit questions, and revoke trust when the server is retired, replaced, or no longer aligned to business need.

Key takeaways

• MCP governance is an identity problem because MCP servers can execute actions, not just exchange data.
• Approval alone is insufficient when versions, scopes, and tool behaviour can drift after deployment.
• The practical control model combines trusted registries, runtime restriction, audit evidence, and explicit ownership.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Execution surface: An execution surface is any system or environment where an identity can actually do work, such as an application, trigger, endpoint, or API. For AI agents, execution surfaces matter because risk appears where action is taken, not only where authentication occurs.
• Trusted registry: A controlled source of tool definitions that has been reviewed, curated, and tied to policy before a model is allowed to use it. In MCP environments, registry trust matters because the discovery path can be attacked before the execution path ever begins.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.

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.

👉 Akto's full post covers the registry model, runtime guardrails, and MCP lifecycle controls in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.