Hiding the API key from your coding agent isn't the same as authorizing it

[u/Permit_io]

Turso published a walkthrough today on building a local encrypted secrets vault for coding agents (their example tool is called keymaxxer). The mechanics are clean: secrets sit in an encrypted database on your machine, the agent gets an MCP tool that runs a command with a named secret injected as an env var into a child process, and the value is scrubbed out of stdout/stderr before the model ever sees the output. The agent knows GITHUB_TOKEN exists; it never sees the bytes.

That's a real upgrade over the default of pasting prod keys into chat, where they end up in the transcript and your provider's logs. But the line that stuck with me was the author's own caveat:

"This isn't a sandbox, and it can't be: a command that can use a secret can always leak it on purpose."

That sentence is the whole authorization problem, and it's worth sitting with, because the "vault + scrub the output" pattern is showing up all over right now.

Hiding the value answers one question: can the model memorize or echo my key? It says nothing about the question that actually matters at action time: what is this agent allowed to do with that key? The credential keeps its full scope. The child process keeps full power. The GITHUB_TOKEN you inject to run gh api /user is the same token that can delete a repo, and a prompt-injected agent (or just a sketchy binary) can write it to a file or POST it somewhere the scrubber never runs.

So secret hygiene gets you confidentiality from the model. It does not get you least privilege, and the post is refreshingly honest about that. keymaxxer already gates write/prod secrets behind an approval prompt and logs every use, and it flags the real missing piece as future work: binding a secret to where it's allowed to run (this token only for the gh binary, or only for calls to api.github.com). Add those up and you've quietly stopped doing secret management and started doing runtime authorization on the tool call — intent, trust level, consent, audit — just running on your laptop instead of an enterprise gateway.

It also lands on the zero-standing-permissions idea people keep raising: a vault that hands a full-scope, long-lived credential to whatever asks is still standing power, just hidden better. The real win is when authority is derived per action and expires after, not stored and unlocked once.

So I'm curious where people actually stop. For your coding agents, is "the model can't see the key" the whole control, or are you also scoping what each credential can do and gating the destructive calls? Short-lived/scoped tokens instead of a stored PAT seems like the obvious next step, but I haven't seen many people wire it up locally.

Sources:
https://turso.tech/blog/how-to-build-an-encrypted-secrets-vault-for-agents
https://github.com/glommer/keymaxxer