The main failure is scope leakage. If the IDE can reach everything the user can reach, then a local coding session can become a broad privilege bridge into documents, databases, and connected tools. That widens blast radius and makes accidental or malicious overreach harder to contain.
Why This Matters for Security Teams
When an IDE inherits broad workspace permissions through MCP, the problem is not just convenience, it is uncontrolled privilege multiplication. A coding session can suddenly read documents, query databases, inspect repositories, and invoke connected tools without a clean boundary between developer intent and system capability. That breaks the normal assumption that local tooling is low risk. Current guidance from the OWASP Agentic AI Top 10 and NHIMG research on Non-Human Identities points to the same issue: identity scope must match task scope, not user convenience.
The risk is especially high because MCP endpoints often inherit trust from the surrounding developer environment instead of enforcing explicit, per-tool authorisation. In practice, a prompt injection, malicious extension, or accidental misuse can turn a productivity feature into a data exfiltration path. NHIMG’s analysis of Analysis of Claude Code Security shows how quickly code-centric assistants can expand exposure when permissions are treated as ambient rather than constrained. In practice, many security teams discover the trust boundary only after an IDE session has already touched data it was never meant to reach.
How It Works in Practice
The safest model is to treat the IDE as a request broker, not as a standing authority. Instead of letting MCP inherit the full workspace, security teams should issue short-lived, task-scoped access that is evaluated at runtime. That means the IDE or agent presents a workload identity, the platform checks what it is trying to do, and policy decides whether that action is allowed right now. This is closer to intent-based authorisation than to classic role-based access control, which assumes stable human workflows.
In practice, the strongest pattern combines workload identity, JIT credentials, and policy-as-code:
- Use cryptographic workload identity so the platform can distinguish the IDE, the agent, and the user session.
- Issue ephemeral secrets only for the current task, then revoke them when the task ends.
- Limit MCP tool permissions to the smallest callable surface, not the entire workspace.
- Evaluate every sensitive request against context such as repository, environment, data class, and approval state.
This is consistent with the OWASP Non-Human Identity Top 10 and the State of MCP Server Security 2025, which reported that only 18% of mcp server deployments implement any form of access scoping for tool permissions. That statistic matters because broad inheritance turns every connected tool into a potential lateral-movement path. These controls tend to break down when MCP is wired into shared developer laptops or permissive enterprise workspaces because the surrounding environment already has more access than the session should ever inherit.
Common Variations and Edge Cases
Tighter MCP scoping often increases setup friction, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff is real, and current guidance suggests the answer is not to eliminate autonomy but to constrain it more precisely. In some teams, read-only access is enough for most workflows, while write actions need separate approval or a higher-assurance session. In others, especially multi-repo or data-heavy environments, a single “workspace permission” is already too broad to be safe.
Edge cases appear when the IDE bridges into SaaS tools, production-like databases, or shared knowledge stores. An agent may not need broad access permanently, but it may chain several narrow tools into a wider effect if runtime policy is weak. The AI Agents: The New Attack Surface report shows how often agents already exceed intended scope, which is why assumptions built around static roles fail quickly once tool use becomes autonomous. The emerging best practice is to separate user identity from workload identity and to treat every privileged MCP call as a new decision, not a continuation of the original login. There is no universal standard for this yet, but the direction is clear: keep privileges ephemeral, observable, and narrowly bound to intent.
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 | A2 | Covers agentic scope leakage and tool misuse from broad workspace permissions. |
| CSA MAESTRO | T1 | Addresses autonomous agent trust boundaries and privilege propagation. |
| NIST AI RMF | GOVERN | Supports governance for runtime decisions and accountability in agentic environments. |
Bind each MCP tool call to task intent and enforce least-privilege at request time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
