Secrets

Connectors need database passwords; generative capabilities need provider API keys. Secrets is the organization's central, encrypted store for those credentials — so one database password lives in one place, is rotated in one place, and is never scattered across a dozen connector forms.

The core promises

• Write-only. A secret's value can be set and rotated, but never read back — not in the UI, not in the API, not in audit records. What the platform cannot show, a leak cannot show.
• Typed. A secret declares what it is (db_credential, llm_api_key, s3_credential, …), and a consumer can only resolve the matching type — a database password can never be handed to something expecting an API key.
• Reference-counted. A secret that is still used by any connector or model adapter cannot be deleted; the Studio tells you it is "in use by N" instead. No silent breakage at 2 a.m.
• Rotation propagates instantly. Every consumer resolves the secret by reference at use time, so rotating the value updates all of them at once — no re-configuration, no re-pinning.

Secrets vs API tokens

Easy to confuse, opposite directions:

Working with secrets in the Studio

1. Go to Secrets in the sidebar (organization admin permission).
2. Create a secret: name, type, value. The value disappears from view the moment it is saved.
3. Where a credential is needed — the connector form, a model adapter in AI Studio — use the secret picker to reference it (or create one inline without leaving the dialog).
4. Rotate when the upstream credential changes; every consumer picks up the new value on its next use.
5. Delete only succeeds once nothing references the secret.

Inline credentials (typed directly into a connector or adapter) still work — the central store is the better habit, not a forced migration. New credentials, and anything shared by more than one consumer, belong here.

Next

• The biggest consumers: Connectors and AI Studio.