Why developers refuse to give agents raw keys
By The Lucidrail Team · 2026-07-05
Ask a room of experienced developers a simple question — do you hand your AI agents your real API keys? — and the answers come back fast and blunt. On a recent Hacker News thread that asked exactly this, the top replies were not nuanced. They were a flat refusal.
These are not beginners being overly cautious. They are people running agents against live systems, and their reasoning is worth understanding. It is not fear of the unknown. It is a specific, mechanical objection to how a general-purpose agent handles a secret it can see.
Follow that objection to its end and you arrive where every one of them landed: the agent should never hold the raw key at all. And because nothing off the shelf did that for them, several went and built the missing piece by hand.
The answers were blunt for a reason
When the thread asked whether developers give their agents raw keys, the shortest answers were the loudest.
No :) — KellyCriterion, on an Ask HN thread about giving agents raw keys
Absolutely not, and if you do this then please please rotate keys every day or two. — PocketBot, same Ask HN thread
Rotating keys every day or two is not enthusiasm for the practice. It is damage control for a habit you could not talk someone out of. The advice quietly assumes the key will leak; it just tries to shorten how long a leaked key stays useful.
The objection is mechanical, not moral
The clearest version of the argument was a single line about how processes work.
if a agent has the keys in the same process, it can easily extract them — devendra116, same Ask HN thread
That is the whole problem in one sentence. If you put a secret in the same process as the agent — an environment variable, a config file it can read, a variable in memory it can print — then any instruction that can make the agent run code can also make it read the secret. A prompt injection, a poisoned web page, a confused tool call: any of these can turn ‘do my task’ into ‘print your key.’ The boundary you imagined between the agent and the credential was never really there.
So developers build the layer themselves
The refusal is not where the story ends. A separate thread on secrets management for agents opened with the same frustration, stated plainly.
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, opening an Ask HN thread on secrets management for agents
The answers to that thread were not links to a product. They were descriptions of tools people had already built for themselves. One developer described a broker he wrote and named credwrap.
Server holds credentials... injects them into a pre-approved allowlist of commands... agent never sees the credential. — akropp99, who built a credential broker called credwrap (Ask HN)
Another described the same shape from a slightly different angle.
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 secrets-management thread
Different people, different weekends, the same design. A server outside the agent holds the real secret. The agent asks for an action, not for a key. The credential is injected into an allowlisted command at the edge, and the agent only ever sees the name of the thing it is using — never the value.
What “the agent never sees the key” actually takes
The pattern these developers keep converging on is not hard to describe, but it has a few load-bearing parts. To keep a raw key out of an agent's reach, you need:
None of this is exotic. It is the same access-control thinking that has protected human systems for decades, applied to a new kind of user that happens to treat any text it reads as an instruction. The surprising part is only that agent operators keep having to build it from scratch.
This is the seam we build at Lucidrail. Agents call through a dispatch layer that holds the real secret and redacts it, so the most sensitive credentials are designed never to reach the agent's context — the agent asks for the action, not the key. It is the pattern these developers keep hand-rolling, shipped as part of the control plane instead of a weekend project. We describe how it works on our /security page.
- A holder outside the agent's process — the secret lives where the agent cannot read it, not in an environment variable it can print.
- An allowlist of what the secret may be used for, so a hijacked action is bounded even if the agent is fully compromised.
- Injection at the edge — the credential is attached to the outbound call at the last moment, never handed back through the model.
- Names without values — the agent can reason about which credential it needs without ever holding the string itself.