if a agent has the keys in the same process, it can easily extract them

Totally - the only completely safe way is to inject keys in a proxy and keep them out of the process. But getting them totally out of plaintext is a great first step, both to keep it from AI and malicious scripts that are looking for keys.

which agent framework or tool gives guarantee for leaks?

does you agent only print "Hello World" on console ? or it uses any service ;)

if you usecase is just about dealing with private key and txn signing why not use any KMS service?

No, more like letting an agent interact safely with an HPC frontend. No cloud, no Windows

so you prefer using separate VM machines?

something that you dont like about using AWS secrets Manager or think it should be handle differently?

im researching around building a execution environment that handle the secret + actual execution, any input is appreciated

Well since in my case all of the LLMs I use are hosted by AWS Bedrock, it means I can get away with only caring about AWS Access keys.

If I need to store database passwords in secrets manager, I can just pass the ARN of the secret manager key in the connection string. I often don’t need to even do that and prefer to use the Data API to access Aurora Postgres/Mysql and that also uses the IAM permissions.

Even for access to EC2 instances I use an IAM controlled Session Manager proxy to access it over SSH/RDP.

But Secrets Manager just works. It’s a simple API/ClI command and the permission system to access it is very granular.

is there any tool that can do this ?

I use mitmproxy outside of agent vm

interesting, how do you use mitmproxy for calling openAI llm ? or what exactly you use it for ?

Mitmproxy it to avoid giving model access to secrets.

My assistant lives in ubuntu vm. When I ask it to “check email” it uses imap with password “xyz” and fetches emails.

But my mail password is actually “abc”. Mitmproxy outside of vm replaces all “xyz” to “abc” for outgoing requests. And reverse for incoming

keyring is one of solution but even substituting values at excution does not gaurantee the security as agents can read the process itself.

im building a safe agent execution layer, A runtime where agents can act, but cannot access secrets. kinda sidecar that is callable by agent for using api keys, secrets, private keys, etc and plus one can add policy on how and what a agent can do.

does this seems good?

yah keyring is more for static protection. when the agent process itself is hostile, keyring is kinda obsolete.

but then i think the key is that sometimes agent does need access to credentials to be useful - like i will give some credentials to agent such as my browser account access.

personally i feel it is not really about preventing agent from accessing credentials, but more to have the supervision layer when agent access it - like you know exactly when and why agent need to access it and you have the ability to deny or approve it.

so do we need something like `safe agent execution layer - that is policy enforced` (SEAL) we can manage what should be allowed and what not

agent uses llm to plan the action, but the actual execution happens in SEAL.

any example where it would make sense to start with?

open for thoughts

yah man i saw your project on the execution layer. i think it is great. but one thing i notice in my daily usage is that i am not sure what to allow or deny before the actual usage. like personally i am not able or interested in pre-setting policies. like claude code, you never know what agents want to call before the actual tool use - could be curl, bash, a random command for a random solution to a random problem. so i believe this supervision needs to be at runtime instead of preset

For those interested, the playground uses a guest wallet stored on browser localstorage so there’s no signup friction.