Can you prove your AI audit data is real?
Anyone can claim their code is audited. Without cryptographic proof, audit data is just trust-me assertions. VERIFY closes that gap with signed, tamper-evident envelopes that bind your identity, your audit files, and the current timestamp into a single verifiable record.
Built on VIBES audit data
AI is writing production code at scale. Developers use LLMs to scaffold applications, generate tests, and architect entire systems. Yet there is no widely adopted standard for disclosing when and how AI was involved — and even when audit data exists, there is no guarantee it hasn't been altered after the fact.
This creates blind spots with real consequences. Security teams cannot prioritize review of code carrying common LLM vulnerabilities. Compliance officers cannot verify AI provenance claims. And when a model is found to be compromised or biased, organizations have no way to prove which parts of their code were affected — or that their audit trail is trustworthy.
This is not theoretical. CrowdStrike researchers demonstrated that DeepSeek-R1 produces significantly more vulnerable code — hardcoded secrets, missing authentication, weak password hashing — when prompts contain politically sensitive context. The baseline vulnerability rate of 19% jumped to over 27%, a nearly 50% increase driven entirely by biases embedded during training.
One model, one study. The broader landscape of LLMs used for code generation remains largely unexamined.
The VIBES standard records what AI did. But without attestation, that data is self-reported and mutable — anyone could edit their .ai-audit/ files after the fact, inflating or deflating their AI usage numbers, changing prompts, or removing records entirely.
VERIFY closes this gap. It wraps VIBES audit data in cryptographic envelopes — Ed25519 signatures, DSSE containers, and temporal anchors — so that any modification after signing is detectable. The result is an audit trail you can independently verify, not just one you have to trust.
VERIFY is the security attestation extension to the VIBES standard. It provides cryptographic proof that AI audit data is authentic, untampered, and temporally anchored. Built on DSSE envelopes wrapping in-toto v1 statements with Ed25519 signatures, VERIFY transforms self-reported audit data into independently verifiable evidence.
Think of it like a notarized document for your AI audit trail. A notary verifies who signed the document, when they signed it, and seals it so any future changes are detectable. VERIFY does the same thing for your AI audit data — except the "notary" is mathematics (Ed25519 cryptography) and the "seal" is a SHA-256 hash.
Without attestation, anyone could modify their .ai-audit/ files after the fact — retroactively inflating or deflating their AI usage numbers, changing prompts, or removing records entirely. VERIFY makes that detectable.
VERIFY works hand-in-hand with the VIBES base standard. While VIBES defines what gets recorded, VERIFY proves the recorded data hasn't been altered. Together they create a complete chain of evidence: structured audit data you can trust.
The attestation pipeline transforms your raw audit data into a verifiable, tamper-evident record in seven steps.
The vibecheck CLI validates your .ai-audit/ directory — checking file structure, hash integrity, and assurance level compliance.
SHA-256 hashes are computed for your three audit files: manifest.json, annotations.jsonl, and config.json.
If your AI tool supports cosigning, it signs the PAE hash at data-creation time via its provider’s signing service. Only the 32-byte hash is sent — audit data stays local.
Your Ed25519 private key signs the same hashes inside a DSSE envelope wrapping an in-toto v1 attestation statement. Both signatures (if present) cover identical PAE bytes.
Optionally, an OpenTimestamps proof anchors the attestation to the Bitcoin blockchain for trust-minimized temporal evidence.
The vibecheck CLI sends the DSSE envelope to POST /api/attestation/submit. The server computes a content-addressed ID (SHA-256 of the canonicalized envelope JSON) and returns it. Submissions start as pending until admin review.
Server-side: GET /api/attestation/verify/{id} checks hash integrity and metadata consistency. Client-side: vibecheck verify-attestation performs full Ed25519 signature verification. The server is a thin receiver — it does not verify signatures.
The entire pipeline runs locally via the vibecheck CLI. Your private key never leaves your machine. Only the signed envelope — containing hashes, not your actual data — is submitted to the registry.
Step 3 is optional and depends on your AI tool supporting the cosigning protocol. When present, the tool provider’s signature enables the Tool-Corroborated trust tier. Without it, the attestation is Self-Attested — still fully valid.
Attestations use established cryptographic standards. Expand each section for implementation-level detail.
Attestations are wrapped in DSSE — a minimal, unambiguous signing envelope format designed for software supply chain security. The envelope separates the payload from its signature, allowing verification without understanding payload internals.
The payloadType declares the payload format. The payload is a base64url-encoded in-toto v1 attestation statement. The signatures array contains one or more Ed25519 signatures, each identified by a keyid (the first 16 hex characters of the SHA-256 hash of the DER-encoded public key). The optional keytype field distinguishes user signatures from tool provider cosignatures.
The payload inside the DSSE envelope is an in-toto v1 attestation statement. This format, used across the software supply chain ecosystem, binds a set of subjects (your audit files) to a predicate (validation metadata).
The three subject entries bind your audit files by their SHA-256 digests. If any file changes, the hashes won't match. The predicate contains validation results, project metadata, and annotation statistics from the vibecheck run.
VERIFY uses Ed25519 — a high-speed, high-security elliptic curve signature scheme. Keys are generated locally by the vibecheck CLI and stored at ~/.vibescheck/keys/.
vibescheck.key — Private key (PKCS8 PEM format, file mode 0600). Never leaves your machine.vibescheck.pub — Public key (SPKI PEM format, file mode 0644). Shared with the registry for verification.The key identifier (keyid) in the DSSE envelope is the first 16 hexadecimal characters of the SHA-256 hash of the DER-encoded public key. This allows the registry to identify which key signed an attestation without storing the full key.
Important: The itsavibe.ai registry does not verify Ed25519 signatures server-side. It is a thin receiver that stores envelopes. Full cryptographic verification requires the vibecheck verify-attestation command on the client side, which checks the signature against the signer's public key.
Every attestation receives a deterministic, content-addressed ID: the SHA-256 hex digest of the canonicalized JSON representation of the DSSE envelope.
This means the same envelope always produces the same ID, regardless of where or when it's computed. The ID is returned by the registry after submission and used in all subsequent API calls.
DSSE uses Pre-Authentication Encoding to prevent confused deputy attacks. Before signing, the payload type and payload are combined into an unambiguous byte string:
This encoding ensures that a signature over one payload type cannot be misinterpreted as a signature over a different payload type, even if the payload bytes happen to be the same. The Ed25519 signature is computed over the PAE-encoded bytes, not the raw payload.
For trust-minimized temporal proof, VERIFY supports OpenTimestamps — anchoring the attestation hash into the Bitcoin blockchain. This proves the attestation existed at or before a specific block time, without relying on any trusted third party.
The OTS proof file is stored alongside the envelope (e.g., attestation.intoto.jsonl.ots). Timestamps require Bitcoin block confirmation, which typically takes 1–2 hours.
Annotations in the audit data may include optional content anchoring fields
(anchor_context, anchor_hash, file_content_hash) and
PRISM score fields (risk_score, risk_factors). These are
included in the attestation payload hash — any modification invalidates the signature.
VERIFY uses Ed25519 key pairs for signing. Keys are generated and managed locally by the vibecheck CLI.
Keys are stored at ~/.vibescheck/keys/ with strict file permissions:
vibescheck.key — Ed25519 private key in PKCS8 PEM format. File mode 0600 (owner read/write only). Never transmitted.vibescheck.pub — Ed25519 public key in SPKI PEM format. File mode 0644 (world-readable). Shared with the registry.The keyid in every DSSE envelope is computed deterministically: take the SHA-256 hash of the DER-encoded public key, then use the first 16 hexadecimal characters. This allows the registry to match signatures to public keys without storing the full key material.
Your private key is the root of trust for all your attestations. If compromised, an attacker could forge attestations under your identity. The vibecheck CLI enforces 0600 permissions on key files. Back up your private key securely — losing it means you cannot create new attestations that chain to your existing identity.
A user's signature proves who signed the attestation. But it doesn't prove what tool produced the data. Anyone could manually create .ai-audit/ files and sign them. Tool provider cosigning closes this gap by adding a second, independent signature from the tool itself.
Think of it like a co-signed contract. The user's signature says "I vouch for this data." The tool provider's signature says "I generated this data in real time." Together, they provide assurance that the audit trail was produced by the claimed tool and hasn't been fabricated or modified after the fact.
Without cosigning, three attacks against attestation integrity remain possible:
A user manually creates audit files claiming tool involvement that never occurred. With only a user signature, there is no way to distinguish genuine tool output from hand-crafted fakes.
A user modifies tool-generated audit files before signing — inflating or deflating AI attribution numbers, removing embarrassing prompts, or adjusting timestamps.
A user creates a fake tool that emits valid VIBES data with another tool's tool_name. The data passes schema validation but was never generated by the claimed tool.
The DSSE signatures array already supports multiple entries. A cosigned attestation adds a second signature from the tool provider's infrastructure key, alongside the user's signature. Both sign the same PAE bytes, creating independent proof that both parties saw the same data.
The recommended implementation uses a remote signing service where the tool sends only the 32-byte SHA-256 hash of the PAE to the provider's signing endpoint. Your full audit data, prompt text, reasoning traces, and code never leave your machine. The provider sees only that an attestation was created and its cryptographic hash.
The tool provider signature must be generated at data-creation time. It cannot be obtained after the fact. This is what gives the cosignature its anti-fabrication property — if you didn't have the tool running when the data was created, you can't get the tool's signature later.
Tool providers publish their public keys at a standard HTTPS endpoint so that verifiers can look them up automatically:
Keys are served over HTTPS only. Providers must keep the endpoint available for the lifetime of any attestation signed with those keys. Verifiers may cache keys for up to 24 hours.
With optional tool provider cosigning, attestation trust is described in three tiers. These tiers are orthogonal to assurance levels (Low/Medium/High) — a Low-assurance attestation can be tool-corroborated, and a High-assurance attestation can be self-attested.
User signature only
A human or CI/CD pipeline attests to the data. No independent confirmation that the claimed tool produced it. This is the baseline — valid and useful, but the signer vouches alone.
User + Tool provider signatures
The tool provider independently confirms it generated the audit data at the claimed time. Strongest assurance against fabrication, post-hoc editing, and tool impersonation.
Tool provider signature only
The tool signed but no user countersigned. Valid, but indicates no human reviewed the attestation. Registries may flag these for additional review.
Tool provider cosigning is entirely optional. Existing single-signature attestations remain fully valid. Cosigning is an additional trust signal for tool providers who want to differentiate their transparency capabilities. Users can request cosigning with the --cosign-url or --cosign-key flags in the vibecheck CLI.
Protects against: data fabrication (creating fake audit files), post-hoc editing (modifying files before signing), and tool impersonation (claiming another tool produced the data).
Does NOT protect against: a compromised tool provider key (if the provider's key is stolen, attackers can forge cosignatures), a colluding user and tool provider (if both parties cooperate to produce false data), or bugs in the tool itself (the tool faithfully signs data it generates, even if the data is wrong due to a bug).
If you build an AI coding tool and want to support cosigning, you need three things:
1. A signing key pair. Generate an Ed25519 key pair. Keep the private key in your infrastructure (server-side or secure enclave). Publish the public key at /vibes/vibes-signing-keys.json.
2. A signing endpoint (recommended). Accept a 32-byte PAE hash, sign it with your private key, and return the signature. The endpoint receives only the hash — never the full audit data.
3. Sign at creation time. The cosignature must be generated when the audit data is created, not after the fact. This is the core anti-fabrication property.
See Section 11.7 of the VIBES standard for the full specification, and the Implementors Guide for integration details.
Understanding what attestation proves — and what it does not — is critical for making informed trust decisions.
To bridge the gap between what attestation proves and what it does not, VERIFY supports tool provider cosigning — where the AI tool itself cosigns the attestation alongside the user. Additionally, VERIFY defines three confidence levels that indicate how much review an attestation has received.
The project maintainer signed their own audit data. No external review. This is the baseline — it proves the data was intentionally published, but the signer vouches for its own accuracy.
A human reviewer (registry admin or third-party auditor) has examined the attestation data for consistency. The review checks structural integrity, metadata plausibility, and alignment between audit data and the project's git history.
Automated verification has confirmed hash integrity, signature validity, structural compliance, and cross-referenced audit data against the project's commit history. The highest confidence level, combining cryptographic checks with data consistency analysis.
The optional PRISM score (Provenance & Risk Intelligence Scoring Model) provides an additional trust dimension — not replacing cryptographic verification, but indicating the risk profile of the AI-generated changes. High-risk annotations (PRISM ≥ 0.6) can trigger additional review requirements before attestation signing. PRISM is a standalone extension on top of VIBES, independent of EVOLVE.
Submitted attestations are publicly viewable on the itsavibe.ai registry. The registry acts as a transparency log — a public record of who attested what, and when.
For each attestation, the registry displays: the signer's key identifier, submission timestamp, project name, assurance level (Low/Medium/High), validation result (PASS/FAIL), review status (pending/accepted/rejected), and file hash digests. Accepted attestations receive a dynamic status badge that can be embedded in READMEs.
Submissions start as pending and require admin review before appearing as accepted. This prevents spam and ensures a baseline quality bar for the public registry.
Verification comes in two forms:
GET /api/attestation/verify/{id}) — checks hash integrity and metadata consistency. Confirms the envelope structure is valid and internal references match.vibecheck verify-attestation) — performs full Ed25519 signature verification using the signer's public key. For cosigned attestations, it verifies both the user and tool provider signatures and reports the trust tier.