How client credentials are stored

Last updated: · By Radim Sekera

At some point in almost every project, someone needs a password. A WordPress admin login, a domain registrar's API key, the FTP credentials for a hosting account nobody has touched in three years. The usual path for that value is an email, a chat message, or a shared document — all of which keep a plaintext copy of a working credential sitting around indefinitely, readable by anyone with access to that inbox, channel, or drive.

BriefGate's secret item type exists so that path doesn't have to be the default. This page explains exactly what happens to a credential a client types into the portal, what protection that buys you, and — just as importantly — what it does not. We would rather you know precisely where the line is than assume a stronger guarantee than the one that actually exists.

What happens when a client fills in a secret field

On the portal, a secret item renders as a masked password field with a lock icon and a note: "Encrypted — shown once to your provider only." There is no show-all, no copy-to-clipboard trail, and no way to recover the value through the portal once it has been submitted.

When the client submits it, the value travels to the server over HTTPS. On arrival — before anything is written to the database — it is encrypted with a libsodium sealed box (crypto_box_seal) using BriefGate's public key. Only that ciphertext is stored. The plaintext exists in server memory for as long as it takes to seal it, and later, briefly, during a reveal — it is never written to disk and never appears in a log.

The private half of that keypair lives only in the server's environment configuration. It is never stored in the database. A stolen database dump — every row, every table — yields ciphertext and nothing else.

The property we do not have

Here is the honest part: BriefGate is not zero-knowledge, and this is not end-to-end encryption. Both of those terms mean the same thing in practice — the service operator holds no key capable of decrypting the data. That is not true here. The private key that opens a sealed secret lives on BriefGate's server, and the server that receives your client's password is the same server that can, when asked correctly, decrypt it. A product that collects a password behind a sealed box and also holds the key to open it is not zero-knowledge, no matter how the box is described.

It's worth being specific about why, rather than treating this as a shortcut. Real end-to-end encryption requires a key that only the intended recipient holds, generated and kept on a device that never hands it to the server in between. BriefGate's portal is deliberately built so a client needs no account, no app, and no setup — they open a link on whatever phone or laptop is in hand and fill in a field. There is nowhere in that flow for a client-held key to live: no persistent identity to attach it to, no install step to generate it in, no session that outlives the one form submission. And even if a key could be conjured up on the client's device for that one visit, it would then need to reach whoever reads the credential later — you, or your agent, querying the intake through the API days afterward — without the server ever seeing it. That's a substantially harder problem than this product takes on, so rather than fake the property, we don't claim it.

What sealing on arrival does buy you is real, just narrower: protection against a compromised database, a leaked backup, or a misconfigured storage bucket — the categories of incident that make up most credential breaches. It does not protect a secret from a server that has been fully compromised by an attacker capable of reading process memory or calling BriefGate's own decrypt path. Full detail on that boundary, along with the rest of the platform's security posture, is on the Security page.

Revealed exactly once

A secret can be decrypted exactly one time, through any of three paths, and all three draw on the same one-time reveal:

Whichever of these happens first gets the plaintext. Every other path is told the credential was already revealed. There is a five-minute grace window that lets the same caller — the same API key, or the same owner's dashboard session — repeat its own call and get the value again, so a dropped connection between our response and your process doesn't destroy the credential. That window is tracked per caller identity: an agent revealing through the API and the owner clicking Reveal moments later never share it. Every reveal, from any path, is written to the audit log with the actor, IP address, and timestamp.

If you spend the reveal by accident

There is no way back through the same item. A second call gets secret_unavailable: true (API) or already_revealed: true (dashboard), along with the timestamp of the original reveal. The only recourse is `request_revision`, asking the client to enter the credential again — the same recourse that applies if a secret simply expires (30 days after submission, if nobody reveals it in time) before anyone collects it.

A credential is meant to be read, not routed

An integration that replays every step of a run — Zapier's task history, a Make scenario log — is a bad place for the one and only readable copy of a credential to land, since you can't clear an entry from someone else's execution log after the fact. get_intake_results accepts exclude_secrets=true for exactly this case: every other item comes back normally, and secret items are reported as still available rather than revealed, untouched, waiting for a dashboard click or a deliberate follow-up call. Downloading an intake as a ZIP (GET /v1/intakes/:id/download) follows the same default — leave include_secrets off and the file contains everything else, with credentials simply absent; set it to true and the download itself becomes the reveal, embedding the values in podklady.pdf. That's a deliberate, explicit choice each time, not one you can trip over.

The pattern we'd recommend follows from this: let an agent collect files, text, and structured answers on autopilot, and let a person open the dashboard and click Reveal when a credential like a hosting login actually needs to be typed into a server or a control panel — once, by someone, rather than carried from step to step through a workflow tool.

What this buys you

A client's WordPress password, API key, or hosting login doesn't have to sit in an email thread, a Slack channel, or a support ticket, outliving its usefulness by years. It arrives encrypted, stays encrypted at rest, can be read exactly once by whoever needs it, and every one of those reads is logged. That's a real improvement over how credentials usually move between a client and whoever is building their site — even though it stops short of a guarantee that BriefGate itself cannot see the value in flight. See Secrets Vault for the full API reference, and Security for how this fits into the rest of the platform.

Related guides

Not a developer? See the client-friendly intake page, or browse the full guides hub.