Receipts

Every action proved, not just logged.

Receipts is a quorum-attested, tamper-evident record of every action: who acted, under what grant, with what context, and where it was published. It powers real-time monitoring across thousands of agents at once, with events emitted in OCSF format for direct ingestion into SIEM and SOAR backends.

Logs tell you what a system says happened. Evidence should be harder to rewrite.

The problem

A log is written by the system you are asking about.

That is fine until the question matters. When an incident is disputed, the record and the thing under investigation share an owner.

What a log gives you

A record you have to trust

  • The system under question is the same system that wrote the record.
  • An operator with the right access can change it, and the change looks like the original.
  • Verifying it means trusting whoever runs the infrastructure it sits on.
  • Denials and refusals are often not written down at all.

What a receipt gives you

A record you can check

  • Every action is attested by a quorum before it is committed.
  • Altering one means forging a quorum's worth of signatures, not editing a file.
  • The consumer verifies the proof locally. There is no broker to take on faith.
  • Refusals are recorded on the same terms as approvals.

Even the audit trail can become part of the attack surface.

Anatomy

What a receipt holds.

Identity, authority, context and outcome travel together. Instrument once and every downstream consumer reads the same record.

receipt · agents.authz committed
actoragent:A-17, delegated from j.okafor
actionledger.read
authoritygrant issued by Writ, consumed
contextEpisode_204, attributed
decisiongranted
publishedreceipts.governed, OCSF 6003
attestedquorum reached, committed to WeilChain
independently verifiable ✓ integrity verified

Illustrative receipt

Evidence feed
agents 1,284 receipts/s 412 denied 7
actoractiongrantdecisionpublished to
agent:A-17ledger.readwrit:9f2agrantedreceipts.governed
agent:R-03arm.movewrit:1c84grantedreceipts.governed
agent:A-17ledger.writenonedeniedreceipts.findings
human:j.okaforkyc.lookupwrit:44b1grantedreceipts.governed
agent:C-08repo.commitwrit:7e30grantedreceipts.governed
OCSF 6003 · API Activity → SIEM · SOAR · compliance

Illustrative feed

  • Who acted, all the way back

    Not just the service account that made the call. The identity persists through delegation, however many hops from the person who started the task.

  • Under which grant

    The authority the action ran under is part of the record, so the question of whether it was allowed does not need reconstructing later.

  • With what context

    The context the actor was working from is attributed rather than implied, which is what makes a decision reviewable instead of merely visible.

  • And where it was published

    The destination is part of the entry, so the same record answers what happened and which downstream systems were told about it.

  • Attested before commit

    A quorum signs the record before it is committed. That is the difference between a record that was written and a record that was agreed.

Where it sits

Every product writes to Receipts.

Codensics, TCrypt, Cerebrum and the ROS2 gateway all produce receipts by default. One record, whichever product did the work.

Underneath, the runtime settles who acted, what they were allowed to do, what they knew and what happened. Receipts is the part you can hand to an auditor.

WEILCHAINWEILSTREAMPENSIEVEAUTOSWRITROS2CEREBRUMTCRYPTCODENSICSAGENTSMCP SERVERSAPPSYOUR CODEYour apps run hereAGENTS · MCP SERVERS · APPSProve every actionRECEIPTSProtect sensitive dataTCRYPTGovern AI codingCODENSICSRobots and frameworksROS2 · CEREBRUMWho is actingAUTOSWhat they’re allowed to doWRITWhat they knowPENSIEVEWhat happenedWEILSTREAMWhat is trueWEILCHAINAbove every cloudBYZANTINE FAULT TOLERANT
  1. Keep your existing appsAgents · MCP servers · applications
  2. Evidence and applied productsReceipts · Codensics · TCrypt · ROS2 · Cerebrum
  3. Identity, authority, context, eventsAutos · Writ · Pensieve · WeilStream
  4. Shared, verifiable stateWeilChain
Ingestion

Already in the format your SOC ingests.

Evidence nobody can read is not evidence. Receipts are emitted as OCSF events, so the tooling you already run consumes them without a bridge.

OCSF

