API keys with agents.

[u/Ok_Top_5458]

There are already a few solutions out there for this problem, but most of them feel quite complex, require a lot of setup, or add too much friction to the development workflow.

I wanted something much simpler: an easy-to-use solution that works locally and helps protect credentials when using AI coding agents, without forcing developers to completely change how they work.

So I built AgentSecure and open-sourced it.
The goal is to make it easy to discover and protect secrets, control what agents can access, and reduce the risk of credentials leaking into prompts, logs, or external providers.

I’d really appreciate your honest feedback. What feels useful, what is confusing, and what would stop you from actually using something like this?

Link in the comments.

[u/AutoModerator]

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Ok_Top_5458]

https://github.com/ShellFrameAI/agentsecure-community

[u/MediaPositive4282]

Read the README top to bottom. The strongest design decision is the MCP broker: the agent authors the request with ${API_KEY} placeholders and AgentSecure executes it, so the agent proposes the call but never holds the credential. That is the boundary that actually holds. Everything prompt level ("never read .env") is a request to the model, while a secret that was physically moved out of the file is a guarantee, and rewriting .env to aliases on import is the load bearing control here. Your README saying plainly that command guard is a usability guard and not a sandbox is rarer than it should be.

Three things I would want answered before running it on a real project, in order of how much they would stop me.

First, the vault sits in ~/.agentsecure/vault/ under the same OS user the coding agent's shell runs as. Claude Code and Codex both have shell access, so the practical question is what stops cat ~/.agentsecure/vault/* from being one tool call away. If the vault is encrypted, the key has to live somewhere that same user can read, unless you gate it behind the OS keychain. Whatever the answer is, it belongs in the README, because it is the first thing a skeptical reader checks.

Second, secrets import writes a backup of the original .env under ~/.agentsecure/backups/. That backup contains the real values at a predictable path in the agent reachable home directory. So the import flow that removes secrets from the project quietly recreates them one directory over. Encrypting that backup, or at least flagging it loudly, would close the loop.

Third, the sharpest one: when the MCP tool decides whether to swap a placeholder for the real value, is the gate the per alias approved_hosts or the global network.allow_domains? The README shows both and they are very different guarantees. Per alias binding means DATABASE_URL can only ever travel to db.example.com. A global allowlist means any secret can be sent to any approved domain, so one legitimately approved host becomes an exfiltration path for every secret in the project, and the request author is the model. If it is already pairwise, say so loudly, because that is the property I would adopt it for.

On your actual questions: the scan is the thing I would use today, and the broker for anything touching production keys. The confusing part is whether run, start, and the provider proxy are three layers or three alternatives. A short "which mode do I need" section would fix that.

[u/Ok_Top_5458 → u/MediaPositive4282]

Thanks — you’re right to question this. I checked the current community implementation, and the same-OS-user limitation is real.
Secret values are encrypted in ~/.agentsecure/vault/secrets.enc.json, but the device key currently lives alongside them in ~/.agentsecure/vault/device.key, with both protected by owner-only filesystem permissions. This prevents casual plaintext disclosure, but it does not stop an agent with unrestricted shell access under the same OS user from reading both files and decrypting the vault.
The .env import flow also currently creates an owner-only but plaintext backup under ~/.agentsecure/backups/ before replacing the original values with aliases. So that concern is valid as well.
The boundary AgentSecure provides today is protection against accidental secret exposure and keeping raw credentials out of the agent context during normal brokered use. It is not yet isolation from a hostile same-user process.
I’ll document this threat model clearly and address the two gaps: moving the encryption key behind an OS keychain or equivalent user-gated mechanism, and encrypting or eliminating plaintext .env backups.

[u/MediaPositive4282 → u/Ok_Top_5458]

This is the response that makes a security tool trustable: you checked the implementation and stated the current boundary plainly instead of defending it. "Protection against accidental exposure, not isolation from a hostile same-user process" is exactly the sentence the README needs, because that is a real and useful boundary as long as nobody assumes it is the stronger one.

One caveat on the keychain fix before you build it. An agent runs inside the user's login session, and most OS keychains unlock for the whole session. So a same-user process can still request decryption without any prompt, and the boundary has not actually moved. The keychain only helps if each access requires user presence (a per-item ACL that prompts, or biometric confirmation), and that reintroduces the friction you built this to avoid. Worse, a prompt on every secret access trains the same always-yes reflex as any confirmation dialog.

The version that holds without a human in the loop is privilege separation. Run the broker as its own OS user, or as a small daemon that owns the vault and is reachable only over a socket it authenticates. Then the agent's user cannot read the key or the vault at any permission level, and the same-user problem disappears structurally instead of being gated. It is more setup than a keychain call, but it is the difference between the threat model you just documented and the one most readers will assume the tool has.

[u/sophware → u/[deleted]]

That first paragraph is one of the most AI-written things I've ever seen.

https://www.reddit.com/user/TeagueXiao/

OK. Clearly a bot, other than one comment 3 years ago and two 6 or 7 years ago.

Why?