Your agent took an action. Something went wrong. Prevention tools tell you you tried to stop it. Project AIR tells you what happened, proves the record is untampered, and gets the proof accepted as evidence.
A court, a regulator, an auditor, an insurance loss adjuster. Every party that looks at your logs asks the same four questions. Project AIR answers the cryptographic ones by construction. You handle the procedural one. The line is explicit, not implied.
Is the record what you claim it is?
Has anything been altered since it was written?
Which system and which key produced this?
Does the process meet the formal requirements a court will apply?
Every Project AIR record is a Signed Intent Capsule: BLAKE3 content hash, Ed25519 signature over the link to the previous record. Change any byte, anywhere, and the verifier reports the exact record where the chain snaps.
OWASP's Agentic Security Initiative names "Signed Intent Capsule" as the emerging pattern for binding an agent's declared goal, constraints, and context to each execution cycle in a signed envelope. Project AIR writes that envelope for every agent step.
The format is AgDR-compatible: the same shape consumed by the open accountability.ai spec, so downstream verifiers, SIEMs, and custody chains work without proprietary tooling. Three primitives combine to produce the integrity guarantee.
{ "version": "0.2", "step_id": "01962a7f-8c4e-7a00-b4a1-8d7e92f01234", "timestamp": "2026-04-21T14:32:01.248Z", "kind": "tool_start", "payload": { "tool": "send_email", "args": { "to": "customer@acme.co", "subject": "Refund processed" }, "user_intent": "refund order #8821" }, "prev_hash": "b2e5d9f3c8a4061f...", "content_hash": "c3f6e0a4d9b5172a...", "signature": "9e5f1c3a6d0e4b7f...", "signer_key": "7c3d9a1e4b8c2f5d..." }
Every claim on this page is grounded in published law. Click through the jurisdictions. Each rule gets a concrete citation and a specific statement of what Project AIR does to satisfy it.
The procedural rules federal courts apply to authenticate and admit electronic records.
The proponent must produce evidence sufficient to support a finding that the item is what the proponent claims it is.
FRE 901Every record carries an Ed25519 signature and embedded public key. Any verifier can confirm the record is what it claims to be, offline, using RFC 8032.
Evidence describing a process or system and showing that it produces an accurate result.
BLAKE3 + RFC 8032The hashing and signing process is deterministic and reproducible. Same inputs produce the same hashes and signatures. An expert witness can describe, demonstrate, and have the demonstration independently reproduced.
A record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person.
FRE 902Records from the AIR chain accompanied by a qualified custodian certification (template generator above) self-authenticate. No live witness required.
Records created in the regular course of business, near the time of events, kept by someone with knowledge.
FRE 803Continuous instrumentation pattern: AIR writes records at the time the agent acts, as part of normal operations. Meets the "regularly conducted activity" bar when deployed as documented.
An "original" ESI includes any printout or output that accurately reflects the information. Duplicates are admissible unless authenticity is challenged.
FRE 1001-1004forensic-report.json is an accurate, human-readable reflection of the signed chain. Admissible under FRE 1003 provided the chain is preserved.
The declaration that turns a log file into self-authenticating evidence. Fill in the fields. Get a signed-ready template. Paste into Word, hand to counsel, file with your exhibit.
CERTIFICATION OF RECORDS GENERATED BY AN ELECTRONIC PROCESS OR SYSTEM
Pursuant to Federal Rule of Evidence 902(13) and Rule 902(11)
I, [Full Name], hereby certify the following:
1. I am the Records Custodian for [Operator Entity]. I am a qualified person
with personal knowledge of the electronic process and system described below.
2. The attached records are true and correct copies of records generated by the
Project AIR logging system operated by [Operator Entity] in the regular course of
business.
3. The records are stored in the AgDR (AI Decision Record) v0.2 format, a
structured append-only log in which each record contains:
a. a UUIDv7 step identifier and ISO 8601 timestamp;
b. the kind of agent step (llm_start, llm_end, tool_start, tool_end,
agent_finish, or agent_message);
c. a structured payload describing the step;
d. the BLAKE3 hash of the preceding record's payload (prev_hash);
e. the BLAKE3 hash of this record's canonicalised payload (content_hash); and
f. an Ed25519 digital signature (RFC 8032) over the concatenation of
prev_hash and content_hash, produced with a private key held under sole
control of [Operator Entity].
4. Each record is cryptographically linked to the preceding record by its hash.
Any alteration, insertion, deletion, or reordering of records is detected
deterministically by signature verification using the open-source Project
AIR verifier (air trace), which reports the exact record at which the chain
breaks.
5. The records were written at or near the time of the events they describe by
the Project AIR instrumentation deployed in the regular course of
[Operator Entity]'s operations. The records have been retained and preserved
according to [Operator Entity]'s records retention policy.
6. The Ed25519 public key corresponding to the signing key used to produce the
attached records is:
[64 hex character Ed25519 public key]
7. The attached records have been verified using the "air trace" command. The
verification output is attached as Exhibit A to this certification. The
chain verified with status "ok" for 247 records.
8. The cryptographic primitives used are industry-standard, open, and
independently reproducible. Ed25519 is specified in RFC 8032. BLAKE3 is
specified in the BLAKE3 reference specification. The Project AIR verifier
source code is MIT-licensed and available at
https://github.com/vindicara-inc/projectair.
I declare under penalty of perjury under the laws of California that the
foregoing is true and correct.
Executed on 2026-05-15 at [Location].
_________________________________
[Full Name]
Records Custodian
[Operator Entity]
Adapted from the form contemplated by FRE 902(13) and 902(11). It is a starting point, not legal advice.
Procedural requirements vary by jurisdiction and case posture. Qualified counsel should review before you sign or file.
The certification describes the system. The operator still documents key management, log retention, and access controls.
Cryptography prevents in-file tampering. It does not prevent whole-file substitution, key misuse, or retention failure. The line is explicit.
No pre-image attack, collision attack, or signature forgery is known against Ed25519 or BLAKE3 at the time of this writing. Both are conservative, audited, widely deployed choices.
A security product that overclaims is worse than useless. Here is what Project AIR does not do.
No cryptographic architecture guarantees a record will be admitted in any given proceeding. Courts apply the rules to the facts.
For the strongest timestamp admissibility, countersign with a trusted timestamp authority (RFC 3161) or an eIDAS qualified timestamp service.
AIR produces advanced electronic signatures under eIDAS. Qualified status requires a certificate from an EU-listed Qualified Trust Service Provider.
Cryptographic primitives are on us. Key management, log retention, and access control are on you.
Strongest mapping is US FRE, EU eIDAS, EU AI Act, and GDPR. Other jurisdictions have analogous rules; local counsel handles the procedural fit.
Past signatures remain valid (the attacker cannot retroactively forge). Records produced between compromise and revocation are attacker-controlled. Standard opsec applies.
Instrument your agent, write the chain, hand your custodian a pre-filled certification. Read the EU AI Act post-market monitoring playbook, or pick the pricing tier that covers your stack.