Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

> The typical use case: reading secrets from 1Password without approving every single read with your fingerprint.

Uh I dont know about that one chief.

Yes - but I'm out of ideas. How else support long running agents without leaving secrets in files or by default exposed in the environment. That way I get notified the first time before they ask for credentials.

The same agents that could potentially leak your secrets? I would rather not give a hacker a cached session that unlocks the keys to the kingdom.

I'll take security by inconvenience over building what becomes the primary reason for a security incident.

If I already approved it once I already have to assume it could have been leaked. The cache doesn't change much about it if the agent / tenant is asking for something it already has.

It slightly opens what should be a really short and brief window of access.

Does https://secretspec.dev/ address your use case?

That looks pretty cool - even supports caching. Will take a deeper look. Thx

Don't give secrets to agents at all that you don't plan on revoking immediately after.

If you have allowed an agent to access any kind of credential, you should assume it is no longer private.

Fnox (by jdx of mise) supports fetching secrets and caching the results either in local age encrypted files or in a background daemon (in memory only) to minimize repeated gets. The daemon is per terminal instance too I believe so you fetching a secret once doesn't store it for the whole session.

It's not a perfect fix but it keeps secrets out of env with (so far for me) minimal inconvenience.

I 100% love this idea and example and I very much appreciate it.

Reply on news.ycombinator.com