The governance model breaks because the organisation loses control over which tools are callable at runtime. Approved-server lists do not stop developers from connecting new servers, reusing personal tokens, or exposing enterprise secrets through a workflow that security teams cannot easily observe or reconstruct.
When runtime tool access escapes change control
The break is not just technical access, it is the control plane that decides which tools are allowed to act on behalf of the organisation. If developers can attach unvetted mcp server inside Cursor, the environment can drift from approved integrations to ad hoc runtime authority, which changes the risk from simple software choice to uncontrolled execution paths.
That matters because MCP is not merely a transport, it is a way to expose callable capabilities to an AI-enabled workflow. The practical issue is whether the organisation can still say who may connect which server, what the server can invoke, and whether the resulting tool path is visible enough to audit later.
As a result, server approval becomes a weak signal unless it is enforced at the point of connection and use. A list of approved servers cannot stop a developer from wiring in a different server, passing through a personal token, or creating an enterprise workflow that security teams never see in a reliable inventory.
Where governance fails first
Governance fails at the boundary between sanctioned platforms and developer autonomy. Once the IDE can reach arbitrary MCP servers, tool choice becomes local and immediate, while policy, review, and exception handling remain upstream and slower. That gap is where shadow integrations appear.
The second failure is accountability. If the server can call external tools, read context, or relay credentials, then incident responders need to know not only what the user did, but which server, token, and downstream service were involved. Without that trace, ownership becomes disputed and reconstruction becomes partial.
OpenAI-style or IDE-style approval models also break down when the runtime can be altered by the person holding the keyboard. Security teams may approve a narrow set of servers, but the developer experience can still permit personal tokens, local configuration drift, or reconfiguration that is invisible to central policy enforcement.
Why unvetted MCP servers expand the attack surface
An unvetted MCP server can behave like a trusted integration while actually expanding data exposure, credential exposure, or action scope. That is why the MCP authorization specification matters: it is designed to keep tokens audience-bound and avoid token passthrough, which reduces the chance that one server inherits authority it should not have.
The attack path is usually indirect. A malicious or careless server can receive context, prompt content, secrets, or API tokens, then relay them to another system or use them to invoke actions the user did not intend. That pattern is especially dangerous in coding tools because developers tend to trust anything that looks like a productivity extension.
For agentic workflows, the relevant failure is identity and privilege abuse rather than a generic extension problem. The model is simple: if the server can act with credentials the organisation did not explicitly intend for that server, the blast radius is no longer bounded by the original IDE session.
What practitioners should do before letting developers connect anything
What to verify: Verify that MCP server registration, approval, and enforcement happen at the point of connection, not only in policy documentation. If a developer can add a server locally and still call enterprise tools, the control is advisory rather than preventive.
Decision rule: If the server can access secrets, production systems, or write-capable tools, treat it as an approved integration problem, not a personal productivity choice. Require explicit ownership, scoped credentials, and an audit trail that ties server actions back to a named business purpose.
What to measure: Measure how many servers are connected outside approved channels, how often personal tokens appear in IDE workflows, and whether each server connection can be reconstructed from logs after the fact. If you cannot answer those questions, governance is already broken.
NHIMG’s MCP Security Guide is the most direct practical reference for the server approval and token-boundary problem, while the AI Coding Agents Security Guide covers the developer workflow risks that make these failures easy to introduce.
For teams designing guardrails around the broader agent stack, the OWASP Agentic Applications Top 10 helps frame tool misuse and privilege abuse as first-order risks rather than edge cases.
Practitioner takeaway: The real control failure is not “developers can install a server”, it is that runtime authority becomes ungoverned unless connection, credential scope, and observability are enforced together.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Cursor-connected MCP servers can inherit or misuse runtime authority. |
| Recommendation — Constrain server and tool permissions to prevent runtime privilege abuse. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue includes personal tokens and secret handling across runtime integrations. |
| AC-6 — Least Privilege | Unvetted servers can expand tool access beyond intended permissions. | |
| Recommendation — Manage and rotate tokens used by IDE-connected servers and agents. Apply least privilege to every server, token, and downstream tool path. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The question is about enforcing who can call which tools at runtime. |
| Recommendation — Enforce least privilege for runtime tool connections and delegated actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Servers that can invoke enterprise tools can bypass intended action boundaries. |
| Recommendation — Authorize each callable function and block unauthorized tool invocation. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org