Keep secrets out of the agent: the credential-broker pattern
By The Lucidrail Team · 2026-07-15
Someone asked a plain question on an Ask HN thread: do you let AI agents use your API keys directly? The replies were short, and almost unanimous.
That is worth noticing. Before any standard body has weighed in, and before any framework enforces it, developers are writing the security rules for agent access in comment threads — and they keep arriving at the same answer.
The answer keeps coming back: no
The refusals were blunt.
No :) — KellyCriterion, on an Ask HN thread about giving agents API keys
Absolutely not, and if you do this then please please rotate keys every day or two. — PocketBot, on the same Ask HN thread
The reasoning underneath is technical, not squeamish. An agent runs your commands inside a process. Anything that process can read, the agent can read too.
if a agent has the keys in the same process, it can easily extract them — devendra116, on the same Ask HN thread
A raw key is not just a permission. It is a copyable string. Once it sits in the same memory the model is driving, a stray log line, an echoed variable, or a single prompt injection can carry it back out. Rotating keys every day or two, as one reply suggested, is damage control for a design that handed over too much in the first place.
The fix developers reach for: a credential broker
On a separate Ask HN thread, the person who started it named the gap directly.
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 that followed described the same shape, arrived at independently. Keep the secret on a server the agent cannot read. Let the agent ask for an action, not for the key. Run only the commands you have approved in advance.
Server holds credentials... injects them into a pre-approved allowlist of commands... agent never sees the credential. — akropp99, describing a tool called “credwrap” on the same thread
Another builder described injecting only what each step needs, and nothing more.
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
The move in all of these is the same. The agent sees the name of a capability and the result of using it. It never sees the secret behind it. The value stays on one side of a seam the model cannot cross.
Why this gets harder with a fleet
One agent and one key is easy to reason about. The problem grows with the fleet.
Run eight agents and they each need credentials for different services — a database here, a payments API there, an email account somewhere else. Now the questions stack up:
Hand-rolling a broker for one agent over a weekend is doable. Doing it consistently across a whole fleet, with a record you can trust afterward, is the part people keep rebuilding — because nothing off-the-shelf did it for them.
This seam is the idea behind the dispatch layer we build at Lucidrail. The agent asks to run an action; the platform holds the credential and runs the allow-listed command on the agent’s behalf, so the most sensitive secrets are designed never to reach the agent at all. Every call still lands in an audit trail that traces back to the goal that prompted it. It is the broker pattern developers keep hand-building, offered as a layer instead of a weekend project — more at /security.
- Who holds the keys, and where do they live so that no agent can read them directly?
- What does each agent actually see — a capability it can call, or the secret itself?
- Who can prove, later, which agent used which credential, and for what goal?