Subscribe to the Non-Human & AI Identity Journal

How should security teams govern MCP in enterprise environments?

Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Why This Matters for Security Teams

MCP should be governed as a live authorization boundary, not as a convenience layer for copilots and toolchains. The risk is not just data exposure, but agentic execution: a model can select tools, chain actions, and expand impact faster than a human reviewer can intervene. Current guidance suggests treating every invocation as a decision point, with ownership, policy, and auditability attached to the agent, the tool, and the context passed between them.

That matters because static RBAC alone does not describe intent. An AI agent may have valid access to one system, yet still misuse that access when it is given richer context than the task requires. NHIMG research on OWASP Agentic Applications Top 10 and OWASP Agentic AI Top 10 both point to the same problem: autonomous systems create security decisions at runtime, not just at login. In practice, many security teams discover that gap only after an agent has already chained tools and touched data it was never meant to reach.

How It Works in Practice

Enterprise MCP governance works best when identity, policy, and telemetry are attached to each agentic action. Start by assigning a named owner to every agent, MCP server, and tool integration. Then replace standing access with just-in-time, short-lived credentials for each task, so the agent can complete work without holding reusable secrets. That approach aligns with NHI lifecycle discipline described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with the audit focus in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

Use workload identity as the root trust primitive for agents, not static API keys alone. In practice, that means cryptographic identity, token exchange, and policy-as-code checks that evaluate the request in context. NIST’s NIST Cybersecurity Framework 2.0 supports the broader governance posture, while runtime decision models should map to what the agent is trying to do, what it is allowed to see, and which downstream systems it may reach. A useful control pattern is:

  • Bind each agent to a unique workload identity.
  • Issue ephemeral secrets per task, then revoke them on completion.
  • Evaluate tool calls at runtime with intent-aware policy.
  • Minimise context so only task-relevant data crosses the boundary.
  • Log every invocation, response, and downstream hop for audit and response.

SailPoint’s AI Agents: The New Attack Surface report found that 80% of organisations reported AI agents had already performed actions beyond intended scope, which is why MCP governance must assume that tool chaining can become lateral movement. These controls tend to break down when MCP servers are bolted into legacy automation stacks that still depend on long-lived secrets and broad service accounts because the agent inherits too much power before policy can intervene.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff is real, especially where teams want low-friction experimentation but still need defensible governance. Best practice is evolving, but there is no universal standard for intent-based authorisation in MCP yet, so teams should document which policy engine is authoritative and how exceptions are approved.

Edge cases show up quickly in multi-agent pipelines, delegated tool use, and shared MCP servers. If several agents use the same server, a single permissive connector can become a privilege amplifier. If a workflow requires broad read access but limited write access, separate those paths instead of granting one generic role. For mature programs, Top 10 NHI Issues and Analysis of Claude Code Security are useful references for how identity sprawl and tool trust failures surface in practice.

Where the environment mixes regulated data, high-trust production systems, and rapidly changing prompts, the safer path is to pair zero standing privilege with per-action approvals or narrow JIT grants. OWASP Top 10 for Agentic Applications 2026 and the agent governance patterns in Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same point: if the agent can decide, chain, and act autonomously, the control plane must be designed for unpredictability, not only for policy compliance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 A1 Agentic tool abuse and runtime misuse are central to MCP governance.
CSA MAESTRO GOV-02 MAESTRO emphasises governance and runtime control for autonomous agents.
NIST AI RMF AI RMF supports accountable governance for autonomous, high-impact AI behaviour.

Use AI RMF GOVERN and MAP functions to define policy, oversight, and escalation paths.