Secrets management

A secret's source and its organization's key custody are separate settings. Open Settings → Platform → Secrets to manage both. Lists show metadata; they never return secret values.

Choose the source

Stored does not mean platform-managed: a stored secret can use a customer-held key. Referenced values enter process memory for their authorized use, but are not saved as secret ciphertext or cached by the reference resolver.

Organization secrets are private by default. Share with workspaces makes an organization secret available to its workspaces. A workspace secret with the same name takes precedence; the workspace list still shows the shared one, marked Overridden in this workspace. Encryption follows the owning organization's policy, including inherited secrets and extension credential columns.

Choose key custody

The page has three tabs: Organization and Workspace list secrets in each scope, and Connections holds the Encryption key section (who holds the key, its access mode, and migration coverage) above the list of vault connections. Add connection supports:

• OpenBao / HashiCorp Vault Transit: token, AppRole, or Kubernetes authentication; optional private CA and client certificate. Turn on Referenced secrets to read values from the vault's KV v2 store; a test path is optional. Only such a connection can back a referenced secret; with none, Create Secret → Referenced says so and links to the Connections tab, where you can turn it on for an existing connection without re-entering its credentials. Test connection checks an unsaved connection, and saving refuses one the vault does not accept.
• Azure Key Vault: public Azure cloud, RSA wrapping key, and federated workload identity. The deployment supplies the projected identity token; no client secret is stored.

Kubernetes and Azure workload identity authenticate as the Scrydon deployment itself, so the deployment operator must first bind your organization to that vault. Vault URLs must be public HTTPS hosts unless the operator allows private networks. See Operator prerequisites.

When Test connection cannot reach the vault, it says why:

Every stored value is sealed together with the organization that owns it. A value copied into another organization's record does not decrypt there, even while the original vault still answers.

The default is platform-managed encryption. Selecting a customer connection probes it, changes custody, and re-encrypts existing stored secrets and organization extension credentials in bounded batches. Keep the previous connection and key available until coverage is complete. Use Resume after an interrupted migration. A connection cannot be deleted while selected or while ciphertext or references still depend on it.

Verify revocation performs an uncached unwrap. Its result does not flush other processes' caches. A successful uncached denial and the displayed TTL together describe the revocation boundary. An organization with no customer envelope cannot perform this check. Vault failures return a typed CUSTODY_* error and HTTP 503; they never select platform custody automatically. Bulk operations report individual failures.

For setup, recovery and a reproducible drill, see Bring or hold your own key.

References

For Vault KV v2, enter a relative path such as applications/payments#token; omit #token to return the complete data object as JSON. Do not include /v1, the KV mount, /data, or a URL. For Azure, enter the secret name without a field suffix. Read now checks access without displaying the returned value. A missing or denied reference fails the operation rather than supplying an empty value.

API and permissions

Connection management is organization-scoped. Workspace ownership is resolved from persisted membership, never from a caller's claimed organization. Use custody actions rather than generic organization-policy updates: generic writes to secrets.keyCustody are rejected.

Log and event redaction

All logs and analytics events pass through a redactor before leaving the system. The redactor recognises two patterns:

Sensitive keys (suffix-based) — any key ending in api_key, access_token, refresh_token, client_secret, private_key, auth_token, secret, password, token, credential, authorization, or bearer is redacted.

Sensitive values (regex-based) — bearer tokens, basic-auth headers, API-key prefixes (sk-…, pk-…), and JSON credential fields are pattern-matched and replaced.

For analytics and error reporting, sensitive keys are removed entirely, not just masked, so they never enter the event store at all.

False-positive prevention

Keys where the sensitive word is a prefix (not the full token) are preserved:

Workflow sanitisation on export / share

Before any workflow is exported or shared as a template, sensitive data is stripped, not redacted:

• OAuth credentials → null.
• Password fields → null.
• Workspace-specific selectors (knowledge-base, document, file, channel, folder, project, MCP server) → null.
• Workspace-specific field IDs (knowledgeBaseId, documentId, fileId, projectId, channelId, folderId, tagFilters) → null.
• Legacy data fields matching credential / oauth / token / secret patterns → null.

Environment variable references ({{VAR}}) can optionally be preserved for export scenarios — useful when you want a template that re-binds to the importer's environment.

Audit

Secret and provider operations use the existing audit system. Custody changes, migration progress and uncached verification emit CUSTODY_CHANGED, CUSTODY_REENCRYPT_PROGRESS and CUSTODY_VERIFY_REVOCATION. Reference reads emit SECRET_ACCESS with source: "referenced", actor or service attribution, and a success/error code. Values, tokens and private keys are excluded.

Related

• Bring or hold your own key
• Audit logging
• Authorization
• Redaction