Point an agent at a new data source and tell it to pull the data. Most of the time it works, because the sources you hand it are open or already wired up. But every so often the source needs a key the agent doesn’t have. An API token. A login. Some credential that lives in a password manager, or in a teammate’s head, or nowhere yet.
What the agent does about that key is the whole question. The answer most people skip until it bites them is simple: the agent should never hold the key itself.
The tempting, terrible fix
Watch what a naive agent does when it hits a locked door. It goes and gets the credential, then puts it somewhere it can reach. Pastes it into a config file. Drops it into an environment variable. Writes it straight into the code it’s generating. The job runs. The door is open.
You also just tore the door off its hinges. The credential is sitting in plaintext somewhere the agent decided to put it. Nowhere anyone tracks, rotates, or scrubs. Do that across every source and you’ve got secrets scattered through config files and generated scripts, none of them logged.
Asking you for the secret right there in the conversation is the same mistake. The value still lands in a chat log, written somewhere you don’t control and can’t clean up later. A secret that passes through the agent is a secret you’ve lost track of.
The key lives in the vault, not the agent
The fix is a hard separation. Secrets live in a vault built to hold them. The agent never sees a value. Not in a file, not in an env var, not in the transcript. When a source needs a key, the vault hands it to the source at the moment of use, and the agent never gets a copy.
The trick: the agent knows the name of what a source needs without seeing the value. It knows this source wants an API key and a user agent string. It can tell you which fields to fill. It never holds what you put in them. The agent operates the source, the vault holds the secret, and it works the lock without touching the key.
So when a key is missing, the agent asks for it through a channel built for keys. A form. A vault prompt. The value lands straight in secure storage, never in the agent’s hands. You fill it in once, it’s stored once, and the agent uses the source without ever seeing what unlocks it.
And before it asks you for anything, it should check whether a working key is already in the vault. Half the time the credential you’d hand it is one you stored for a sibling source last week. Reuse beats minting a new secret, and it beats interrupting you for what you already gave it.
Whose keys are whose
Once secrets live in a vault, a boundary falls out worth making explicit. The agent owns the credentials it creates, the ones it gathered to make a source it built work. It can’t touch the credentials you own. The warehouse connection secret, the object store key, the things other pipelines and people depend on. The agent can’t know what else leans on one of your secrets, so it has no business reading, copying, or deleting one. It manages its own keys. Yours stay yours. The vault enforces that line so you don’t have to trust the agent to remember it.
It’s least privilege applied to secrets. An agent that can use a key without holding it is useful. An agent that can read or rewrite anything in your vault is a liability waiting for a bad day.
What good looks like
The agent goes to use a source and sees it needs a key. It checks the vault. Key’s there, the source gets it and the agent never does. Key’s missing, the agent tells you exactly what it needs and you drop it into the vault. Then it runs.
None of this is exotic. It’s just refusing to let the agent become a place secrets live. Keep the key in the vault and let the agent work the lock. Don’t hand it the key and hope it doesn’t leave it lying around.
A locked door is not an error. It’s the most ordinary fact in data work: this thing needs permission. Build the agent that asks for it without ever holding the key.
Todd Fearn is the founder of Datris.ai and has spent about thirty years building data infrastructure for financial institutions. He writes about making AI agents useful in real production systems.