The only private key that my agents have access to are temporary AWS access keys to a dev environment with decently locked down permissions.

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.

▲

devendra116 21 hours ago | parent [-]

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

	▲	raw_anon_1111 21 hours ago \| parent [-]
		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.