Credentials & data handling

Some targets need API keys or tokens before an agent can use them. The credential model is built so that the honest description is also the reassuring one: we cannot read your credentials, and neither can our own web application.

The path a credential takes

1. Sealed in your browser. The credentials form encrypts values with a libsodium sealed box to the audit worker's public key before anything leaves your machine. The web app stores ciphertext it has no key for.
2. Decrypted only inside the job. The worker decrypts values in the isolated environment that runs your audit, injects them as environment variables for the scenarios that declared them, and nowhere else. Plan generation never receives credential values — only the variable names your target needs.
3. Verified before spend. The pre-flight smoke gate proves the credentials work before any agent run starts. A wrong key fails there, with a clear message and nothing consumed — credential problems never surface as agent results.
4. Scrubbed from everything you download. Before artifacts upload, every occurrence of every credential is replaced with a [REDACTED:NAME] marker — including base64, URL-encoded, JSON-escaped, and hex encodings of the value, so a credential can't hide in an encoded form inside a trace.
5. Purged at the end. When the audit reaches a terminal state, the stored ciphertext is deleted. Re-running later asks for credentials again rather than keeping them around.

Scope the access

Use the least-privileged credentials that make your documented tasks work — a sandbox or staging key where you have one, a scoped token rather than an account owner key. The audit does what your docs say a user can do; it needs no more access than that.

Broader platform practices — infrastructure, retention, disclosure — live on the security page. Data-export and deletion self-service is in your dashboard settings.