Today we are publicly launching Sequesign, a protocol for cryptographically verifiable receipts of delegated AI work. The reference implementation, the trust model, and a live demo are available now.

Agents are starting to do real work on behalf of people and organizations. They review invoices, approve refunds, complete marketplace tasks, draft contracts, and make decisions someone else has to live with. When an agent reports what it did, there is currently no portable way to verify that report against the underlying work. The agent wrote the logs. The agent wrote the summary. The agent claimed it followed the steps it was supposed to follow. A Sequesign receipt is the independent record that lets a reviewer cross-check that report against what actually happened.

The site at sequesign.com has a working demo with two agent workflows and five verification scenarios. You can run a valid receipt and watch it pass. You can run a tampered receipt and watch the verifier reject it. You can run a scenario where the agent made a claim it cannot back up, and watch the verifier flag the warning without failing the receipt. That last case is the one we care about most. It shows what a receipt is for, and what it is not.

The technology is patent pending. The reference implementation is public preview, not production. Next on the roadmap are a hosted witness service, a developer SDK, and a delegation manifest primitive that binds the rules to a witnessed commitment at task delegation time, so the rules cannot be authored after the fact to fit the outcome.

If you build agents, evaluate them, regulate them, or have to defend their decisions to someone else, the protocol is designed for you. Try the demo. Read the trust model. Tell us where it falls short.

Try the live demo . Read the trust model . Reach out

When something goes wrong with an AI agent, the first thing someone asks for is the logs. The agent's chat transcript. The tool call history. The trace. The thing the agent wrote about what the agent did. This is almost always the wrong answer, and the reason matters.

Logs are written by the system being investigated. That single fact disqualifies them as evidence in any serious dispute. If the agent did something wrong, the agent also wrote the record of what it did. If the agent was confused, the agent also wrote the explanation. If the agent lied, the agent also wrote the lie. Logs can document anything an agent wants to claim, and they prove nothing other than what the agent decided to write down.

A receipt is different. A receipt is signed at the moment of action, by the party doing the action, with a key the party cannot rewrite. It is countersigned by an independent witness who did not see the underlying content. It is chained to the previous action so the sequence cannot be quietly reordered. When approvals are required, the approver signs separately with their own key. The receipt is portable: a third party can verify it offline, without trusting the system that produced it, weeks or months after the work happened.

The distinction is not academic. Right now, when an agent does something a reviewer is unhappy about, the reviewer's only recourse is to trust or distrust the agent's logs. There is no third option. If the agent is wrong, the logs reflect a wrong agent. If the agent is lying, the logs reflect a lying agent. The reviewer cannot tell which from the logs alone, because the logs are exactly what the agent decided to produce.

This is fine when nothing is at stake. It stops being fine the moment the agent is approving payments, evaluating claims, executing trades, submitting work for pay, or making decisions a regulator might later ask about. The cost of "trust the logs" goes from low to enormous as soon as someone outside the system needs to verify what happened.

Several adjacent technologies look like they might solve this and do not. Distributed tracing makes logs more structured but does not change who wrote them. Audit logging adds tamper-resistance to log storage but does not change who authored the original entry. Observability platforms aggregate logs from thousands of services but treat them all as authoritative. Even blockchain anchoring, which is occasionally proposed for this problem, only proves that a log existed at a certain time. It does not prove the log accurately describes what happened, because the system writing the log is the same system being investigated.

The receipt pattern is older than any of these. It is how invoices work. It is how shipping manifests work. It is how notarized documents work. The signer commits to a specific claim, in a specific moment, with a specific instrument, and the receipt is the artifact that travels. The reviewer never has to trust the signer to verify the signature.

Bringing receipts to agent work is mostly a matter of building the pieces. The protocol has to define what each action commits to. The chain has to extend deterministically. The witness has to be independent. The signatures have to verify offline. The receipt has to be portable enough that a reviewer who has never heard of the agent platform can still verify it. None of this is novel cryptography. It is plumbing applied to a problem that did not have plumbing yet.

