Ask HN: Best practice securing secrets on local machines working with agents?

10 points by xinbenlv 161 days ago | 12 comments

When building with autonomous / semi-autonomous agents, they often need broad local access: env vars, files, CLIs, browsers, API keys, etc. This makes the usual assumption — “the local machine is safe and untampered” — feel shaky.

We already use password managers, OAuth, scoped keys, and sandboxing, but agents introduce new risks: prompt injection, tool misuse, unexpected action chains, and secrets leaking via logs or model context. Giving agents enough permission to be useful seems at odds with least-privilege.

I haven’t seen much discussion on this. How are people thinking about secret management and trust boundaries on dev machines in the agent era? What patterns actually work in practice?

bilbo-b-baggins 161 days ago |

The solution that Anthropic uses for Claude Code Web for repository access is to not give the LLM any secrets at all - anything requiring escalated privilege is done through a proxy which holds the credentials.

varshith17 160 days ago |

Concrete setup: (1) All secrets in 1Password/Bitwarden with CLI, (2) Agent sandbox with no env var access, (3) Wrapper scripts that fetch secrets on-demand and inject at runtime, (4) Context scrubbers that strip secrets before LLM sees logs. Key insight: don't prevent agent access to secrets, prevent secrets from entering agent context/logs. Different problem, solvable with tooling.

CriptoSeguro25 161 days ago |

TBH, the best pattern I've seen is just nuking the secrets at the input level. Run a local regex watcher in-memory that flags anything looking like a PK or seed phrase before it even hits the agent's context window. Keeps it off the network stack entirely

xinbenlv 161 days ago | |

Any prompt injection attack could by pass this by simply do a base64 or any encoding, I guess?

CriptoSeguro25 161 days ago | | |

You ar absolutely right. Obfuscation like Base64 or rot13 will always beat static Regex. I was thinking more in terms of a seatbelt for accidental leaks user error rather than a defense against adversarial prompt injection. It's about reducing the blast radius of clumsy mistakes, not stopping a determined attacker.

algebra-pretext 161 days ago |

I’m not too familiar with the space, but a friend of mine works at Descope[0] where they offer IAM solutions for agents.

[0] https://www.descope.com/

xinbenlv 161 days ago | |

is the permission device+client based or role based?

nojs 161 days ago |

Run the agent in a sandbox without access to production secrets.

xinbenlv 161 days ago | |

What if you simply need to give them access. E.g if you want them to do code review you have to at least give them code repo read access. But you don't know if the environment where agent runs will be compromised

mejutoco 158 days ago | | |

If you give read access with their own api key they will only get read access, the access that you gave them. Not sure what is the issue.

deflator 161 days ago |

I've been having success using Doppler for secret storage. Takes it off the filesystem.

xinbenlv 161 days ago | |

My question is not about on or off storage, is more about when you give agent access, it assume the environment agent runs is safe