Coding agent security: assume the agent is compromised
By Sandeep PandaCo-founder, Bug0 · Building FactoryKit
The industry’s default answer to agent risk is better behavior: system prompts, guardrails, alignment. Useful, and insufficient. A coding agent reads untrusted content all day (repo files, issues, error messages, web pages), and prompt injection means any of it can steer the agent. Our position: design as if the model will eventually follow a hostile instruction, and make that event boring.
The threat model
Simon Willison’s lethal trifecta names the failure shape: an agent with access to private data, exposure to untrusted content, and a channel to exfiltrate. A coding agent in a naive setup has all three: secrets in env vars, a repo full of untrusted text, and open outbound network access. OWASP’s GenAI Top 10 ranks prompt injection first for the same reason.
You cannot remove untrusted content from a coding agent’s diet; the codebase is untrusted content. So the work goes to the other two legs: what the agent holds, and where it can send things.
The agent cannot leak what it never had
FactoryKit’s rule is brokering, not trust. The agent CLI runs with a placeholder key. Real credentials (model gateway keys, GitHub tokens, storage credentials) never enter the sandbox: not env, not argv, not prompts, not git metadata. The sandbox firewall injects real credentials into approved outbound HTTPS requests in transit, so authentication happens outside the blast radius of anything the model can read or be tricked into printing.
Scope is the second half. Each repo gets its own GitHub token, path-scoped to that one repo. A task touching repo A holds nothing that opens repo B.
The agent never touches git
Inside the sandbox, the agent edits a working tree. That is the entire surface. Commits, pushes, branch names, and pull requests happen host-side, as the app’s bot identity, after the run. An injected instruction to force-push to main fails not because the model resisted, but because the capability is not in the room.
What does enter the sandbox
Your app’s own env vars (the ones you register so your dev server can boot) do enter the sandbox as process env. The app cannot run without them. They are sealed with AES-256-GCM at rest, and prompts and logs carry only their names, never their values. FactoryKit’s own credentials are the ones that never enter at all. If a vendor tells you nothing sensitive is in the sandbox, ask how the app under test authenticates to its own database.
Questions for any vendor
- Where do model and GitHub credentials live during a run, exactly?
- What is the token scope: one door per repo, or a master key?
- Who executes git: the agent, or the host?
- What egress can the sandbox reach?
- What evidence ships with each change?
We publish our answers because the architecture is the answer (how the factory works).
FAQs
Can a coding agent leak our API keys?
Only if it holds them. FactoryKit’s agent runs with a placeholder key; real credentials are injected into approved outbound requests in transit, at the network layer, so there is nothing in the sandbox to leak.
Does the agent have access to our GitHub token?
No. Git inside the sandbox uses plain URLs; credentials are added in transit and each token is path-scoped to a single repo. The agent also never commits or pushes; the host does that after the run.
What about prompt injection?
We assume it will eventually succeed and design so a hijacked agent has nothing to steal and no ability to push code. That assumption is worth more than any filter.
Do our application secrets enter the sandbox?
App env vars you register do enter as process env, because your app needs them to run. They are sealed with AES-256-GCM at rest and never appear in prompts or logs, which carry names only.
Can we bring our own model keys?
Yes. Either way the design holds: the agent process runs with a placeholder, and the real key, ours or yours, rides the firewall rather than the agent.
About the author
Co-founder, Bug0 · Building FactoryKit
At Bug0, Sandeep architects Passmark, the open-source AI regression testing framework. He previously co-founded Hashnode and scaled it to millions of developers as its CTO. He wrote AngularJS: Novice to Ninja, co-wrote Jump Start HTML5, and thinks mostly about agentic testing and the infrastructure that makes AI-written code safe to ship.
See a software factory run on your repos
A demo is a working session: your repos, a real task from your backlog, a finished pull request.
Book a demo