Sequesign exists because the plumbing was missing. Agents are starting to do real work, and they are doing it in environments where someone will eventually ask the agent to prove what it did. Logs are not a defensible answer. Receipts are.

Sequesign is not a truth oracle, and the receipt does not magically detect every lie an agent might tell. A receipt can prove that the agent committed to a specific record, at a specific time, in a specific sequence, with the right signatures. It cannot prove the agent's natural-language summary matches the actual evidence. The protocol's job is to surface the gap: the verifier marks claims that lack external attestation as unsupported, so a reviewer knows what to trust and what to push back on. That is a much smaller claim than "we detected the lie," and it is the claim the protocol can actually defend.

The next time someone asks for the logs, ask for the receipt instead.

A common reaction to Sequesign goes something like this: "Sounds great, but how do I know the agent is telling the truth?" That is the right question. It is also a question the receipt does not answer, and being clear about why is the whole product.

A Sequesign receipt is a portable, cryptographically signed record of an agent's work. It contains the actions the agent performed, the evidence associated with each action, the signatures of every party involved, and the chain that connects them in order. The receipt is generated as the work happens, signed at each step, countersigned by an independent witness, and produced as a single verifiable artifact at the end.

What that receipt proves, and what it does not, splits along a sharp line. This post walks through both sides of the line in concrete detail.

What a valid receipt proves

The evidence has not been changed. Every piece of evidence associated with an action is canonicalized and hashed at the time the action is recorded. The hash is committed to the chain. Anyone verifying the receipt later can recompute the hash from the evidence and confirm it matches what the chain committed to. If a single byte of evidence changes after the fact, the hash changes, the commitment no longer matches, and the verifier rejects the receipt with a specific failure reason.

The action sequence is intact. Each action commits to the previous chain state. The chain state is a deterministic function of every action that came before it. Removing an action, reordering actions, or inserting a new action in the middle all break the chain in a detectable way. The verifier walks the chain from the beginning and confirms each step extends the previous one correctly.

The agent signed the work. Every action record carries the agent's signature. The signature is over a canonical message that includes the action's evidence hash, the previous chain state, and the new chain state. The verifier confirms that the signature verifies under the agent's public key. If the signature was forged, or if the message it was supposed to sign has been altered, verification fails.

The witness signed the chain. An independent witness service countersigns each chain extension. The witness does not see the underlying evidence; it sees only the hashed commitment. This means a customer can run a witness without exposing the agent's data, and the witness can attest to "this commitment was presented at this time" without taking on the liability of reviewing content. The verifier confirms the witness signature verifies under the witness's published public key.

Schemas validate. When the receipt is bound to schemas, the verifier confirms that each piece of evidence conforms to the declared shape. If the evidence has a field that is supposed to be an integer and someone put a string there, the receipt fails schema validation. If a required field is missing, the receipt fails. The schema is hashed and the hash is committed to the action, so changing the schema after the fact does not retroactively change what receipts were validated against.

Workflow profiles validate. When the receipt is bound to a workflow profile, the verifier confirms that the sequence of actions satisfies the declared rules. For an invoice approval workflow, the profile might require that policy is checked before human approval is requested, and that human approval is present before a payment instruction is created. If the agent skipped a step or got the order wrong, the receipt fails profile validation, even though every individual action might be cryptographically valid.

Human approvals are valid. When an action requires human approval, the receipt includes an attestation signed by the approver using the approver's own key. The verifier confirms the signature is valid under the approver's public key. This is not the agent claiming an approval happened; it is the approver themselves committing to it.

What a valid receipt does not prove

Here is where most other systems would stop and pretend they have solved the problem. We do not, because they have not.

The receipt does not prove the agent told the truth. If the agent's evidence for an action is a piece of natural-language text claiming "I verified the vendor's bank details," the receipt commits to that text being what the agent said. It does not commit to the vendor's bank details actually being verified, because no independent party signed off on that claim. The verifier will report the chain as cryptographically valid and the workflow as complete. It will not, by itself, tell you whether the agent was honest about what it did.

