//Question
How do you sandbox an AI coding agent from production credentials?
Posted on 31st August, 2026

William
//Answer
Give the agent its own identity, run it in a container with no inherited credentials, broker every token it needs through a short-lived scoped grant, and allowlist its network egress. The failure mode in almost every real deployment is simpler than any of that: the agent runs as the developer, inside a shell where the cloud CLI is already authenticated against production.
Start by breaking credential inheritance. Run the agent in a container or dedicated VM that does not mount the developer's home directory, cloud config directories, SSH keys, or shell profile. Anything the agent needs gets injected deliberately.
Deny reads on secret paths at the filesystem level rather than relying on the agent's own permission prompts. .env, credential directories, keychain paths, and kubeconfig files should be unreadable, not merely discouraged.
Issue credentials through a broker with short expiry and narrow scope. If the agent needs to query a database, it gets a read-only role against a seeded staging instance with an hour-long token, not the connection string sitting in the repo.
Allowlist egress. An agent that can reach only your model provider, your package registry, and your source host cannot exfiltrate to an attacker-controlled endpoint even after a successful injection.
Route production access, when genuinely required, through a human-approved pipeline rather than a live session.
Akto Argus enforces this at runtime by applying policy to the agent's tool calls and outbound requests, so credential access and network destinations are checked against a scope rather than trusted because the session started clean.
Assume the agent will be injected. Sandbox for the aftermath.
Comments