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
On its own page, Vault in the top navigation. It shows the vault of whichever organization you have active, so switching organization in the menu at the top right switches the vault with it.
The page has four tabs: Secrets (the vault items themselves), OAuth apps (below), Wired in (every module configuration, gateway credential and module deployment secret the organization holds, and the vault item each one points at), and Activity (who changed what, and when; owners and admins only).
OAuth apps are the registrations a gateway signs people in to an upstream with. They sit beside the vault's secrets rather than among them: the client ID is public, and the client secret is sealed the same way a vault item is and is never shown again. An organization's owners, admins and managers can register one there — create the app in the provider's console with the redirect URI the page shows, then paste its client ID and secret — and rename it, rotate its secret, or delete it once no gateway uses it. Apps Odel registered with an upstream itself are listed too, for completeness; Odel removes them with the gateway they were made for.
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 only comes out when something needs it
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. A value leaves the vault in two cases only. A module or gateway wired to it makes a call, and the value goes to that call alone. Or a module deployment's secret is linked to it, and the value is copied onto that module's worker. 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.
The one exception is a module deployment's secret, set in the developer portal. It holds a copy of the value on the module's worker, so it keeps the old value until the module's next deploy or until someone presses Re-sync from vault on its Secrets & Variables card.
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 a notice names where it's wired; the Wired in tab and the secret's Wired into list link 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; read the Activity tab and each item's history |
| Member | See what exists |
| Manager, billing manager | Nothing, unless it also holds Member |
These are the default roles. A role your organization makes on its Roles page can hold any of these on its own: seeing the vault, managing it, using its items, and reading its history.
Members never need a value to use one. An owner or admin points a gateway or a module at an item, and everyone who uses it gets a working credential without ever seeing it. A team can hand its people a working credential without handing anyone the credential itself.
Linking an item is the exception: pointing a module deployment's secret, or a new gateway's credentials, at a vault item takes an owner or admin.
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. The Activity tab reads that record, and owners and admins can see it.
- A module receives the value, not its source. It's handed the credential at call time, or finds it on its worker if it's a deployment secret, 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.