Contents7
I have a confession to make. Part of my week goes neither to selling, nor to designing, nor even to putting our AI agents to work. It goes to holding their keys.
A token here to publish code, an API key there to send emails, CRM access for the agent that keeps records up to date. I generate them, store them, renew them, stash them, and hand them to the next agent that needs one. A concierge, in short. Minus the lodge, and with no Christmas tips.
This article from our Business AI section tells the story of that chore, why it so often ends in a leak, and the solution we chose for ourselves, which we can set up for you too.
In short
A key handed to an AI agent means six moves: generate it, paste it, note where it lives, renew it, hide it, then hand it to the next one. Every new agent starts the loop again.
The chore invites shortcuts, and shortcuts end in leaks: keys forgotten in agent configuration files, on machines, never renewed.
A secrets vault takes over the work: each key is stored once, kept up to date wherever it is used, with one identity per agent and per environment.
Nobody reads your keys: not us, since our access disappears at handover, not your AI, which never sees the real value, and not the host for anything encrypted end to end.
It runs on your server or in a cloud hosted in Europe, in your name, on open-source software whose code is public.
What does a key concierge’s life look like?
An AI agent does nothing beyond what its access allows: that is both its strength and its limit, as our article on the loop of an AI agent explains. The one that publishes code needs a repository token, the one that sends quotes needs an email-sending key, the one that updates the CRM needs an API key. And every key goes through the same cycle:
The life of a key handed to an AI agent
- Generate
The key is created in the service’s console, with rights you hope are right.
- Paste
The key goes where the agent will find it, in the settings of its environment or of the publishing pipeline.
- Note
Where the key lives, what it is for and when it expires all have to be remembered somewhere.
- Renew
The key expires, or it has been seen, and everything has to be redone without breaking anything.
- Hide
The key must not end up in a file, a screenshot or a chat.
- Hand over
A new agent or a new project arrives, and the loop starts again.
Multiply that by the number of agents, then by environments (development, staging, production), then by projects. In our case, that means six code repositories and agents that work in the cloud. The maths is quick, and it does not favour the concierge.
From the field
Every key here still makes the trip by hand
On 10 October 2026, setting a single key on the new hosting platform of this site turned into a puzzle. The tool refused it, because the latest version of the site was not the live one but a preview under review, and both solutions it offered started from that preview, at the risk of putting it live. The only safe way out: set it by hand, on the live version. The next day, we decided to run all our agents in the cloud rather than on my computer: every key they needed had to be copied by hand into their environment settings. And since one rule allows no exception here (a key is never pasted into a chat with an agent), I am the one who makes the trip, every time.
Why does the chore so often end in a leak?
Because a chore invites shortcuts, and each shortcut has its own leak:
- The key pasted into the agent’s configuration, “to save time”. It stays there, and the file travels: into a code repository, a backup, a help message sent to a colleague.
- The key that never expires, “so I don’t have to think about it”. It outlives departures, abandoned projects and providers who have left.
- The same key for everything, “so I don’t have to manage ten”. The day it leaks, everything opens at once, and changing it breaks everything at the same time.
- The key sent by chat, “just this once”. It sleeps there, readable by anyone who gets into the chat.
These shortcuts leave measurable traces. GitGuardian, which tracks exposed secrets at scale, finds them even in the files that connect AI agents to their tools, and on the machines hit by Shai-Hulud 2, an attack carried by booby-trapped code packages:
unique secrets exposed in MCP configuration files, the ones that connect an AI agent to its tools
of the machines compromised by Shai-Hulud 2 held more than ten secrets, and 5% more than a hundred
of those machines were not workstations, but servers running publishing pipelines
Renewal, the step people skip
Of the six moves, it is the most tedious, and therefore the one that gets put off. The same report sums it up in one sentence:
Teams can’t rotate secrets without risking production outages, so they don’t.
That is the whole concierge trap: the more copies a key has, the scarier it is to change, and the longer it lives. The risks agents add to the picture, from the booby-trapped instruction to the resold AI key, are covered in our article on the secrets vault.
What a secrets vault changes for the concierge
A secrets vault is a single, encrypted place where the company’s keys live, with an identity for each person, each automation and each agent. It does not get rid of keys. It gets rid of the concierge.
With a vault
Each key is stored once, and sent up to date wherever it is used
Renewal is scheduled, and happens on its own when the service allows it
Agents use keys without seeing them: the real value is only added at the moment of the call
The log says who used which key, when, and from where
With a concierge
Each key is copied into every tool, every project and every environment
A key expires without warning, and you find out when everything stops
Agents keep their keys in their settings, where they can read and repeat them
Nobody knows who used which key, or when
The solution we chose, for us and for you
In October 2026, we chose an open-source, audited vault for our own agents, and our keys will move into it one by one, starting with the agents’ keys. It is also the one we offer you, with these advantages:
- On your premises, or hosted in Europe. The vault runs on your server, even one cut off from the internet, or in a cloud hosted in the European Union, always in your name. If your sector requires a qualified host, such as SecNumCloud in France, it runs at that host: you choose where it runs, not its publisher.
- Nobody reads your keys. Values are encrypted end to end: they can only be decrypted on your side, never on the vault’s server or at its host, with one exception, covered below. Our own access disappears at handover.
- Not even your AI. An agent never receives the real value. Depending on the setup, it gets the result of the action, or a fake key, a decoy. The relay checks each request against your rules, then swaps the decoy for the real key as it leaves for the intended service. An agent fooled by a hidden instruction has nothing to give away.
- One environment, its own keys. Development, staging, production: each environment has its own keys, and the agent running tests never touches the production ones. The vault shows at a glance which key is missing from which environment.
- One identity per agent. Each agent, each automation and each person has their own, with only the rights they need. An agent goes off the rails, a provider leaves: you cut that access, and the others carry on. Our guide on AI governance in the enterprise shows how to slice those rights.
- A key changed once, up to date everywhere. The vault itself pushes the new value to your publishing pipelines, your hosting and your tools. For services that allow it, each agent can even receive fresh, short-lived keys.
- A history and a log. A value overwritten by mistake is restored in one click, and every read is recorded: who, which key, when, from where.
- Nothing home-made. Every line of code protecting your keys is public and auditable. The publisher is audited by an independent third party (SOC 2 Type 2), and its software regularly tested by a security firm. If you change providers, the vault stays yours.
Our agents already work this way when they publish code: the token is added on the way by the network layer, and never enters their working environment. The vault extends this principle to all our keys.
What the vault does not do for you
Watch out
Losing access to the vault means losing every key at once
The recovery kit is stored offline, and the emergency procedure, entrusted to two people you designate, is tested before you need it. We keep no copy: that would be precisely the access we promise not to have.
Two other limits are worth stating. First, to push a key to your tools itself, the vault’s server must be able to decrypt it. That is why we set it up on your premises or with a European host in your name, and why the keys that matter most (money, domain names, administrator accounts) live in a space that never syncs and stays encrypted end to end. Second, a vault does not fix a key that has already leaked: it gets changed, no discussion.
Where to start?
With a list: the keys your agents and automations use, where they live, who created them, and when they expire. If it fits on one page, good. If nobody can write it, you have your answer. And if your agents are still just a project, this is the best time: the vault is easier to set up before them than after, and our guide to integrating AI in your business lays out the steps.
Then our AI secrets vault offer does the rest: an inventory of your secrets and of existing leaks, the vault opened in your name, your tools and agents connected one by one, then the handover of the keys. Count €2,900 to €4,900 depending on the number of tools and agents, and two to three weeks. Before anything else, we check with you in 20 minutes that this is the right project. And so that each agent also has its budget and caps, our AI at the right cost pack plugs into it.
In short: the best concierge is the one you no longer need. If you would like to hand back the keys for good, write to us.
Frequently asked questions
Why not just give the key to the AI agent?
Because an agent reads everything it is given, and can repeat it, copy it or have it coaxed out of it by an instruction hidden in a document. A key it has never seen is a key it cannot leak. With a vault, it asks for the action, and the key is only added at the moment of the call, towards the intended service alone.
Does a secrets vault replace the password manager?
No, it sits alongside it. A password manager serves people, for their accounts. The vault also serves machines (agents, automations, publishing pipelines), with an identity for each, separate environments and a log of every read. For their personal passwords, everyone keeps their own manager, with two-factor authentication wherever it exists.
Do you have to host the vault yourself?
Not necessarily. On your premises, you keep control of everything, including the server that decrypts synced keys, at the cost of a server to maintain. Hosted in Europe in your name, there is nothing to maintain, and keys encrypted end to end stay unreadable to the host. The choice depends on your team and your obligations.
Can AI read the keys in the vault?
No. It receives the result of the action, or a fake value that the relay swaps for the real one as the request leaves, after checking it against your rules. The AI model never sees the key, whoever its provider, so a booby-trapped instruction cannot make it repeat anything.
Jim · founder of Brain Plus AI
Also in business ai

Understand12 min
Secrets vault: your AI uses your keys without seeing them
Passwords sent by email, API keys forgotten in code, AI agents that could copy everything: these are the leaks we come across most often. And how a vault in your name lets your AI use your keys without ever reading them.

Understand10 min
Agentic AI: how an agent's loop works
An AI agent does not do everything in one go: it runs in a loop, gathers context, acts, checks and starts again. Understanding that loop means knowing where to put the controls, the limits and the human review.

Practical guide12 min
Enterprise AI governance: who can access what
An AI assistant reads whatever your access rights let it read, sharing mistakes included. Here is how to split your knowledge bases by department, keep a common core and decide who writes to the shared memory.
