MCP server governance in Cursor needs execution-time controls

At a glance

What this is: This is Stacklok’s analysis of governing MCP servers in Cursor, with the key finding that execution-time policy, audit logging, and curated approval are needed to stop unmanaged tool use.

Why it matters: It matters because MCP servers sit directly in the path between AI-assisted development and enterprise systems, so IAM, PAM, and NHI teams need controls that work at tool execution time, not just at onboarding.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Stacklok's blog post on governing MCP servers in Cursor

Context

MCP server governance is the problem of controlling which AI-connected tools can run, what data they can touch, and how their use is logged. In Cursor, that problem becomes an identity governance issue because the agent can call real systems through tools that may be approved, copied from chat, or introduced without central review.

The security gap is familiar to NHI teams: unmanaged tool identities, reused tokens, and unclear execution boundaries create shadow access inside development workflows. When the control model cannot see which MCP servers are running, it cannot enforce policy, prove accountability, or limit blast radius.

That makes MCP governance relevant to both NHI and human IAM programmes. The question is no longer whether developers can move faster with AI-assisted tooling, but whether the organisation can preserve control when the toolchain itself becomes an access path.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do MCP deployments increase identity and access risk?

A: MCP increases risk because it connects untrusted model output to real systems that can act on it. That creates new paths for token exposure, overbroad authorization, rogue endpoints, and confused deputy behaviour. The issue is not AI novelty, but the expansion of machine-to-machine trust at runtime.

Q: What breaks when MCP tool access is only reviewed at install time?

A: Install-time review fails because the real risk appears when the agent executes a tool call. A server can be approved in name yet expose disallowed tools, unexpected arguments, or changed behaviour later. Execution-time controls are needed because tool identity and tool behaviour can diverge after installation.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

What end-to-end observability changes for NHI oversight

The article’s logging model uses OpenTelemetry to capture downloads, tool usage, and error rates, then forwards those signals into enterprise observability stacks. That closes the gap between tool approval and tool behaviour, which is where many NHI governance failures occur. If a server is approved but behaves unexpectedly, logs and metrics provide the evidence needed for review, incident triage, and policy tuning. Without that telemetry, organisations are left with approval records but no behavioural proof.

Practical implication: require telemetry for tool downloads, invocations, and failures so governance can be verified in operation.

NHI Mgmt Group analysis

Execution-time governance is the real control boundary for MCP. The article shows why pre-install approval alone is insufficient once a Cursor agent can invoke tools during live work. Governance must exist at the point of execution, because that is where unapproved access becomes operational access. For practitioners, the lesson is that MCP policy must be enforced where the agent acts, not where the developer first discovers the tool.

MCP governance is an NHI problem before it is an AI problem. The central risk is not model intelligence, but unmanaged tool identities, reused tokens, and secrets flowing through non-standard execution paths. That is the same structural issue IAM teams see with service accounts and API tokens: access exists outside the normal lifecycle and escapes central visibility. The practical implication is that NHI controls must extend into developer AI tooling.

Identity blast radius for MCP tools: the dangerous unit is not the server alone, but the combination of server, token, and context. When tools are exposed inside the agent’s working context, the model can be steered toward actions the organisation never intended to make available. That creates a larger blast radius than a simple allowlist problem, because the context itself becomes part of the trust surface. Practitioners should treat tool exposure as a governance boundary, not just a configuration choice.

Observability without policy is not governance, and policy without telemetry is not assurance. Stacklok’s design points to the right operating model: curate, enforce, and log. The broader market signal is that enterprises are moving toward control stacks that combine registry, runtime, gateway, and audit trail rather than treating MCP as a lightweight integration layer. Security teams should expect MCP governance to converge with existing NHI and PAM operating models.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how immature tool governance still is across the category.
• For a broader operating model, see Top 10 NHI Issues, which frames the lifecycle and control failures that MCP tooling now exposes.

What this signals

Identity blast radius: MCP governance will increasingly be judged by how quickly teams can narrow the set of tools an agent can even see. Once blocked tools never enter the agent context, organisations reduce both misuse risk and the chance that disallowed capabilities become part of runtime reasoning. That is a stronger control posture than simple post-execution monitoring.

The practical direction for programmes is clear: treat MCP tooling like any other non-human access estate, with ownership, approval, telemetry, and offboarding. If your development platform cannot answer which tools were used, by whom, and under what policy, you do not yet have governance. That gap will matter more as AI-assisted coding moves deeper into production workflows.

For practitioners

• Establish an approved MCP registry Create a central catalog of sanctioned MCP servers, verified configurations, and ownership metadata before developers are allowed to self-install anything. Use the registry as the source of truth for tool approval and offboarding.
• Enforce execution-time deny controls Intercept agent tool calls before they execute and deny any server that is not explicitly authorised. Pair the deny decision with a clear message so developers understand why the call was blocked.
• Log server usage and tool arguments Capture downloads, invocations, tool names, and arguments in a central telemetry pipeline so security teams can correlate policy decisions with actual behaviour. Feed those events into existing observability and SIEM workflows.
• Remove plaintext secrets from runtime paths Require encrypted secret handling in any MCP runtime and prohibit servers that rely on copy-pasted tokens or plaintext credential injection. Review where developer tooling can inherit enterprise secrets without an explicit governance check.

Key takeaways

• MCP servers create a new governed access layer inside developer workflows, and that layer needs execution-time control.
• Hard-coded secrets and missing tool scoping show that MCP security remains immature, especially where identity and runtime policy are not aligned.
• The strongest operating model combines curated approval, deny-by-default execution, and telemetry that proves what tools were actually used.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Execution-time control: A policy or guardrail that blocks or restricts a tool while it is running, before it can read secrets, execute commands, or exfiltrate data. For developer environments, execution-time control is the difference between observing a malicious artifact and stopping it from doing harm.
• Tool Context: Tool context is the set of capabilities, arguments, and accessible functions available to an AI agent during a session. When blocked tools are removed from context, the agent cannot select them, which reduces the chance of disallowed actions becoming part of runtime behaviour.
• Curated Registry: A curated registry is a governed catalog of approved tools or services with verified configurations and ownership. In NHI and AI tooling programmes, it functions as the control point for sanctioned discovery, installation, and lifecycle management.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Cursor Hook flow used to approve or deny MCP execution requests.
• How the registry, runtime, gateway, and portal components are wired together in the enterprise platform.
• The OpenTelemetry events and metrics Stacklok says can be forwarded into Grafana or Splunk.
• How the macOS and Linux hook deployment model is intended to work in managed environments.

👉 Stacklok's full post covers the Cursor Hook flow, registry model, and telemetry details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.