Security

In transit

• TLS 1.2 or better for every connection — the agent, the portal, the API and the webhook deliveries.
• The desktop agents pin the API's certificate chain, so a corporate middlebox cannot silently sit between an agent and the server.
• Evidence uploads are chunked and resumable, and each chunk's checksum is verified server-side before it is accepted.

At rest

• Evidence objects are encrypted with AES-256 in object storage, and their SHA-256 digests are stored alongside so a download can be re-verified against what was uploaded.
• Local agent logs are encrypted on the candidate's own machine.
• Passwords are stored as bcrypt hashes, never reversibly. API keys are stored as a SHA-256 hash plus a short clear-text prefix, which is what lets the portal show you sk_a1b2c3d4… in the key list without being able to reconstruct the key.

Credentials on the candidate's machine

Session tokens live in the OS keychain — Keychain on macOS, the Credential Manager on Windows, the Secret Service on Linux — and are scoped to one session. They are not written to a config file, and they expire when the session ends.

Installers and updates

The download page publishes each artifact's SHA-256 next to it, and updates are delivered through a signed manifest, so the update channel cannot be used to serve a build the release process did not produce. Publisher certificates for macOS and Windows are not in place yet, so macOS and Windows will warn that the publisher cannot be verified the first time the app is opened — compare the SHA-256 before you continue.

Organization controls