Notifications
Clear all
Topic starter
19/08/2026 4:07 pm
TL;DR: MCP server usage in Cursor creates a governance gap because developers can wire up approved and unapproved tools, reuse personal access tokens, and expose enterprise secrets without standardised visibility, according to Stacklok. The real issue is not whether AI automation is useful, but whether organisations can govern tool execution, audit access, and prevent disallowed MCP calls without breaking developer workflows.
NHIMG editorial — based on content published by Stacklok: Governing MCP Servers in Cursor with Stacklok
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Enforce execution-time deny controls Intercept agent tool calls before they execute and deny any server that is not explicitly authorised.
- 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.
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.
👉 Read Stacklok's blog post on governing MCP servers in Cursor →
MCP server governance in Cursor: are your controls keeping up?
Explore further
19/08/2026 4:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server governance in Cursor needs execution-time controls
