The vault
One place for your keys and tokens — stored once, wired into anything, changed in a single edit.
Plenty of what you connect to Odel needs a credential. A module that posts to Slack wants a Slack token. A connection to someone else's MCP server wants whatever that server asks for. A gateway needs the OAuth app that connects it to the upstream.
Without somewhere to put them, you end up pasting the same key into three different forms and then forgetting where the third one was. The vault is that somewhere.
Where it lives
Organization settings, under Vault — right below the organization switcher, so switching organization and looking at its secrets is one motion.
Every organization has one, including your personal organization. There the vault is simply your own secrets: the ones your modules and your connections use, belonging to nobody else.
A value goes in and does not come back out
You can name a secret, replace its value, and delete it. You cannot read one — not in the interface, and not through the API behind it. This isn't a display choice that a future feature might relax: the service that manages the vault has no method that returns a value, so there is no request the website could make to get one.
What you can see is everything around the value: what it's called, when it was last used, when it was last changed, and what's wired to it.
Save it somewhere else too
Since nothing can read a value back, the vault is not a backup. If a key exists only here and only in the service that issued it, losing access to that service means minting a new one.
Type it, or point at it
Anywhere Odel asks for a secret — installing a module, editing its config, connecting an external server, setting up a gateway — the field has a key icon on the right.
Type into the field and you're storing a literal value, used by that one thing.
Click the key and you get your vault instead: search it, pick an item, and the field shows a chip reading from your vault. What gets saved is a pointer to the item, not a copy of it. The value itself never reaches your browser, on the way in or the way out.
Change it once
That's the whole point of pointing rather than copying. Rotate a key at the issuer, paste the new value into the vault item once, and every module, connection, and gateway wired to it is using the new value on its next call. Nothing else to find, nothing to update.
Renaming works the same way — everything wired to the item follows the new name automatically, so you can fix a name you regret without breaking anything.
Deleting is the one thing the vault will refuse. If anything still points at an item, the delete fails and tells you where it's wired; the In use list below the vault links to each place. Unwire it there first, then delete.
Which vault a picker is showing you
Two rules, and they follow from who's actually using the secret.
Your own things pick from your own vault. Module secrets and your private connections belong to you personally, so their pickers show your personal organization's vault — even while you have a team organization selected.
A shared gateway picks from the organization's vault. A gateway's upstream credentials belong to the organization that owns it, and that's the vault its wizard offers.
A gateway still never shares anyone's access
The organization shares the registration — the OAuth app that lets people sign in at all. Each person's own token from the upstream is stored against them personally, and is never in the organization's vault. See connecting a gateway.
Who can manage it
| Role | Can do |
|---|---|
| Owner, admin | Create, rotate, rename, and delete items |
| Manager, member | See what exists and point things at it |
Members never need a value to use one — pointing at an item is enough — which is the useful half of the arrangement. A team can hand its people a working credential without handing anyone the credential itself.
In your personal organization you're the owner, so all of this is yours.
When you remove something
Uninstalling a module deletes the secrets that belonged to it. If one of those was a pointer into your vault, the pointer goes and the vault item stays — it was never that module's to delete, and anything else wired to it carries on.
What is actually protected
In plain terms, and each of these is a property of how it's built rather than a policy:
- Values are encrypted before they're stored, and each one is bound to its own place. A stored value moved somewhere it doesn't belong fails to decrypt rather than being read.
- The keys that do that decryption live in one isolated service and nowhere else. The marketplace, the developer portal, and the proxy that runs your modules hold none of them.
- That service cannot reach the network. Outbound requests are blocked, so there is no route out even if something inside it went wrong.
- Every change is recorded — who, what address, when — as durably as the change itself.
- A module receives the value, not its source. It's handed the credential at call time and learns nothing about where it came from or what else uses it.
Want the mechanism?
The addressing model, the encryption, the reference resolution, and the audit trail are written up in how the vault works.