Storing Credentials for HTTP-Request Steps Safely
Credentials you store for a workflow's HTTP-request steps are sealed with AES-256-GCM encryption and are never handed back to you or anyone else — only a hint is.
Before you paste a production API key into any workflow tool, it's a fair question to ask where it's stored and who can read it back. Here's the direct answer for Workflows.
How credentials are stored
Credentials used by HTTP-request steps are held in their own dedicated table, sealed at rest with AES-256-GCM encryption, keyed by a platform-level encryption key that never leaves the backend. They're managed from a credentials panel in the editor, separate from the workflow logic itself.
The part that matters most: no read-back
Once a credential is stored, it is never returned to a caller — not through the API, not through the UI. If you need to check which credential is attached to a step, you'll see a short hint, not the value itself. This is the same pattern the platform uses for AI provider keys elsewhere: write-only, hint-only, by design.
Why this is worth stating plainly
For anyone doing due diligence before connecting a workflow tool to production systems, "can this thing ever show my key back to someone, accidentally or otherwise" is the real question — and the honest answer here is no, structurally, not just by policy. A credential goes in encrypted and stays that way; the only thing that ever comes back out is a hint short enough to recognize, not enough to use.
If security review is part of your rollout process, this is the concrete detail to point to rather than a general assurance.