The receipt does not prove an invoice came from a real vendor. The agent may have processed an invoice, but unless the vendor or a vendor verification service separately signed the invoice details, the receipt only proves that the agent saw and acted on an invoice with those details. Whether those details came from a real vendor is a question for the upstream evidence pipeline, not the receipt.

The receipt does not prove the payment provider confirmed the instruction. Unless the payment provider issues a counterparty attestation that becomes part of the chain, the receipt only proves the agent generated a payment instruction. Whether the instruction actually executed is a separate fact, attested by a separate party, that the receipt can include but does not generate.

The receipt does not prove the LLM provider attested to its response. When an agent uses an LLM to review evidence or generate a decision, the receipt commits to what the LLM returned. It does not commit to that being what the LLM actually generated, unless the LLM provider separately signs the response. Today, no major LLM provider does this. The protocol is built to handle provider attestations when they become available; until they do, LLM outputs are agent-asserted.

The receipt does not prove unsupported claims are externally attested. The protocol can mark some of the agent's claims as unsupported, either because the agent self-reports them as such or because the evidence comes from sources the verifier does not recognize. These claims are surfaced as warnings: the receipt still verifies cryptographically, but the verifier tells the reviewer that this particular claim has no external backing. The reviewer can then decide whether the claim matters enough to require additional verification.

Why this distinction matters

Most systems that try to address agent trust make claims they cannot keep. They promise to detect lies, catch hallucinations, or verify outputs end-to-end. These promises sound good in marketing copy and fail in practice because no system can verify a claim that was never independently attested in the first place. When the system fails, the failure looks like the protocol's fault, even though the underlying gap was always between the agent and the world.

Sequesign takes a different approach. The protocol does what it can prove and surfaces what it cannot. A receipt with no external attestations on any content-level claim is still useful: it proves the agent committed to a specific record, at a specific time, in a specific order, with the right signatures. That alone is enough to defeat the "the agent wrote the logs after the fact" attack, the "the agent skipped a required approval" attack, and the "the evidence was changed after the work was done" attack. Those are real attacks and the receipt does prevent them.

For everything beyond that, the receipt makes the trust requirements visible. If the LLM response is unattested, the receipt says so. If the vendor identity is unverified, the receipt says so. If a claim is agent-asserted with no external backing, the receipt says so. The reviewer no longer has to guess which parts of the agent's report are defensible and which are taken on faith. They can see the line.

The honest version of the pitch

A Sequesign receipt does not make an unreliable agent reliable. It does not make a dishonest agent honest. It does not magically verify external facts. It does something more limited and more useful: it produces an artifact that separates what is cryptographically provable from what is only agent-asserted, and it does so in a way that travels with the work and can be verified offline by anyone who has the receipt.

That separation is the product. Everything else is either downstream evidence pipelines (whose receipts can be referenced) or out of scope.

Try the live demo . Read the trust model

A Sequesign receipt is designed to be verified offline by anyone who has it. This post walks through what verification actually does, what the receipt package looks like, and what a minimal verifier needs to check.

What a receipt package contains

A Sequesign receipt is a directory or zip file with a small, fixed structure:

receipt.sequesign/
  receipt.json              receipt envelope with metadata
  actions.jsonl             one action record per line
  evidence/                 hashed evidence content
    act_001_task_created.json
    act_002_policy_checked.json
    ...
  attestations.json         agent, witness, human, counterparty signatures
  keys/                     public keys for verification
    agent.pub.pem
    witness.pub.pem
  verification-report.json  output of the last verifier run (optional)

The receipt envelope at the top is a single JSON object that names the chain, declares the receipt mode (freeform, schema-validated, or profile-constrained), references the schemas and profile if applicable, and lists the final chain state. Everything else in the package is content that the envelope references by hash.

What the verifier checks

Verification is deterministic. Given the same receipt and the same public keys, every verifier in the world produces the same report. There is no fuzziness, no model inference, no scoring. The verifier returns a structured report with flags for each property it checked.

