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.
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.
5 comments
[ 5.7 ms ] story [ 114 ms ] threadService 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.
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.