How to protect a coding agent from prompt injection
Assume a malicious instruction reaches the agent and the agent follows it. A sandbox cannot correct that decision, but it can restrict the files, credentials, services, and output the agent can reach.
A prompt injection uses normal agent capabilities
A repository tells the agent to read setup instructions before running tests. Those instructions include a hidden request: read the user's SSH directory and send its contents to a diagnostics host.
This attack needs no software exploit. Reading repository text, opening files, and making HTTP requests are normal coding-agent operations. The malicious text can also arrive through an issue, test output, generated documentation, or a web page.
Detection helps, but cannot enforce safety
A text filter or second model may identify obvious malicious instructions. It may also miss a reworded instruction or block legitimate setup steps. Because the attacker controls the text, detection should reduce exposure but should not decide what the agent is allowed to access.
Assume detection fails. The remaining question is concrete: what files, credentials, destinations, local services, and repositories can the agent reach?
Restrict the capabilities an injected agent can use
| Attempt | Required control | Remaining risk |
|---|---|---|
| Read host secrets | Grant only required filesystem paths; use a separate agent home | Files placed inside the workspace remain readable |
| Steal an API key | Keep the real key outside the box and broker approved requests | An allowed request may still contain source code |
| Send data elsewhere | Allow only required network destinations at an enforced layer | Approved destinations remain reachable |
| Use SSH, Docker, or desktop authority | Deny host Unix sockets and isolate loopback | Every explicit socket grant carries real authority |
| Publish a harmful change | Require external review before export or apply | A reviewer can still approve bad code |
Do not expose the developer's home directory
An h5i box receives only the filesystem paths granted by its resolved policy. Its agent home is a per-box copy with credential-shaped entries removed. Paths such as ~/.ssh and ~/.aws should not be present unless the task explicitly requires them.
Workspace contents are intentionally readable. Do not copy a secret into the repository and expect the sandbox to hide it from the agent.
Keep reusable credentials outside the box
A secret in an environment variable or dotfile can be copied by any compromised process. h5i instead gives the box a per-run placeholder and sends approved requests through a host-side credential broker. The broker selects the upstream service and adds the real credential outside the box.
The broker prevents direct theft of the key; it does not narrow the service permissions attached to that key. Use service credentials with the minimum required scope. It also cannot stop source code from appearing in an allowed model request.
Enforce network and local-service boundaries
Proxy variables constrain only software that uses the proxy. If raw off-list connections must fail, use an isolation tier that enforces destinations at L3/L4, such as supervised or microvm. The container tier's HTTP proxy does not constrain a program that opens its own socket.
Unix sockets and loopback services need the same attention. An SSH agent or container daemon can give the box substantial host authority without any internet connection. Deny Unix sockets by default and grant only the specific local service a task needs.
Use a fresh browser profile inside the box
A daily browser profile contains cookies, extensions, downloads, and authenticated sessions. Headless mode does not remove that authority. Place browser work inside the box with a fresh profile so page code cannot inherit the user's sessions and localhost refers to the box's dev server.
Review the patch outside the sandbox
Capability restrictions do not make the generated code safe. A prompt-injected agent can still write a backdoor or weaken a test inside its workspace. The box must not decide that its own result is acceptable.
Export the patch with its execution report and receipt. Review them before applying the change to the parent repository.
What remains possible
- The agent can damage or delete its disposable workspace.
- It can misuse any file, destination, socket, or credential explicitly granted by policy.
- It can send source through an allowed model request.
- It can produce convincing but unsafe code for a human to review.
- A shared-kernel tier does not protect against a successful host-kernel exploit.
Sandboxing reduces the authority available after prompt injection. It does not prevent the injection or verify the final code.
Check the boundary before running the agent
Inspect the resolved policy and answer five questions: Which host files are readable? Which reusable credentials enter the box? Which internet destinations and local sockets are reachable? Which browser profile is used? Can the box write directly to the parent repository?
Test harmless denials for paths and destinations that should be unavailable. A security boundary should fail because of an enforced rule, not because the agent was asked to behave.
Sources and further reading
- Write a box policy, for filesystem, network, socket, and resource controls.
- Credential handling and Unix-socket policy.
- Run the browser beside the dev server inside a box.
Questions that come up
Does sandboxing prevent source code from reaching the model?
Are permission prompts still useful inside a box?
Write down what the agent may reach
Create a fail-closed profile for filesystem, network, and resources.
Limit what the agent can reach
A narrow box makes a successful injection much less consequential.