Security and Secret Encryption
Flashback applies a consistent secret-encryption model across the platform. This model is not limited to Cloud Storage: it also applies to AI resources and to any connected resource that requires credentials, tokens, API keys, or private material.
Why this is a dedicated platform topic
Secrets are used in multiple places, including:
bucket and container credentials,
AI provider credentials,
repository-level integrations,
and future resource connectors added to the gateway.
Because the same trust model is reused everywhere, encryption and decryption behavior should be understood as a platform security principle rather than a feature of one page or one connector.
Core model: encrypted at rest, isolated decryption path
All secrets in Flashback are encrypted in the backend database using an RSA-based mechanism where the backend service itself does not hold the complete ability to decrypt plaintext secrets directly.
This gives two practical outcomes:
Secrets remain unreadable as plaintext in persistent backend storage.
Secret decryption is moved away from the regular backend request path.
Do not use Flashback as a backup vault for recovering original provider keys. Treat it as a secure execution store for connected resources, not as a secret-recovery system.
Decryption lifecycle on Bridge Nodes
Decryption is handled by Bridge Nodes through a federated shared-secret process:
On startup, a Bridge Node retrieves encrypted secret payloads needed for authorized operations.
Decryption occurs only inside the node runtime in memory.
Plaintext secrets are not written to disk or long-term storage.
When the node stops, in-memory secret material is purged and must be re-established on next startup.
This reduces persistent exposure and avoids concentrating decryption capability in a single always-on backend surface.
Scope of application
The same model applies whenever Flashback needs to act on behalf of your configured resources, including:
Cloud Storage connectors,
AI/LLM connectors,
and other gateway resources that use delegated credentials.
As new resource types are introduced, they inherit this same security baseline so governance and operational behavior stay consistent across the platform.
Repository API key secret handling
Repository API keys (storage and AI) follow the same platform model and add important operational constraints:
API key secrets are encrypted at rest in backend storage.
Full plaintext secret values are shown only once in the UI at key-creation time.
After the creation view is closed/reloaded, the secret cannot be retrieved again.
If the secret is lost, you must generate a new key and rotate client credentials.
Never treat Flashback as a secret-recovery mechanism for repository API keys. Build your runbooks around immediate copy, secure storage in your own vault, and deterministic key rotation.
For repository operations and key-management workflows, see:
Operational guidance for teams
To use this model effectively in production:
Keep original credentials in your own enterprise secret-management process.
Rotate provider keys and tokens based on your security policy.
Use least-privilege scopes when creating external credentials.
Review Bridge Node operational security (runtime hardening, access control, and monitoring).
Related pages
Last updated
Was this helpful?