Secrets management
How Scrydon stores and retrieves credentials — three strategies (LOCAL / BYOK / HYOK), redaction at every boundary, and audit on every access.
Every credential Scrydon handles — OAuth tokens, API keys, SMTP passwords, vendor secrets — is encrypted at rest and redacted in logs, exports, and analytics events. This page documents the three storage strategies and the access model.
The three strategies
Scrydon manages the encryption key. Secrets are encrypted at rest in the platform database using AES.
- Simplest to operate — no external KMS needed.
- Encryption key is held in a Kubernetes secret you control.
- Encrypted values are stored in the platform database.
Use LOCAL when your operations team isn't ready to bring an external KMS into the platform's hot path.
You provide the encryption key. The encrypted material is still stored in the platform database, but the data-encryption key (DEK) is wrapped by a customer-managed key in your KMS.
Supported KMS providers:
- AWS KMS
- Azure Key Vault
- HashiCorp Vault
- GCP KMS
Use BYOK when your security policy requires customer-controlled encryption keys but you accept ciphertext at rest in the platform database.
The secret value never lives in the platform. Scrydon stores only a reference URI; the secret is fetched at runtime from your KMS or vault for each authorised use.
Supported KMS providers:
- AWS KMS
- Azure Key Vault
- HashiCorp Vault
- GCP KMS
Use HYOK when your security policy says the platform database must not contain even encrypted credential material.
The vault API
Secrets are accessed through a small typed API. Every call is authorisation-gated and audited.
| Endpoint | Who can call it | Purpose |
|---|---|---|
/secret/save | Workspace admin or higher | Create or update a secret with encryption. |
/secret/get | Workspace admin or higher | Retrieve the decrypted value. |
/secret/delete | Workspace admin or higher | Delete a secret. |
/secret/list | Workspace member or higher | List metadata only. Values are never returned by list. |
/secret/save-bulk | Workspace admin or higher | Batch create / update. |
/secret/get-bulk | Workspace admin or higher | Batch retrieve. |
/secret/admin/get | Service-to-service only (mTLS) | Internal service access — used by the workflow runtime to inject credentials. |
The internal endpoint requires SPIFFE / Dapr mTLS — there is no user path to it. See SPIFFE / mTLS.
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:
| Key | Treated as |
|---|---|
tokenCount: 100 | Not a token — preserved |
passwordStrength: "strong" | Not a password — preserved |
authMethod: "oauth" | Not auth data — preserved |
tokenizer: "gpt" | Not a token — 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
Every secret operation is captured in the audit log:
SECRET_CREATE,SECRET_UPDATE,SECRET_DELETE,SECRET_ACCESSPROVIDER_CREATE,PROVIDER_UPDATE,PROVIDER_DELETE,PROVIDER_TEST
Each event records the actor ID, IP address, user agent, and a metadata object describing the affected secret (without the value).
Audit retention is configurable per organisation. Default is 365 days; some compliance frameworks require longer — see Compliance for the framework-specific defaults.
Related
- Audit logging — what's captured on every secret access.
- Authorization — execution grants for secret reads in workflows.
- Permission model — who can call which endpoint.
- Redaction — full pattern catalogue for logs and events.