The checks, in order:

1. Chain integrity. The verifier walks the chain from the initial state forward. For each action, it computes the action record hash from the canonical action record, computes the next chain state from the previous state and the action record hash using the chain extension function, and confirms the new state matches what is recorded. Any mismatch fails the receipt with reason chain_state_mismatch.

2. Evidence hashes. For each action, the verifier canonicalizes the corresponding evidence file, hashes it, and confirms the hash matches what the action committed to. Any mismatch fails with reason evidence_hash_mismatch.

3. Agent signatures. Each action carries an agent signature over a canonical message that includes the action record hash, the previous chain state, and the new chain state. The verifier confirms the signature verifies under the agent's declared public key. Failure here means the agent did not actually sign this action, or the message has been altered.

4. Witness signatures. Each chain extension carries a witness attestation. The verifier confirms the witness signature verifies under the witness's published public key. The witness key is discovered via a well-known endpoint, or for offline verification, it is included in the receipt's keys directory.

5. Schema validation, if requested. If the receipt mode is schema-validated or profile-constrained, the verifier loads each declared schema, confirms its hash matches what the receipt committed to, and validates each evidence object against its schema. Failure here means the evidence does not match the shape it claimed to follow.

6. Workflow profile, if requested. If the receipt is profile-constrained, the verifier loads the declared profile and confirms the action sequence satisfies the profile's rules. This catches missing required actions, prohibited transitions, and other workflow-level errors.

7. Human approval attestations. If the workflow includes human approvals, the verifier confirms each approval attestation verifies under the approver's public key, and that the approver's identity matches what the workflow required.

8. Counterparty attestations. If any actions include counterparty attestations, the verifier confirms those signatures and resolves the counterparty public key via the declared discovery method.

9. Unsupported-claim warnings. The verifier inspects evidence for claims marked as unsupported and surfaces them as warnings on the report. These warnings do not fail the receipt; they make the trust gap visible.

What the report looks like

The verifier's output is structured for both human and machine reading:

{
  "valid": true,
  "receipt_id": "rcpt_8f3a4c2e91d7b6a8",
  "chain_id": "chn_7f3a4c2e91d7b6a8",
  "verification_level": "L4_HUMAN_APPROVED",
  "mode": "profile_constrained",
  "profile": "sequesign.invoice_payment.v0.1",
  "flags": {
    "hash_integrity": true,
    "sequence_integrity": true,
    "schema_validation": true,
    "workflow_profile": true,
    "agent_identity_bound": true,
    "witness_verified": true,
    "policy_bound": true,
    "human_approval_verified": true,
    "counterparty_confirmed": null
  },
  "warnings": [],
  "reason": null
}

The flags are the truth. The verification_level is a summary label derived from the flags. null in a flag means "not requested," not "failed."

When verification fails, the report includes a specific reason and pinpoints the affected action:

{
  "valid": false,
  "reason": "evidence_hash_mismatch",
  "action": {
    "sequence": 3,
    "action_type": "llm_invoice_reviewed"
  },
  "expected_evidence_hash": "a3f7b8c2e91d4f6a2c8e1f3b9d6c5e7f",
  "computed_evidence_hash": "b2e8f4a7c93d5a1e3b7c9f2d8a4e6c1b"
}

Running the verifier yourself

The reference implementation includes a verifier you can run locally on any receipt. The verifier is offline by design; it reads the receipt package and the public keys it needs, and it produces a report without contacting any external service. This is intentional. A receipt is supposed to be verifiable by anyone who has it, including someone with no relationship to Sequesign and no internet connection.

The web demo at sequesign.com runs this same verifier server-side and renders the report in the browser. There is no model inference, no heuristic, no magic. What you see in the demo is exactly what a local verifier produces from the same inputs.

The SDK, which is in progress, will expose the verifier as a one-line import so any system can verify receipts as part of its own workflow. Until then, the reference implementation is the canonical source.

Try the live demo . See how it works