The most privileged software on a developer laptop used to be the compiler. It is now an assistant that can decide to run the compiler, and everything else, on its own.
Why AI Coding Assistant Security Matters Now
A developer laptop is the densest position in the enterprise: source code, cloud credentials, package registry tokens, SSH keys, and a shell. For twenty years, EDR, DLP and code review were sized against a human typing commands at human speed. An AI coding assistant in agent mode changes the counterparty. It reads files, plans, and executes terminal commands, and the approval prompt is the only thing standing between a suggestion and an action.
The uncomfortable part is where the dial sits out of the box. In the enterprise defaults we have reviewed for VS Code-based environments, agent mode is enabled, MCP servers are permitted from any source, and rule-based terminal auto-approval is switched on. That is a default posture of “yes,” not “ask.”
| Signal | Figure | Source |
|---|---|---|
| MCP servers present in cloud environments | ~80% | Wiz research |
| AI IDE extensions present in cloud environments | 80% or more | Wiz research |
| Enterprises with agents in use that IT did not sanction | 88% | Ospiri published research |
| Added breach cost attributed to shadow AI | +$670K | Ospiri published research |
If four out of five environments already carry the exposure, this is not a tail event to hedge. It is the base case, and the question is how much of it you can see.
Defaults vs Policy: The Comparison
Most security teams review the assistant the way they review any SaaS tool: vendor questionnaire, SOC 2 report, data-handling addendum. Those answer where your code goes. They do not answer what the assistant is allowed to do on the machine. Let’s step back and separate the two books.
| Control surface | Where the default sits | What it means in practice |
|---|---|---|
| Agent mode | Enabled | The assistant can chain edits and commands without a human in each step |
| MCP server sources | Allowed from all sources | Any developer can attach a third-party tool server with local reach |
| Terminal auto-approve | Rule-based approval on | Commands matching a rule run with no prompt |
| Extension installs | Marketplace open | New agent capabilities arrive with a click |
| Telemetry to security | None native | The SIEM sees the network edge, not the tool call |
None of these settings is exotic. Each is a convenience that a developer would reasonably want. The risk is that the sum of conveniences is an autonomous process with shell access and no named owner.
Anatomy of a Failure: Four Steps From Convenience to Incident
Incident patterns in this category are boring, which is why they work. A prompt-injected README, a poisoned dependency description, or a malicious MCP tool response gives the assistant an instruction that looks like context. The sequence is repeatable.
- Ingest. The assistant reads untrusted content: an issue, a repo, a web page, a tool result.
- Reinterpret. Instruction and data blur, and the content is treated as a task.
- Match. The resulting command fits an auto-approve rule, so no human is prompted.
- Exfiltrate or persist. Credentials are read from the home directory, a script is fetched, or a new MCP server is registered for the next session.
The control that matters sits at step three. Input filtering at step one is a treadmill, because every new encoding spawns a new rule. Approval at step three is a policy decision, and policy that is enforced on the device is the only version that survives a prompt injection.
The Exposure Formula
Treat the assistant like a position, not a product. The exposure is a function of how much it can reach and how often it acts without a human.
Assistant Exposure = (Reachable Credentials × Auto-Approved Command Rate) + (Unvetted MCP Servers × Data Sources Touched)
| Factor | How to measure it | Owner |
|---|---|---|
| Reachable credentials | Tokens, keys and cloud profiles readable by the assistant process | Endpoint / IAM |
| Auto-approved command rate | Share of terminal actions executed without a prompt | Platform engineering |
| Unvetted MCP servers | Configured servers with no approval record or signature | Security architecture |
| Data sources touched | Repos, drives and SaaS tenants actually reached | Data governance |
Each factor is a count with a name next to it. That is what makes the formula useful: it converts an argument about whether developers should be trusted into a number you can trend.
What This Requires: Controls at the Point of Action
Managed settings help, and you should use them. They lock the dials you can see. They do not cover the unsigned skill pulled from GitHub, the MCP server launched over stdio that no proxy ever observes, or the extension that adds a new capability on Tuesday. The gap is architectural: configuration describes intent, and only the endpoint observes behavior. For the stdio case specifically, see our note on the MCP server your proxy will never see, and for the sprawl problem, governing the MCP sprawl.
| Requirement | Configuration-only approach | Runtime enforcement approach |
|---|---|---|
| Terminal commands | Allow-list rules, auto-approve on match | Per-action verdict on the device, with a block that holds |
| MCP servers | Source setting in the IDE | Inventory and allow/deny at process level, including stdio |
| Credentials | Hope the path is unreadable | Deny reads outside the sanctioned scope |
| Evidence | Settings export | Per-action log an auditor can hold |
This is the logic behind an agent firewall: enforcement at the kernel boundary, where the action actually lands, rather than at the prompt. It is also why agent security is a runtime discipline and not a questionnaire.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1. Inventory | Enumerate AI IDEs, extensions and configured MCP servers across endpoints | Named list with owners | 1-2 weeks |
| 2. Reset defaults | Turn off blanket terminal auto-approve; restrict MCP sources to an approved list | Managed settings baseline | 1 week |
| 3. Measure | Baseline the exposure formula: credentials reachable, auto-approved rate, unvetted servers | One trended number | 2 weeks |
| 4. Enforce | Move the approve/deny decision from the IDE setting to the endpoint | Per-action evidence | First quarter |
The Bottom Line
An AI coding assistant is a privileged process whose security posture is set by convenience defaults, and a prompt is not a control. The settings you can see are worth locking, but the exposure lives in what runs after the setting says yes. If your team is sizing this for the next planning cycle, request a working session. We will walk through your developer estate, produce the exposure baseline, and scope a deployment. Expect a first read in two weeks.