Catalog PyPI
PACKAGE EXPLORERView in registry

aer1-langchain

PyPI

One-line verifiable execution receipts for LangChain agents. Free, no API key, offline verification, chain-head anchoring to Nostr and Bitcoin.

aer-1ai-agentsauditaudit-traillangchainmcptracingverifiable-receiptszambo
Versions collected1
Direct dependencies0From release 0.1.0
Last observed20 Oct, 20:26 UTC

README

Version 0.1.0 documentation

aer1-langchain

One-line install, no API key, free forever: attach this collector as a callback handler and every LangChain run emits a hash-chained, offline-verifiable verifiable workflow receipt (AER-1, an IETF Internet-Draft, Section 8). What the agent did, in what order, with per-step hashes and a Merkle root over the whole run. No network calls, no behavior changes, the collector only observes. Receipt chain heads can anchor to Nostr and Bitcoin, so anyone can later confirm the record was not changed, without trusting any server.

The AER-1 framework collector family

The LangChain collector in the AER-1 framework collector family. Any agent running on these frameworks can emit verifiable AER-1 execution receipts: every step recorded, hash-chained, one Merkle root over the whole run.

See the AER-1 implementation registry for every implementation.

Install

pip install aer1-langchain

Use it (copy, paste, run, no API keys needed)

# pip install aer1-langchain langchain-core
from uuid import uuid4
from aer1_langchain import AER1ReceiptCollector

collector = AER1ReceiptCollector(goal="check the Paris weather")

# Simulate what a real chain/agent emits through callbacks.
# In production you pass the collector as a callback:
# chain.invoke({"input": "..."}, config={"callbacks": [collector]})
run = uuid4()
collector.on_llm_start({}, ["What is the weather in Paris?"], run_id=run)
collector.on_llm_end("I will call get_weather.", run_id=run)

run2 = uuid4()
collector.on_tool_start({"name": "get_weather"}, "Paris", run_id=run2)
collector.on_tool_end("Sunny, 22C in Paris", run_id=run2)

receipt = collector.finalize(final_answer="Sunny, 22C in Paris")
assert collector.verify(receipt) == []  # VALID
collector.save("receipt.json", workflow=receipt)

That is the whole integration: attach the collector as a callback, run, finalize. The receipt is a plain JSON object you can store, ship to an auditor, or render in a UI.

What the receipt contains

Workflow level (AER-1 Section 8, Table 2):

  • type, version, workflow_id, receipt_id, session_id
  • goal, status
  • steps: one record per event, seq 1..n in order
  • merkle_root: Section 8.1 root over the ordered step receipt ids
  • output_hash: SHA-256 of the final answer
  • verify_url: where the verification procedure is documented

Step level (AER-1 Section 8, Table 3):

  • seq, receipt_id, tool, receipt_hash, started_at, ended_at, status

Each step tool names the callback source (for example llm, tool:get_weather, chain:MyChain, agent:finish, retriever). arguments is the start payload and observations is the end payload; each step receipt_hash is SHA-256 over the canonical JSON of those three, so the hash commits to what actually happened. The receipt stays compact while the hash commits to the content.

Verification

collector.verify(receipt) runs the full offline check and returns a list of failure reasons, empty when valid:

  • all Table 2 / Table 3 members present and well-formed
  • seq values exactly 1..n in order, no gaps
  • no two steps share a receipt_id (MM-1)
  • merkle_root matches the recomputed Section 8.1 root
  • strict RFC 3339 timestamps, lowercase UUIDs, 64-char hex digests

Tamper with any field and verification fails. Try it:

receipt["steps"][0]["tool"] = ""
assert collector.verify(receipt) != []  # fails, as it should

Separate verification verdicts

For honest reporting, use verify_receipt_verdicts() instead of a single boolean. Each dimension gets its own verdict; they are never conflated:

from aer1_langchain import verify_receipt_verdicts, verdicts_summary

verdicts = verify_receipt_verdicts(receipt)
print(verdicts_summary(verdicts))
# byte_integrity=pass schema_validity=pass issuer_authenticity=not_checked
# evidence_linkage=not_checked anchor_verification=not_checked
# chain_integrity=pass
DimensionWhat it checksCollector behavior
byte_integrityMerkle root matches the recomputed rootpass / fail
schema_validityAll required fields present and well-formedpass / fail
issuer_authenticityCryptographic proof of who issued the receiptAlways not_checked; the collector does not verify signatures
evidence_linkageUpstream evidence bytes match their digestsAlways not_checked; the collector does not capture upstream evidence
anchor_verificationAnchor proof is valid and binds the rootpass / fail / not_checked (no proof provided)
chain_integrityseq values are 1..n in order, no duplicate receipt idspass / fail

Verdict values are pass, fail, not_checked, and unavailable. not_checked is neither a successful check nor evidence of failure.

What the commitment covers (and what it does not)

The merkle_root commits to the ordered list of step receipt_id values. Each step receipt_hash commits to that step's tool name, arguments, and observations. The output_hash commits to the final answer bytes.

What this does not cover:

  • The commitment does not prove the bytes are unchanged since issuance. An attacker able to replace both bytes and digest creates another matching pair. Continuity requires comparing against a digest from an independently trusted path (a retained receipt, a verified signature with a trusted key, or a separately verified anchor).
  • A matching hash does not prove the action ran, the data is true, or any external outcome occurred. It proves the supplied bytes agree with the supplied digest.
  • The receipt records the collector's observations. It does not prove provider truth, correct reasoning, authorization, or business success.
  • Without an anchor, truncation (deleting steps from the end and recomputing the root) is not detectable.

Construction versions

This package uses these exact constructions (see CONSTRUCTION_VERSIONS in the verdicts module):

  • Merkle tree: section-8.1-binary-merkle-v1
  • Step digest: sha256-canonical-json-v1
  • Output commitment: sha256-utf8-v1
  • Anchor proof: aer1-anchor-proof-v1

Notes

  • Pass the collector in config={"callbacks": [collector]} on invoke/batch/stream, or attach it to individual components (LLM, tool, retriever, chain, agent executor).
  • Error callbacks (on_*_error) record the step with status: "error", which marks the whole receipt error.
  • Agent actions record immediately as agent:<tool> steps; on_agent_finish closes the run with an agent:finish step.
  • session_id defaults to a fresh UUID per collector; pass your own to correlate receipts across runs.
  • verify_url defaults to the AER-1 specification page; point it at your own verifier in production.

Spec

AER-1: Agent Execution Receipts is an IETF Internet-Draft, draft-zambo-aer1, https://datatracker.ietf.org/doc/draft-zambo-aer1/

See it live

Your receipt is offline-verifiable, but you can also check it on the live verifier:

  1. Copy the receipt JSON your code produced
  2. Paste it at https://zambo.dev/verify
  3. See the verification result with the Merkle root and step hashes

Or mint a live receipt directly: run any call at https://zambo.dev/demo and get a shareable receipt URL like https://zambo.dev/run/.

License

Apache-2.0

Downloads & popularity

Awaiting observations

No metric observations yet

Download counts and popularity will appear here as the collector receives them.

Versions 1

Collected releases
VersionPublishedDirect dependenciesOpen version
0.1.07 Oct 20260

Package advisories

0
No matching advisories collected

This describes our collected data; it is not a security assessment.

Metadata history

Meaningful changes
Current collected state Current

Observed since 20 Oct, 20:26 UTC

No superseded metadata states collected. Unchanged observations do not create new revisions.

Record identity

package:091433ce52c0a41dedee854ffad4442d5d9946fd2debc0ed031bc62e346d8611