A schema your tools know

Events are emitted in OCSF rather than a proprietary shape, so there is no custom parser to write and no bridge to maintain between the record and the systems that read it.

SIEM · SOAR

Direct ingestion

Receipts land in SIEM and SOAR backends directly. Existing correlation searches and playbooks match against them without being rewritten for a new source.

Fleet scale

Thousands of agents at once

Monitoring runs in real time across thousands of agents simultaneously, so a fleet is observable while it works rather than reconstructable afterwards.

What you get

Four things a log cannot give you.

01

Evidence that survives a dispute

When an incident is contested, the record was not written by the party being questioned. A regulator, auditor or counterparty can check it without taking your word for it.

02

One instrumentation, four audiences

Security, compliance, engineering and finance read the same record for different reasons. Identity, authority, provenance and cost travel with the event rather than in four systems.

03

Refusals on the record

What an agent was stopped from doing is as much a part of the account as what it did. Denials are recorded on the same terms as approvals.

04

Continuous instead of retrospective

Evidence accumulates as work happens, so answering a question weeks later is a query rather than a reconstruction project.

Where teams use it

Three places this earns its keep.

Incidents that get disputed

Where the account of what happened has to hold up to someone who has no reason to trust the systems that produced it.

Regulated workloads

Where showing what happened and under whose authority is a recurring obligation rather than a one-off investigation.

Agents acting on their own

Where nobody watched the action happen, so the record is the only account there will ever be of it.

Questions

Evidence, attestation and ingestion, answered.

What security, compliance and platform teams ask before they put this in front of an auditor.

What is an AI agent audit trail?

An AI agent audit trail is a record of what autonomous agents did, under whose authority, and with what context. Receipts produces that record as a quorum-attested entry written before the action is committed, rather than as a log the acting system writes about itself afterwards. Every entry names who acted, under what grant, with what context, and where it was published.

What does a single receipt contain?

A receipt records who acted, under what grant, with what context, and where it was published. The identity persists through delegation, so the actor is traceable back to the person who started the task rather than stopping at a service account. The authority the action ran under is part of the record, and the whole entry is attested by a quorum before it is committed.

How is a receipt different from an application log?

A log is written by the system you are asking about, and anyone with sufficient access can change it without leaving a trace. A receipt is attested by a quorum of independently operated validators before it is committed, so altering one means forging a quorum's worth of signatures rather than editing a file. The consumer verifies the proof locally instead of trusting the infrastructure that produced it.

Can a receipt be altered after the fact?

Not by one party acting alone. Because each receipt is committed under quorum attestation, changing one after the fact requires forging or coercing enough independent validators to reach that threshold again. That is a detectable, public act rather than a silent edit to a file.

What format do receipts come in?

Receipts are emitted in OCSF format for direct ingestion into SIEM and SOAR backends. That means a security team can pull them into the tooling they already run without writing a bridge or a custom parser, and existing correlation searches match on day one.

Does Receipts work across browser AI and coding agents?

Yes. Receipts is the unifying ledger across the surfaces where AI is actually used, including browser-based assistants, coding agents and agents built on frameworks. Codensics extends Receipts into developer environments rather than running alongside it, so a coding agent's activity lands in the same record as everything else.

Are denied actions recorded, or only successful ones?

Denied actions are recorded on the same terms as approvals. What an agent was stopped from doing is part of the account of what happened, and a record that only contains successes cannot answer whether controls were working.

How many agents can Receipts monitor at once?

Receipts powers real-time monitoring across thousands of agents simultaneously. Because evidence accumulates as work happens rather than being reconstructed later, answering a question about a specific action weeks after the fact is a query rather than an investigation.

How does Receipts relate to TCrypt and Codensics?

TCrypt is the preventive half and Receipts is the evidentiary half: TCrypt protects selected sensitive fields before they reach a model, and Receipts records what happened afterwards. Codensics is not a parallel product but a superset layer that extends Receipts into developer workflows. All of them write to the same record.

See it in action

Control the input. Trace the output. Prove the execution.

Who acted. Under which grant. With what context. Attested before commit.