Credentials and secrets

A Credential is a secret you store once and reuse everywhere. It can be an API key, a bearer token, basic auth, an OAuth2 client, an AWS key, or a database login. The store checks each secret against its type before saving, encrypts it at rest, and never hands the secret back on a read. Anything that needs the secret (a discovery source, an external capability, a workflow) looks it up and uses it on demand. So a key is configured in one place and consumers never hold their own copy.

When you’d use it

• Store a secret a connector needs, such as an API key for a discovery source or an external system.
• Reuse one credential across several consumers instead of pasting a key into each.
• Rotate a secret in one place when it changes.
• Keep secrets out of records and logs by referencing a credential rather than embedding a key.

What you manage

Credentials live under Credentials (/admin/credentials). The discovery Credential Vault page shows the same store alongside agent sweep credential sets, so a credential created in either place is selectable when you set up a discovery source. For each one you set:

• A type. Basic, bearer, api_key, oauth2, custom, aws, or database.
• The secret values for that type, checked against its schema before it saves.
• The connection settings for that type, such as a token URL, scope, or username. Edit shows them filled in and lets you change them in place; secret fields stay hidden, and pasting a new value replaces one without retyping the rest.
• Rotation. Replacing the values when a secret changes. Change secret replaces every field at once; a paste into a single secret field on Edit replaces just that one.

Create and rotate credentials in the admin guides.

Good to know

• A read never returns the secret material. You get metadata and non-secret settings back; the secret values stay encrypted and are decrypted only when a consumer uses them.
• A half-configured secret cannot be saved. It is validated against its type first.
• Deleting a credential that is still in use is refused, with the list of what references it, so a delete cannot quietly break a consumer.
• The secret-store tables are protected. The generic record editor refuses to write to them, even for a super admin.
• Agent sweep credential sets are a separate store with a different, zero-knowledge threat model: those secrets are sealed to one on-prem agent’s key on save and the platform cannot read them back. The Credential Vault page manages both stores in labeled sections.

How it connects

This primitive owns storing, validating, and encrypting platform secrets and the read interface consumers use. It does not auto-rotate or alert; it tracks rotation state, and a rotation policy is a Business rule or Workflow. Who may read or write credentials is governed by Identity and access.

• Create and rotate credentials in the admin guides.
• See how an external capability binds a credential in External capabilities.
• Exact shapes: store fl_credentials (types basic, bearer, api_key, oauth2, custom, aws, database); reads return metadata only; every term in the glossary.