Every verdict is cryptographically linked to the one before it.
Each audit entry includes a hash of the entry before it, so they form a chain:
Edit any past entry and its hash changes, which breaks every entry after it. The chain snaps visibly. The verifier walks every link on your own machine, so you don't have to trust the server to tell you it's fine.
Same trust property. Three audiences.
Cryptographic integrity
Each verdict is chained to the previous one. Modify any historical entry and the chain breaks visibly. Run our open-source verifier against your log anytime. You don't have to trust us, you can check.
Tamper-evident, customer-verifiable
A tamper-evident trail for every governed commit, each entry cryptographically linked to the last. Run our verifier on your own infrastructure to confirm nothing was altered, deleted, or reordered, the same property behind certificate-transparency logs, applied to code governance.
A statement you can audit
Every review creates a permanent, tamper-proof record, and a tool to verify it wasn't changed by us or anyone else. Like a bank letting you audit your own statement history without taking the bank's word for it.
One command. No vendor in the loop.
The verifier is a standalone tool with two modes:
- Offline, walks the chain locally, no network. For air-gapped audits or verifying a snapshot.
- Online, also checks your recomputed head against the server's, catching both local tampering and server-side divergence.
Verify your own ledger.
Pull the verifier from the Ovyero SDK, point it at your audit log, get a clean exit code or a list of broken chain links with line numbers.
A broken link exits non-zero with the affected line and expected-vs-actual hashes, capture it and follow our discrepancy protocol (rare, treated as high-severity with an SLA). Prefer no install? Paste a bundle into the browser verifier at /trust/proof, same verifier, running it locally stays the zero-trust path.
The chain proves nothing changed. The signature proves it came from us.
Two different guarantees, and Ovyero gives you both:
- Integrity is the chain, any edit snaps a visible link, proving contents are unchanged.
- Authenticity is the signature, exported bundles are signed with Ovyero's ledger-signing key — a private key held only on our servers, distinct from the API key you use to authenticate — proving the bundle really came from Ovyero.
Integrity alone isn't enough: a tamperer can recompute hashes to look consistent again. Only the Ovyero private key produces a signature that verifies against our published key, so a valid signature could only have come from us.
Verify the signature yourself.
Every signed bundle embeds the public key and fingerprint it was signed with. Confirm that fingerprint matches the one we publish, then the verifier checks the signature for you. No vendor in the loop.
The live fingerprint is always at /trust/pubkey, treat that as the source of truth. Key rotations are published, never silent: the full record of which key was active when is at /trust/key-history, so a bundle signed under an earlier key still verifies against the right one.
We never store your source. We never publish your records.
The chain is about integrity, not exposure. We never publish customer ledgers. What goes in:
What gets recorded
- Verdict metadata, pass / advise / block, finding categories, rule IDs, line numbers, timestamps
- SHA-256 hash of each governed artifact (so the chain can prove which version was reviewed). never the artifact itself
- Authorship attestation, human / AI / mixed, per-commit
- Rule-set version + active critic catalog versions (so verdicts are replayable against the exact rules in effect)
What never gets recorded
- Your source code. Your code is sent to our server over TLS only to be evaluated, held in memory for the length of that evaluation, then discarded. It is never written to disk, databases, backups, or the audit log.
- Your file contents. The chain records a SHA-256 hash of each file to prove which version was reviewed, not the file itself.
- Your secrets, API keys, or any literal value from your codebase.
Verdicts come back categorical (rule IDs, line numbers, severity), never source, which is how the chain stays in MB, not GB.
The proof, updating in real time.
On a schedule (and on every deploy), Ovyero pins a fingerprint of the whole ledger to DigiCert's RFC 3161 timestamp authority. You can't backdate a timestamp, so anchored history can't be rewritten. Opaque hashes only, no code, no customer data.
Loading live anchors…
Or check a token against DigiCert yourself: base64-decode a tokenBase64 from
/trust/anchors to anchor.tsr and run
openssl ts -reply -in anchor.tsr -text.
Prove one specific record is included.
Integrity and anchoring together already give you record-level inclusion: every exported bundle carries a
chain_proof that ties each row's audit_id and hash to the hashes on either side of it,
and the chain head is what gets anchored to DigiCert. So proving a single verdict is genuinely part of the
anchored history is three steps, no vendor in the loop:
- Export the bundle containing the record:
aios audit export(it includes that row'saudit_id, its hash, and thechain_prooflinking it to its neighbours). - Run
aios verifylocally (or paste the bundle into /trust/proof). This recomputes the hash chain and confirms youraudit_id's row hashes to exactly what its neighbours expect — if any row were altered, removed, or reordered, the chain around your record would not close. - Confirm the chain head is anchored: match the verified head hash against a timestamp token from /trust/anchors (verified against DigiCert above). A record whose chain closes under an anchored head provably existed, in that position, before the anchor's timestamp.
There is no separate trusted "inclusion endpoint" to believe: inclusion is a property you re-derive from the signed bundle and the public anchor with tools you run. That is the whole point — the proof does not depend on us being honest, or even online.
What we cover per AI coding assistant. And what we don't.
This table is generated from a machine-checked file in our repository. Every cell marked Covered or Partial must cite a proof that passed within the last 30 days, or our CI fails. Cells we haven't tested say Unknown — we don't guess. The raw file, with every proof, is at /trust/conformance.json.
| Assistant | Commit gate | Author attribution | Transcripts stay local | Ownership signals |
|---|---|---|---|---|
| claude-code | Covered proof: commit-gate-hook · 2026-09-16 commits made by Claude Code run the installed pre-commit hook like any git commit | Covered proof: agent-trailer-claude · 2026-09-16 Co-Authored-By: Claude … <noreply@anthropic.com> trailer → agent (weighted majority per path/author); human committer preserved | Covered proof: no-transcript-egress · 2026-09-16 | Covered proof: ownership-scan-local · 2026-09-16 |
| openai-codex | Unknown (untested) untested: Codex CLI commits via git and should invoke pre-commit hooks — do not claim until a fixture proves it | Unknown (untested) no trailer pattern verified yet; if Codex stamps a Co-authored-by trailer it joins the fixture-proven agent table, never a guessed regex | Unknown (untested) Codex is reported to keep transcripts local (advisor input 2026-09-16); OUR pipeline stores none regardless — the unknown is about the assistant's side until verified | Covered proof: ownership-scan-local · 2026-09-16 |
| cursor | Covered proof: commit-gate-hook · 2026-09-16 gate fires on git commit; apply-without-commit edits are ungoverned until committed | Partial proof: bot-and-unknown-attribution · 2026-09-16 no trailer signal from Cursor; commits attributed to the human committer with author_type unknown (honest) | Unknown (untested) Cursor's own cloud sync of chats is outside our control; OUR pipeline stores none — the unknown is about the assistant's side | Covered proof: ownership-scan-local · 2026-09-16 |
| github-copilot | Covered proof: commit-gate-hook · 2026-09-16 | Not covered inline completions are indistinguishable from typing at commit time; no signal exists to attribute | Unknown (untested) | Covered proof: ownership-scan-local · 2026-09-16 |
| windsurf | Unknown (untested) untested: whether Windsurf's auto-commit flows invoke pre-commit hooks has not been verified — do not claim until the drill tests it | Unknown (untested) | Unknown (untested) | Covered proof: ownership-scan-local · 2026-09-16 |
| aider | Partial proof: commit-gate-hook · 2026-09-16 aider auto-commits; hooks fire, but aider surfaces hook failures poorly — gate blocks work, UX of the block is degraded | Covered proof: agent-trailer-aider · 2026-09-16 Co-authored-by: aider (…) trailer → agent; human committer preserved | Covered proof: no-transcript-egress · 2026-09-16 | Covered proof: ownership-scan-local · 2026-09-16 |
| raw-git | Covered proof: commit-gate-hook · 2026-09-16 | Partial proof: bot-and-unknown-attribution · 2026-09-16 human by default; author_type 'unknown' is the honest envelope value unless an identities mapping asserts human | Covered proof: no-transcript-egress · 2026-09-16 no assistant involved | Covered proof: ownership-scan-local · 2026-09-16 |
| ci-bots (Jenkins, Dependabot, GitHub Actions) | Not covered non-interactive committers bypass local hooks entirely — see docs/LAYER2_CI_BOT_SPIKE.md | Partial proof: bot-and-unknown-attribution · 2026-09-16 ATTRIBUTED (author_type machine + machine_kind via the classifier), NOT gated — the spike's P1c recommendation, shipped | Covered proof: no-transcript-egress · 2026-09-16 | Partial proof: bot-and-unknown-attribution · 2026-09-16 bot activity is recorded and surfaced as machineActivity but bots are never owners |
17 covered · 5 partial · 2 not covered · 8 unknown. The commit gate sits at git, so it applies to any assistant that commits; attribution is only claimed where the assistant leaves a verifiable signal (a commit trailer). Bots are attributed but not gated by the local hook.
- Commit gate — staged files evaluated by the governance server at commit time (pre-commit hook)
- Author attribution — author_type (human|agent|machine|unknown) attached to ownership signals / verdict envelopes
- Transcripts stay local — AI transcripts never leave the machine (serializer forbids transcript/trailer/message fields)
- Ownership signals — local git aggregates uploadable via `ovyero ownership scan` (counts + classification only)
You don't have to trust the vendor. You can verify your own data.
Your governance records are yours, and their integrity is yours to verify with a tool we ship openly. That holds whether Ovyero is online or not, and whether you're auditing for SOC 2 next week or in a deposition five years from now. Build records that survive.
Where it runs. Ovyero is hosted on Railway (AWS us-east). The full, versioned list of every infrastructure sub-processor — who they are, what data they touch, and the region — is published for procurement at /legal/sub-processors (machine-readable at /legal/sub-processors.json).