An agentic IDE is a new class of tool, and along with its convenience it brings an attack surface that is easy to underestimate. The same agent reads untrusted text, runs commands in your shell, reaches the network through MCP and edits repository files. Each of these abilities is at once the benefit the whole thing was built for and a channel through which something can go wrong. A threat model here starts not with paranoia but with an honest list of what the agent can touch at all.
The naive move is understandable and almost always first: write good instructions and assume that is enough. A strict, polite, detailed wording in the prompt or in AGENTS.md feels like control - it seems that if you clearly tell the agent what not to do, it will not do it. Most early setups rest on this confidence: control lives in text.
It breaks on a simple fact: the text the model reads can persuade it. Prompt injection is not exotic but a comment in the code, a line in a README, a docstring or a test addressed no longer to a human but to the agent, asking it to do the wrong thing. A model is by nature open to persuasion, and that is exactly why persuasion must not change your security decisions. An instruction shapes behavior but is not a boundary: a boundary cannot be stated in words inside the very thing the agent interprets.
It helps to lay the sources of risk out in rows, so each gets its own control rather than a general call to be careful. An untrusted repository carries injections and harmful scripts; the agent's output - bugs, insecure patterns and hallucinations; the shell - destructive and external effects; MCP and ACP - data disclosure and third-party actions; the cloud - access to the repository, the network and secrets; a plugin or extension - supply-chain execution. Below this map is gathered into a source - risk - control table.
The professional mechanism is to separate influence from enforcement. Instructions help behavior and stay useful, but enforcement comes from other things: permissions, hooks, the sandbox, branch protection and approvals. They work by system means, not by the model's goodwill, and so do not depend on whatever text the agent read along the way. The practical technique is one: whatever can be expressed as a rule, move out of the prompt into a permission, a hook or the sandbox - there it becomes a boundary rather than a wish.
Why this rather than simply a stricter prompt. Because a prompt, to a model, is data it interprets, not a guarantee of execution. Cognition warns directly that Devin can hallucinate, introduce bugs into code and suggest insecure code or procedures, and recommends ordinary engineering measures: code review and branch protections so that checks are enforced before a merge. Since the maker itself does not promise correct output, the only reliable boundary lies outside the model.
| Source | Risk | Control |
|---|---|---|
| Untrusted repository | Prompt injection, scripts, hooks | Restricted Mode, review, sandbox |
| Agent output | Bug, insecure pattern, hallucination | Diff, tests, human review |
| Shell | Destructive or external effect | Permissions, CWD review, sandbox |
| MCP/ACP | Data disclosure, third-party action | Tool grants, provider policy |
| Cloud | Repository, network, secret access | VM policy, least privilege, audit |
| Plugin/extension | Supply-chain execution | Pin, inspect, admin allowlist |
The cost of ignoring this distinction is concrete. An untrusted repository opened without Restricted Mode can be steered by an injection into an extraneous action. Output accepted without review and tests introduces a bug or an insecure pattern straight into main. A broad tool grant for MCP carries data past the limits you kept in your head. The radius of these mistakes is real commits and leaks, not a line in a log.
When each control is justified follows from the same map. For untrusted code - Restricted Mode, in which agents do not run, and a look before trust. For the agent's output - the diff, tests and human review. For the shell - permissions, a check of the working directory and the sandbox. For MCP and ACP - minimal tool grants and the provider's policy. For the cloud - VM policy, least privilege and audit. For a plugin - pinning the version, inspection and an admin allowlist of publishers.
Security should be checked not by the question does the prompt sound safe but by the state of enforcement. Is Restricted Mode on for an unfamiliar repository. Does the protected branch require independent checks before a merge. Is there a deny on destructive commands and on paths with secrets. Has the diff been read before acceptance. Each of these answers is a fact about the system you can present, not a feeling about the text.
The typical failure is confusing influence with control. I did tell the agent not to touch .env instead of a deny rule on .env; I trust the output because it looks reasonable, without running the tests; I install a plugin without checking the publisher and the update source. The sign is the same: the control exists only as a phrase in the prompt and nowhere else. Move it into a permission, a hook, the sandbox or branch protection - and a whole class of incidents simply stops being possible.