Agents should never see your raw keys
By The Lucidrail Team · 2026-06-26
A developer opened a Hacker News thread with a plain, honest observation. It named a gap a lot of people had felt but not said out loud.
Secrets management with Agents feels absent today. The agent needs API keys to call external services, but the usual patterns feel broken in this context. — m-hodges, Ask HN
The replies were not theory. They were descriptions of the workarounds people had already built to get through the week. And they were converging, independently, on the same shape.
There is a name for that shape: a credential broker. A small piece of software that holds your secrets so the agent never has to.
The pattern developers keep landing on
One person in the thread described a server they wrote to sit between the agent and the outside world. The agent asks it to run an approved command; the server supplies the credential and runs it. The agent gets the result, not the key.
Server holds credentials… injects them into a pre-approved allowlist of commands… agent never sees the credential. — akropp99, on a self-built broker (Ask HN)
Another described the same idea from a different angle: hand each step of the workflow only the secrets that step needs, injected at the moment of use.
Each part of the agentic workflow only gets the secrets it needs injected. Agent can see env var names but not the values. — kageiit, on the same thread (Ask HN)
Read those two side by side and the common thread is obvious. The agent can name the credential it wants. It can ask for the credential to be used. It just never holds the credential itself.
Why “just give the agent the key” fails
The tidy version — drop the keys into the agent’s environment and let it call whatever it needs — breaks for a simple reason. A key in the same process as the model is a key the model can read, print, log, or be talked into revealing.
if a agent has the keys in the same process, it can easily extract them — devendra116, Ask HN
On a related thread, the advice from people who had lived it was blunt. If you are going to do this at all, treat every key as already leaked.
Absolutely not, and if you do this then please please rotate keys every day or two. — PocketBot, Ask HN
That is the real objection. It is not that agents are careless. It is that a raw key is a bearer token — whoever holds it can act. One prompt injection, one over-shared log line, one command that echoes an environment variable, and the secret is out. The blast radius of a leaked key is everything that key can touch.
What a broker actually buys you
Once the secret lives with the broker instead of the agent, a few good properties fall out for free.
None of this is exotic. It is the same instinct that keeps database passwords out of application logs, applied to a new kind of caller that happens to be a language model.
- The agent can only act through commands you approved in advance, not through whatever the raw key would allow.
- You can revoke or rotate a secret in one place, without touching the agent or its prompts.
- You get a record of which secret was used, for what, and when — because every use goes through one seam.
- A leaked transcript or log is far less dangerous, because the value was never in it to leak.
The tell: everyone is building it alone
The striking part of the thread is not any single design. It is that several capable people arrived at the same broker pattern separately, each writing their own version, because nothing off-the-shelf shipped it. When many people rebuild the same small thing from scratch, that thing should exist.
This is one of the pieces we build at Lucidrail. A dispatch seam sits between the agent and the tools it calls, and secret redaction keeps the most sensitive secrets out of the agent’s context by design — the agent asks to act, the platform supplies the credential, and the raw key is never in the model’s hands. Same broker pattern the thread kept reinventing, bought instead of rebuilt. More on our /security page.