The Credentials Problem
Every automation workflow needs credentials. Webhook URLs, API keys, database passwords, SMTP credentials, OAuth secrets — the list grows with every integration you add.
These credentials are almost always stored badly. Environment variables committed to version control. Plaintext in YAML config files. Hardcoded in cascade definitions that get exported or shared. Stored in a team password manager that was not designed for programmatic access.
The Sentinel Vault is built for exactly this use case — secrets that need to be accessible to automated workflows, stored securely, and never exposed in plaintext to the tooling that uses them.
Encryption at Rest
All secrets in the Vault are encrypted with AES-256-GCM before storage. This is not transparent encryption at the storage layer (which only protects against physical disk theft) — it is application-level encryption where the plaintext value is never written to the database.
The encryption key is derived from a platform-level secret combined with an account-specific salt. Even with direct database access, encrypted values cannot be decrypted without the platform key.
Each encrypted value is stored with its associated IV (initialisation vector) and authentication tag — the GCM mode provides both confidentiality and integrity. A tampered ciphertext is detectable, not silently corrupted.
Accessing Secrets in Cascades
Secrets are referenced by name in cascade definitions using the $env.*$ syntax:
- name: notify
type: http
method: POST
url: "$env.DISCORD_WEBHOOK_URL$"
headers:
Authorization: "Bearer $env.STRIPE_SECRET_KEY$"
At cascade runtime, the reference is resolved to the plaintext value in memory. The plaintext value is used for the API call and then discarded — it is never written to logs, Nexus Reports, or the database.
If a cascade step logs its inputs for debugging purposes, secrets referenced via $env.*$ are automatically redacted in the log output, replaced with [REDACTED].
Secret Types
The Vault supports structured secret types with validation:
API Key — A single string value. Validated as non-empty on save.
HTTP Header — A key-value pair for use in HTTP step headers. Stored together, resolved as a header tuple.
Credential Pair — Username + password. Stored as a unit, accessible as $env.SECRET_USER$ and $env.SECRET_PASS$ separately.
Webhook URL — A URL string. Validated as a valid HTTPS URL on save.
SMTP Config — Host, port, username, password stored as a unit for the mail system.
PEM Certificate — Base64-encoded certificate or key material. Used for mTLS and signing workflows.
Typed secrets provide two benefits: validation catches configuration errors at save time rather than at runtime, and structured secrets can be accessed by component rather than the whole value where appropriate.
Access Control
Secrets are scoped to their owner by default:
- User secrets — accessible only to the owning user's cascades
- Team secrets — accessible to all members of a team, for shared infrastructure credentials
- System secrets — platform-level secrets (SMTP, Discord, etc.) set by the account owner and available to all cascades in the account
Access control is enforced at the resolution layer, not the storage layer. Even if two users share the same platform instance, user-scoped secrets are never resolvable in another user's cascade runtime.
Secret names are visible to users with appropriate access. Secret values are write-only after creation — you can update or delete a secret, but you cannot read back the plaintext value after saving. If you need to verify a secret, rotate it rather than reading it.
Secret Rotation
The Vault includes a rotation workflow for API keys and credentials:
- Add the new value under the same secret name with the "stage as pending" flag
- The old value remains active; the new value is staged
- Test your cascade with the new key using the "test with pending" option
- Promote the pending value to active — the old value is archived, not deleted
- Verify the cascade runs correctly
- The archived value is purged after the configured retention period
This zero-downtime rotation means you can update credentials without scheduling maintenance windows. Running cascades continue using the active value until their current run completes; new runs pick up the promoted value.
Sentinel Budget + Vault Integration
The Sentinel system combines secrets management with budget tracking. Financial API keys (Stripe, payment processors, expense APIs) can be tagged as financial credentials, enabling the Sentinel budget monitoring to attribute costs to the specific secrets used in each transaction.
This means you can see not just what you spent, but which automated workflow spent it and which credential it used. If an unexpected charge appears, the audit trail leads directly to the cascade step and the Vault secret reference that triggered it.
Compliance Considerations
For teams with compliance requirements, the Vault provides:
- Audit log of every secret access (resolved in cascade step, updated, rotated)
- Retention policy — configure how long archived (rotated-out) values are kept before purge
- Access log — which users have viewed or modified which secrets
- Export capability — export the audit log in SIEM-compatible format
The Vault is not a replacement for a dedicated secrets management solution at enterprise scale (HashiCorp Vault, AWS Secrets Manager). It is the right tool for small and mid-size deployments where you want security without dedicated secrets infrastructure.
Your credentials are not configuration. Treat them like the sensitive data they are.