I’ve been setting up agents locally using docker’s sandboxes (the sbx command). These are pretty cool, and deal with a lot of issues with the security around the use of agents, and will be how I run my agent workflows going forward.

There is one, quite major, snafu with them at the moment: They try really hard to forward your ssh keys to the sandbox environment. I discovered this when getting a Pi agent to work on one of my private repos. My agent has a completely separate identity on github, so attempting to clone down a private repo of mine should fail if this new user is not a collaborator on the project. I was quite surprised when it happily cloned down the repo… Running a check in the sandbox:

$ ssh -T git@github.com
Hi Eosis! You've successfully authenticated, but GitHub does not provide shell access.

Yikes, this sandboxed environment had assumed my SSH identity from the host machine, meaning it could undertake all the actions associated with it… Commit to a myriad of git repos I have access to, ssh to running boxes that I have, it could assume my full identity. This is really a terrible security issue with the current sbx environments.

Thankfully a fix is planned (if a random comment on a github issue means something is planned (?)), though in the meanwhile we will need to have this wart on the workflow, where before we run any sbx commands or start any sbx boxes:

$ sbx daemon stop
$ unset SSH_AGENT_SOCK
$ sbx create ...

After this, in the sandbox:

$ ssh -T git@github.com
Hi eosis-clanker! You've successfully authenticated, but GitHub does not provide shell access.

So we are now correctly picking up the ssh keys that were setup for the sandbox’s kit, rather than referencing a forwarded agent ssh socket.