Organisation vault

Share a credential with your team without giving it to them. An admin stores it once; members use it in their connectors and can never read its value — not in the interface, not through the API, not in an agent's answer.

Why

Without a vault, sharing the company Stripe key means messaging it to someone. It then lives in a conversation, in everyone's password manager, and in their memory — and rotating it becomes a manhunt. Here it is entered once, used by name, and revoked in one action.

How it works

Step	Who	What happens
1	Admin	Profile → Vault → New credential. Pick the connector, name the entry, enter the values. They are encrypted immediately.
2	Member	In Integrations, the connector offers "Use an organisation credential" and a list of names.
3	Platform	The member's connection stores a reference, never a copy.
4	At run time	The value is decrypted on the server only, at the moment the agent calls the tool.

What the platform guarantees

• No read-back. No endpoint returns a stored value — not even to the admin who typed it. To change a secret, you replace it.
• Per-organisation isolation. Every query is filtered on the organisation in the caller's token. A reference pointing at another organisation resolves to nothing.
• Encrypted at rest. The same mechanism as every other platform secret, and compatible with HashiCorp Vault (Transit), which moves the key out of the application entirely.
• Never in an agent's answer. The redaction filter strips credentials from tool results and model output regardless of where they came from.
• Immediate revocation. Deleting an entry cuts every connection using it, because they hold only a pointer. The page tells you how many before you delete.
• Auditable. Create, update, delete and attach are all recorded (vault.create, vault.update, vault.delete, vault.attach).

Permissions

Action	Admin	Member
See the list (names, connectors, fields)	✅	✅
Attach an entry to their own connector	✅	✅
Add / edit / delete	✅	—
Read a stored value	never	never

Good practice

1. One entry per use, named for that use: "Stripe production", "Slack support". Removing one team's access is then deleting one entry, without breaking the others.
2. Use the vendor's scoped keys (read-only, restricted) rather than the master key. The vault protects the value, not the powers it carries.
3. Rotate regularly. Edit the entry and every member follows automatically, with nothing to change on their side.
4. Check usage before deleting — the confirmation shows how many connections will stop.
5. Someone leaves? Nothing to do about secrets: they never had them. Just deactivate the account.

Editing an entry

The fields appear empty — that is expected, values cannot be read back. A field left empty keeps its value; a field you fill replaces it. So you can rename an entry, or change a single field, without knowing the others.