[drchaim]

How are you folks handling secrets in a simple way?

- sops , ansible vault and similar seems too weak given the agent is gonna read them at some point if you have the pass available. - proxy injection seems too complicated and doesn’t cover all use cases.

[acdha]

Try not to: use AWS short-term credentials for anything there, federate with GitHub/GitLab job credentials where possible, etc. It’s easier and you never worry about rotation again.

If you can’t avoid it, use an automatically-rotated store and inject them as late as possible so an attacker needs to be able to get them out of a running process.

In all cases, look into restrictions: not just least privilege access but things like network restrictions so an attacker can’t just use the key on their own systems.

[qntmfred]

I recently finally fully moved all my projects away from .env (for local dev) to infisical, thinking it'd be the way to stop agents from (accidentally?) peeking at my secrets. while I'm still glad I made the move, it's clear that local agents are still moving around my local environment with sufficient privileges and autonomy to use infisical cli however it wants. my work isn't high stakes enough to matter much and I have rotation scripts on hand, but it's hard to see how to fully close the door against this type of risk at this point.

[jakehulberg23]

There's a solution for this in Infisical! It's called secrets brokering and is built into the Infisical CLI: The Infisical agent proxy. Using this, your agent can use secrets without ever being able to fetch them back since they are injected into upstream requests. You can use this for local coding agents like Claude Code or Codex, and also have a standalone proxy with a separate machine identity for longer running agents (slack agents, hermes, openclaw etc.) Check it out here:

https://infisical.com/docs/documentation/platform/agent-prox...