Ask HN: How do you gate an autonomous coding agent's shell access? | Hacker News Reader

Ask HN: How do you gate an autonomous coding agent's shell access?

2 pointsalanfuNZ3 comments

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?

View on HN

I tried nono to limit commands an agent can run but that proved to be cumbersome.

I ended up creating multiple logins on a Linux system. I used my developer account to clone git repos and then create local bare repos in a read only dir. The new linux user accounts can clone from these bare repos but not push. This way, each coding agent (installed per linux account) can only work within the file system for that user on the repo assigned to that user.

Each of these user has no github permissions (cannot clone from github, cannot create pull requests, etc.). They can run tools (that I have installed) but cannot generally install software or push changes (no sudo access, no github credentials). So I can ask each coding agent to make local changes, and when they are done they create a pull request branch and wait for it to be accepted.

Then my single authorized user can take that pull request branch and merge it and push it (or create a pull request). This prevents any agent from working on a repo other than the one it has access to.

Doing this allows me to run several agents at once, one per repo, and not interfere with each other. Before I did this the agents would overreach and start modifying other repos while the correct agent was also making changes. Now, each agent creates a document requesting changes from other agents in their respective repo.

So these low privilege users have no credentials (other than to use a coding agent). This setup works for me.

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.

Agree on the sandbox side. dagger or a microVM is the right blast-radius layer, and moving creds out of the environment entirely (service accounts, WIF, an egress proxy that injects them) is the real fix for the secret-then-outbound-call case. Obscuring the string is weaker than it looks: the agent can base64 it, split it, or just describe it, and the sandbox has no way to know that the request body was derived from what it read ten minutes ago.

That's why I ended up gating at the tool-call level with session state instead of at the network level. Same curl gets a different verdict depending on whether the session already read something secret-shaped. Deterministic rules only, and the approval prompt times out to deny, logged as a timeout rather than a denial so I can tell the two apart later.

On the policy-model approach: I'd be careful about what a model's truthy value is allowed to do. A classifier crossing a threshold is a guess with a confidence attached, and a guess that hard-blocks real work gets the whole guardrail disabled by the end of the day. The split I settled on is that a probability can ask (escalate to a human) but only a predicate can refuse. Curious whether you're letting the model produce the deny directly, or routing its output through a human when it's uncertain.

For what it's worth this is what I've been building: https://github.com/DobermanCore/Doberman-Core. Apache-2.0, 100% open source

Reply on news.ycombinator.com