Local Does Not Mean Trusted
A coding agent feels local. It runs in your terminal, sees your repository, edits files, and asks permission before risky commands. That feeling is dangerous if it makes the tool trust project-local input too early. A repository can contain configuration, hooks, scripts, issue templates, docs, and hidden instructions. Some of those are useful. Some can be hostile.
Anthropic's containment post describes a class of bugs that happened before the trust dialog. The lesson generalizes: opening a folder is an inbound request. Reading project config is parsing attacker-controlled data until the user has explicitly trusted that folder.
The trust prompt is not the security boundary if untrusted project files can influence behavior before the prompt appears.
The Environment Has to Say No
Model-layer defenses are necessary, but they are not enough. If a user is phished into pasting a malicious prompt, the instruction may look like user intent. The model cannot reliably infer that the user has been socially engineered. In that case, the environment must refuse dangerous effects: block network egress, keep credential files out of reach, restrict filesystem writes, and make secrets unavailable by default.
This is the same reason sandboxing is not merely a productivity feature. It lets the agent do more routine work without constant prompts, while keeping the blast radius bounded when the prompt, repo, dependency, or tool output is hostile.
Delay local config
Project settings, hooks, and startup scripts should be parsed only after trust is established.
Constrain filesystem access
The working tree is not the home directory. Credentials, browser profiles, SSH keys, and cloud configs should stay outside reach.
Control egress
If the agent cannot POST to arbitrary hosts, many exfiltration prompts fail regardless of how persuasive they are.
Audit risky actions
Permission prompts are useful, but logs and policy are what let teams investigate after the fact.
Security Review Is a Workflow, Not a Badge
Claude Code's automated security review feature points at another side of the same story. Agents can help defenders find SQL injection, XSS, auth flaws, unsafe data handling, and dependency issues. But automated review should complement human review, not replace it. The tool is strongest when it shortens the loop from finding to patching.
The interesting shift is that coding agents are now both part of the development environment and part of the security workflow. That means they need to be protected like developer tools and evaluated like security tools. A compromised coding agent is not just a bad autocomplete. It is an actor with filesystem access, code-writing ability, and sometimes network reach.
The Practical Baseline
A serious Claude Code deployment should have a baseline: per-project trust, sandboxed execution, explicit network policy, credential isolation, dependency scanning, review logs, and a way to run security review in CI. For personal projects, the same principles apply at smaller scale: do not open unknown repos with broad permissions; do not give the agent access to your home directory; do not let convenience become ambient authority.
The future of coding agents is not fewer boundaries. It is better boundaries: quiet where the action is low risk, firm where the blast radius is real.