ClairAudit

Controls you can inspect, not adjectives.

This page lists how the platform is built. It does not list certifications. For reports, questionnaires or a controls walkthrough, contact us.

Controls register

Descriptions reflect the current platform implementation. Technical detail on the audit trail and verification is in the documentation.

RefAreaControl
C-1 Tenant isolation Every request runs inside a Postgres row-level security context scoped to the tenant and user. Queries, including natural-language queries, cannot read outside it.
C-2 Authentication RS256-signed JWTs with separate audiences for the app, administration, the MCP server and the client portal. WebAuthn second factor. SAML and OIDC single sign-on.
C-3 Secrets and credentials Connector credentials and OAuth tokens are encrypted with AES-256-GCM before storage. Passwords are hashed with Argon2id.
C-4 Audit trail Append-only and hash-chained. Update and delete are blocked at the database, the service exposes append only, and a CI lint rule fails the build on any other write path.
C-5 Independent timestamping The chain is re-verified daily. Merkle roots of the trail are submitted to OpenTimestamps calendars and, where configured, anchored on the Base Ethereum L2, so the record can be checked outside ClairAudit.
C-6 Sign-off integrity Workpaper and report sign-offs are recorded with signatures and appended to the trail. Electronic signature is available through DocuSign or Adobe Acrobat Sign.
C-7 Evidence handling Uploaded evidence is scanned and stored with a content hash, so the file a finding cites is the file that was reviewed.
C-8 AI output controls Findings require a standards citation and pass a verifier score, or are flagged for human review. Model usage is attributed per tenant.
C-9 Data residency and privacy Tenants choose a data region and can request a region move. Data-subject export, rectification and erasure requests are supported.
C-10 Control evidence A daily job records results for ten SOC 2 Trust Services Criteria controls and stores them for review. What is collected.

A record that cannot be quietly edited.

Each entry commits to the one before it. Changing any past entry breaks every hash after it, and an anchored root makes the break visible to anyone holding the published root.

How the trail works
  1. #10418Evidence E-12 attached to C-4.2prev 9b2e…07d1 → 3f9a…c41e
  2. #10419Finding F-07 cited to ISA 570 ¶16prev 3f9a…c41e → a8c0…5b93
  3. #10420Verifier score 0.91 recordedprev a8c0…5b93 → 71de…e20a
  4. RootMerkle root submitted for timestampingroot 5c47…19fb
  5. Sample · illustrative values

Found something? Tell us first.

Email [email protected] with a description, steps to reproduce, the impact you see and how to reach you. Please do not open a public issue.

In scope: app.clairaudit.com, api.clairaudit.com, admin.clairaudit.com, portal.clairaudit.com and their APIs. Out of scope: third-party dependencies (report upstream), social engineering, physical attacks and denial of service. We coordinate disclosure timing with you and credit researchers unless you prefer otherwise.

Bring an engagement. We will walk the file with you.

A demo covers your audit methodology, the standards you report under, and how agents, citations and review gates would fit your team. Pricing is discussed on the call.