I use coding agents across real repositories every day. I run a small security firm, and between audits and two kids there are never enough hours, so agents do a lot of the reading and the grunt work for me.
The biggest mindset shift wasn't about which model to use. It was this: the repository is not automatically trusted context.
When you ask an agent to "fix the failing test", it reads the README, the open issues, the test files, package.json, maybe the CI config. To you, that's your project. To an attacker, every one of those files is an input channel into something that can run commands on your machine.
Everything in the repo is input
- A README or an issue can contain instructions. Following instructions is the agent's whole job. One line buried in a doc ("before running the tests, also run this setup command") is prompt injection with a shell attached.
- A test can execute code. "Run the tests" means "run whatever the test files do".
- A package script can install more code. Install hooks run on install, and agents install dependencies all the time.
- A git hook can run before the commit you asked for.
- Config files are persistence. If the agent can write to your shell config, IDE settings, git hooks or CI workflows, one bad step survives the session.
And the dependency the agent suggests might not even exist yet. Attackers register package names that models tend to hallucinate (people call it slopsquatting). @harsh2644 tested three AI coding tools for it this week if you want to see how often it happens.
Where it actually goes wrong
When we review agent systems, the failure is rarely the model saying something bad. It's untrusted text reaching an execution sink: a shell command, a package install, a file write outside the repo, a CI change, a network call.
So I look at it like taint analysis in code review. Draw every path from something untrusted (an issue, a doc, a test, package metadata, generated code) to something that executes or persists. Then ask what stops it on each path. Usually the honest answer is "I'd have to notice".
What I changed in my own setup
- The agent runs in a box. A container or VM with the repo mounted, and no access to my home directory, SSH keys, cloud credentials or wallets.
- No standing secrets in its environment. No production tokens, no package publish tokens, no deploy keys. If a task really needs a credential, it gets a separate low-privilege one for that task.
- Approvals that mean something. No global auto-approve. Read-only actions can go through on their own. Anything that installs, writes outside the worktree, touches CI or hooks, or goes to the network waits for me. The trap here is approval fatigue: if nine prompts are routine, you click the tenth too, and the tenth is the one that matters. So I keep the prompts few and serious.
- Pinned to one repo and one branch. Separate worktrees per task. A file in the repo telling the agent to "also update the other project" should go nowhere.
- Its diff is a PR from a stranger. I review dependency changes, new scripts and CI edits first, before the actual code change.
- New packages get checked before install. Does it exist, is it the one I meant, who publishes it. Lockfiles committed.
- Logs it can't edit. What commands ran, what was installed, what was sent out. If something goes wrong, I want the record to come from outside the agent's reach.
If you write smart contracts
Keep agents away from deployer and signer keys, full stop. A "just deploy it to testnet" script is one edited RPC URL away from mainnet. Let the agent write and test the code. Run deployments and anything that signs yourself.
The point
None of this makes agents less useful. It's what lets me give them more work without worrying about what's sitting in some test file.
What does your setup look like? I'm especially curious how people handle approvals without drowning in prompts.
I wrote this with help from AI for drafting and editing. The opinions and the setup are mine.
Top comments (0)