Plugin policy, browser controls, and approved IDE access reduce exposure. They do not finish the decision about whether an already-allowed workflow should take the next action now.
Quick answer
AI IDE security should include plugin policy, environment scoping, browser and extension hygiene, repository trust boundaries, MCP/tool connector review, and a runtime-trust check before the next action.
If your model can read code, suggest commands, call tools, follow callbacks, or push traffic to other systems, then AI IDE security is not finished when access has been approved. The real last-mile question is whether the latest diff, tool response, redirect, extension message, MCP handoff, or outbound target has quietly changed what the workflow believes it should do.
Plain-language explainer
In plain language, AI IDE security means protecting the place where coding agents and human developers share context. A browser tab may feed instructions into a plugin. A plugin may summarize a repository and suggest a command. A command may call a tool. A tool may return text that points the workflow to a new endpoint, a new file, or a new action. None of that looks dramatic on its own. But taken together, it can quietly reshape authority.
That is why this category matters now. Modern developer workflows are no longer just an editor and a git remote. They are stitched together from assistants, browser surfaces, extensions, test runners, repo analyzers, MCP-connected tools, and web-linked helper flows. The same workflow can move from IDE to browser to tool output to callback chain in seconds.
The first layer of security still matters a lot:
- which plugins are installed
- which repos can be read
- which browser surfaces are allowed
- which tools can execute commands
- which external endpoints can be reached
But once those controls are present, the failure mode becomes more subtle. The workflow can remain inside nominal policy while still inheriting unsafe authority from a new suggestion, a new diff, a connector description, or a tool response that starts acting like instruction. The AI Agent Hardening Manual covers the full defensive stack — IDE security sits at the top of that stack as the action-time verification layer.
What usage control really solves — and what it does not
There is a fair first sentence here: usage control is real progress. If a team can narrow which AI tools are allowed, which browser interactions are permitted, which extensions can run, and which environments can be touched, that lowers exposure immediately. It can reduce shadow usage, stop obviously risky connectors, and make the environment more governable.
But AI IDE security fails when teams stop there. Access and policy answer what may exist. They do not fully answer what should happen next.
| Control layer | What it helps with | What still remains open |
|---|---|---|
| Plugin allowlisting | Reduces obvious extension sprawl | Whether plugin output is quietly reshaping the next action (GLS-TOP-237) |
| Browser or session policy | Limits risky pages and sessions | Whether a redirect, embedded instruction, or extension callback should still be trusted |
| Tool scoping and MCP policy | Restricts reachable tools and services | Whether handoff text, tool metadata, or intermediate responses are expanding authority mid-run (GLS-MCP-POISON-201) |
| Endpoint allowlisting | Constrains where traffic can go | Whether the chosen action is still appropriate in context after new signals arrive |
That remaining column is the runtime-trust problem. It is where Sunglasses belongs in the stack. The CVP evaluation framework is how we publish independent, reproducible tests of Sunglasses' detection coverage against authority-drift scenarios like these.
Three concrete AI IDE security failures
1) The plugin suggestion that becomes authority
A coding assistant plugin reads the repo and proposes a command to "fix" a build issue. The plugin is approved. The IDE session is approved. The repository is allowed. Nothing looks broken at the policy layer.
Then the suggestion quietly expands scope: it adds a new package source, changes where secrets are read from, or recommends a command sequence that reaches further than the original task required. The dangerous part is not only the command itself. It is the moment the workflow starts treating the plugin's generated explanation as authority over the next step.
That is an AI IDE security failure because the workflow stayed inside an allowed environment while the trusted action boundary moved. Sunglasses pattern GLS-TOP-237 (tool output trusted override) is designed to catch exactly this vector — text inside tool responses that attempts to elevate its own authority.
2) The browser-to-IDE handoff that changes intent
A developer or agent opens documentation, an issue thread, or a browser-based helper inside the same working loop. The browser surface is allowed. The extension is installed intentionally. The assistant pastes content back into the IDE and uses it to shape code changes or tool calls.
The risk appears when that content is no longer just reference material. It starts steering behavior: follow this redirect, use this mirror, trust this callback, or run this "temporary" recovery command. The workflow sees familiar approved surfaces, but the meaning of the next action has changed.
This is exactly why AI agent sandboxing vs runtime trust and AI IDE security are now overlapping surfaces. The browser is not outside the developer workflow anymore. It is one of the places where runtime trust gets rewritten. See the FAQ for common questions about where this boundary sits in practice.
3) The MCP-connected tool chain that stays in scope on paper
An IDE assistant can call approved tools through connectors or MCP-style integrations. Every endpoint looks valid on paper. Credentials exist. The tool is in policy. The agent is "allowed."
Then a tool description, response block, or intermediate handoff quietly shifts where the workflow goes next: a broader project, a different destination, a new callback path, or a higher-authority action than the original task justified. This can happen without any one step looking outrageous in isolation.
Pattern GLS-MCP-POISON-201 (MCP tool manifest poisoning) covers this attack vector. Pattern GLS-CAI-248 (delegation token revocation bypass) covers the delegation-handoff variant — where a delegation token or approval receipt is already revoked, expired, or mismatched, and the incoming content instructs the agent to ignore the revocation and execute anyway. That is why hardening and MCP security still need a runtime-trust layer even after the permission check has passed.
How Sunglasses catches it
Sunglasses is not trying to replace plugin policy, IDE governance, browser controls, or IAM. Those are upstream controls. Sunglasses fits at the moment where trust-bearing text and metadata still need review before the workflow acts.
That means looking for patterns like:
- text that quietly overrides earlier constraints
- tool responses that act like new policy (GLS-TOP-237)
- connector or MCP descriptions that blur scope boundaries (GLS-MCP-POISON-201)
- action-shaping instructions hidden inside ordinary-looking content
- revoked or expired delegation handoffs the content tells the agent to honor anyway (GLS-CAI-248)
If usage control answers "what can this environment reach," Sunglasses helps answer "what should this workflow still trust after it just read this new thing?" That is the missing second sentence on most AI IDE security pages.
For teams already using the AI Agent Security 101 guide as the broad explainer, this is the narrower workflow-specific extension: developer tools, plugins, browser handoffs, and MCP-connected helpers still need an action-time trust decision. How Sunglasses works with Cursor shows exactly where these checks plug into a real IDE-agent workflow.