Ask HN: How do you gate an autonomous coding agent's shell access?
2•alanfuNZ•8h ago
I've been giving coding agents more autonomy lately, letting them run shell commands unattended for longer stretches, and I don't have a good answer for how people actually gate that beyond "run it in a container and hope." A container limits blast radius but doesn't stop the agent from reading a secret and then making an outbound call in the same session, or force-pushing to a branch it shouldn't touch, or just doing something irreversible while nobody's watching. Curious what people are actually doing: allowlists of commands, human-in-the-loop approval for anything destructive, something built into the agent framework itself, or just accepting the risk because the alternative is too slow? Specifically interested in what happens when the approval step itself fails or times out, does your setup default to allow or deny?
Comments
verdverm•4h ago
I used dagger for the sandbox in my personal harness. Docker also has a sandbox (microvm based) product now. Both obscure the credentials, but I do not think it eliminates them base64 encoding it (or some other transformation). It does step it from being visible if it is the same string, regardless where/how it is printed.
Service accounts / IAM / WIF / proxies, which remove credentials from the environment all together, are more advanced options.
I'm working on a custom "tool calling policy" guardrail agent. There are a number of models which have been trained to accept a policy document and user content, returning a truthy value for the harness to use during approval.
verdverm•4h ago
Service accounts / IAM / WIF / proxies, which remove credentials from the environment all together, are more advanced options.
I'm working on a custom "tool calling policy" guardrail agent. There are a number of models which have been trained to accept a policy document and user content, returning a truthy value for the harness to use during approval.