Your evidence stays with you. Our claims are yours to check.

Where your data lives

BitExact is self-hosted. It runs entirely inside your infrastructure, and the record it keeps is written to storage you control.

• No hosted service, no telemetry. There is no BitExact-hosted service and no multi-tenant plane. The product has no telemetry and makes no outbound connection of its own; this is architectural, not a setting. An air-gapped deployment is fully functional.
• Copies leave only when a person makes them. Exports, evidence packs and archives are written where an operator points them. No copy leaves the deployment unless someone exports it.
• Encryption at rest is your platform's. BitExact makes the evidence tamper-evident, not unreadable. It creates its directories and files owner-only, and bitexact health warns when they are not; put the store on an encrypted volume or an encrypted database, and encrypt its backups.

The four connections that leave, and only when you configure them

1. Timestamp authority

   To anchor a run in time, BitExact sends only a SHA-256 hash of the run's head to an RFC 3161 timestamp authority you choose. No recorded content.

2. Log witnesses

   The transparency log's signed head goes to the witness addresses you name, so parties outside your deployment can confirm its history was not rewritten. Name none and the log is signed and unwitnessed.

3. Event destinations

   Signed notifications to the webhook, Splunk or Datadog destinations you configure: ids, counts, hashes and causes, never recorded content. Configure none and nothing is sent.

4. Your key service

   If you keep the envelope key or a capture key in AWS KMS, BitExact asks your KMS to wrap, unwrap or MAC with it. The key never leaves KMS, and no recorded content is sent. Keep keys in files or an HSM and nothing is sent.

Never in the way of your pipeline

A failure in BitExact's recording does not become a failure in your pipeline. When the recorder cannot do its job, because of an expired license, a full disk or an unreachable database, the agent's call goes through exactly as it would without BitExact, and the evidence declares what it missed. Witnessing and event delivery run beside recording, never in its path. One limit, stated plainly: if you route calls through the recording proxy and its process is stopped, calls pointed at it fail as calls to any stopped service would. The SDK and the collector put no process of ours in the call path.

Sources: Deployment, Compliance pack, Transparency log, Event delivery.

What we never see

• Your evidence. Recorded prompts, responses, tool calls and payloads stay in your store. No subprocessor touches customer data, because there is no hosted system for it to reach.
• Your keys. The recorder key that signs your runs lives where you put it: a file on the host, a PKCS#11 HSM where the key never leaves the hardware, or an AWS KMS envelope where the key is encrypted at rest and decrypted once at startup under your own key policy. The capture key that protects hash-only fields is kept apart from the evidence and never held in it.
• Your license check. A license is a signed file, validated on your host against the vendor public keys built into every release, with zero network calls.
• What you do send us. Every 90 days you run bitexact license request and send us the file yourself. It is signed by your recorder key, carries a TPM 2.0 attestation of the recorder host, and states your production-agent count as figures, never as the identities themselves.

Sources: Recorder-key custody, Licensing terms, Security.

How you can check us

The product ships compiled. What you rely on to trust it is open, signed or published, so you can check it without us.

• The open verifier. One Apache-2.0 Python file, never compiled, that re-derives every hash and signature in an evidence bundle. It imports nothing from the product, needs no license and makes no network call, so your auditor runs it on their own machine. Get the verifier.
• Published checksums. Each verifier version has a row in CHECKSUMS.txt and a verifier-v<version> tag. Confirm the digest through a channel independent of wherever you got the file.
• Signed releases. Each product release carries a SHA256SUMS file and a cosign-signed image, signed with our release key. Its public half, cosign.pub, is delivered with your license, so your admission controller can refuse any image that is not the signed release. Each signature is also recorded in Sigstore's public transparency log.
• An SBOM with every release. A CycloneDX SBOM attached to the image, over a pinned dependency closure held as an allowlist, audited for known vulnerabilities before every release.
• A build that checks itself. Every build lists every file it installs with its SHA-256, signed with the release key. At startup the product checks that list; if any file differs it records nothing, passes your agents' calls through and says why.
• Public conformance vectors. The bundle format is specified, and its golden fixtures and canonicalization vectors, accepted bytes and refusals, are public, so a second implementation can check a bundle without our code.

Sources: Hardening, Compliance pack, Auditor verification, Bundle specification.

Reporting a vulnerability

Send reports to security@bitexact.ai, with the affected component (recorder, viewer, SDK, command line or the open verifier), its version and the steps that reproduce it.

1. The verifier comes first. It is the trust root auditors rely on, and a verifier that accepts evidence it should refuse is the most serious class of issue this product can have.
2. Report privately. Please do not open a public issue, and do not test against a deployment you do not operate. There is no BitExact-run service holding customer evidence, so no hosted system is in scope.
3. How a fix ships. For the product, a new release with a SHA256SUMS file and a cosign-signed image, delivered to every licensed customer with the issue described in its release notes. For the verifier, a new version with its checksum row and tag, so anyone holding a bundle can verify it again.

The policy states no response-time commitment and offers no bug bounty. The machine-readable contact is at /.well-known/security.txt; the full policy is on bitexact.dev.

What we don't do

• We are not a governance layer. BitExact records what your agents did and the decisions your people and policy engines made. It never blocks a call, and it records a policy engine's verdict without ever deciding one.
• We never claim complete capture. BitExact proves that what it captured is intact. A call made entirely outside the interfaces it records never enters the record, and the verdict never says otherwise. A gap BitExact knows about is declared on the record.
• We never call you compliant. The compliance mapping states the evidence each obligation asks for and where it stops. Nothing we publish says a deployment is thereby compliant, or that BitExact is certified or approved by any regulator.
• We hold no third-party certification. We claim no SOC 2 report, no ISO 27001 certificate and no external audit. The SOC 2 evidence kit we provide on request indexes artifacts a reviewer can inspect; it is not a certification.
• We detect, not prevent, root on the host. Against a root user on the recorder host, every integrity control detects and none prevents. That is why the verifier prints a run's stated standing as the producer's statement, never as proof.

Sources: Regulatory mapping, Security, Compliance mapping.

Procurement

• The agreement. The Master Service Agreement is provided during procurement. The licensing terms it carries are public now.
• The security documentation. The security description, data processing agreement, support terms, SLA and source-escrow rider are negotiated per engagement and attach to the agreement as exhibits. Ask for the ones your review needs.
• The compliance pack. Standing answers for a security and procurement review: deployment and data handling, data at rest, evidence integrity, post-quantum coverage and the supply chain. Read the compliance pack.
• Who to write to. Licensing and pilots: sales@bitexact.ai. Security reviews: security@bitexact.ai.

Review it on your own traffic

A design-partner pilot is a fixed-term license on one deployment, recording production traffic, with direct engineering support. Your security team reviews it where it runs.