or is there any other tool or mechanism that one use to safegaurd from potential exploit or leaks
I let it troubleshoot my web code using a temporary JWT in a dev environment using headless chrome and Puppeteer in a Docker container.
Everything else is in AWS Secrets Manager inaccessible by the IAM role the agent has access to.
I don’t store the temporary AWS keys in a file anywhere. They are in environment variables. All AWS SDKs and the CLI look in the environment variables by default.
I sure as hell don’t store API keys anywhere on my local computer.
im researching around building a execution environment that handle the secret + actual execution, any input is appreciated
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.
If I get my stuff hacked (because I use a machine with nothing else on it other than coding agents) I'll know these services are not removing my personal info from their logs.
I don't operate chinese models where my high value api keys are.
It's pretty hard to debug stuff without using real api keys, service accounts etc...otjerwise
My use case is ssh. I would like to stick my private key into a local Docker container, have a ssh-identical cli that reverse proxies into the container, and have some rules about what ssh commands the container may proxy or not.
Does anyone know of something like this?
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?
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.
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