Skip to content
CertiQA is in early access. Request access

7.6 Encryption at Rest and in Transit

What is encrypted, where, and what (if anything) you need to do about it.

Short version: nothing. Encryption is on for every workspace and every plan. There is no setting to enable. The only things you may notice are described under What You Might Notice.

Connection Protection
Your browser, the CertiQA CLI, CI jobs and integrations to CertiQA HTTPS (TLS) only
CertiQA services to the database TLS is required by the database, and CertiQA checks that the server’s certificate belongs to the database before it connects
CertiQA services to object storage HTTPS (TLS)
Calls CertiQA makes to your agent or API under test The address you configure. Use https:// for anything that carries real data
Between CertiQA’s own services inside its private network Private network only, authenticated with a service token
Data Protection
Vault secrets, provider keys, third-party credentials AES-256-GCM envelope encryption. With CMEK on Enterprise Ultra, the master key is yours
Agent conversations, tool-call arguments, judge reasoning, step and tool-call results, world state, review-queue text and traces Encrypted again at the application level (AES-256-GCM) before it is written to the database, in addition to disk encryption
Database storage and backups Encrypted at the storage layer
The run archive and other files in object storage Encrypted with a CertiQA-controlled key (AWS KMS) with automatic key rotation

Run results, conversation text and similar content are encrypted with a CertiQA platform key, not your CMEK key. That means reading your own results never depends on your key provider being reachable. Per-workspace keys for run data are planned for Enterprise Ultra and are not available yet.

  • Run archive files are readable. CertiQA decrypts content before it files it, so the .jsonl.gz files you download contain ordinary JSON. Treat the downloaded files as sensitive: once they leave CertiQA, their protection is yours. See Data Retention and the Run Archive.
  • Statuses, timings, names and counts are not encrypted. Pass/fail status, durations, case and scenario names, token counts and cost figures stay readable so that dashboards, trends and flake analysis work. Do not put secrets in case names or step descriptions; use Vault.
  • Error messages are stored readable. If your application echoes personal data in its errors, those errors appear in run summaries. Fix the source, or mask the value in your application’s error output.
If you… Then
Test an agent or API that holds real customer data Point CertiQA at it with https://, and keep credentials in Vault ({{vault.NAME}}), never in step text
Use the CertiQA CLI or the self-hosted runner Nothing. Both connect over HTTPS. If your network inspects TLS, set NODE_EXTRA_CA_CERTS to your corporate CA bundle
Download run archive files Store them where you store other test evidence that may contain customer data, and delete them when you no longer need them
Need your own keys Enterprise Ultra can bring its own AWS KMS or HashiCorp Vault key for secrets. See CMEK and Key Rotation
Run CertiQA in your own VPC Follow Private VPC Deployment. Require TLS on your own database and keep certificate verification on

Can CertiQA staff read my run conversations? The content is encrypted in the database. It is decrypted by the CertiQA service when you or your team open a run, and by the archive job when it files your results. Access to production systems is limited to named operators, and admin actions are written to the audit log.

Is CertiQA certified (SOC 2, ISO 27001)? Not yet. We do not claim certifications we do not hold. Ask your account contact for the current security questionnaire answers.

What happens to the encrypted data when a workspace is deleted? It is deleted with the workspace, including the run archive. See Data Retention and the Run Archive.