agentic-receipts
Cryptographically signed, tamper-evident execution receipts for AI agents, tool calls, GPU workloads, and distributed jobs.
agentic-receipts creates verifiable records of agent and workload execution.
Each receipt contains hashes of the input and output, execution metadata, an
Ed25519 public key, and a digital signature.
Features
- Ed25519 receipt signing and verification
- SHA-256 input and output hashing
- Tamper detection
- Wrong-public-key rejection
- JSON-serializable receipts
- Unique receipt IDs and nonces
- Optional receipt chaining
- Execution timing and latency metadata
- Support for agent, tool-call, and distributed workload records
Why execution receipts?
AI agents and distributed workloads often execute actions across services, tools, models, and infrastructure providers.
Traditional logs record what a system claims happened, but they may be edited afterward. A signed execution receipt provides cryptographic evidence that the record has not been modified since it was signed.
Possible use cases include:
- AI-agent tool-call auditing
- Multi-agent workflow verification
- GPU workload records
- Distributed task execution
- Usage and billing evidence
- Security and compliance audit trails
- Verifiable automation pipelines
Receipt structure
A signed receipt can contain:
The values above are an example. Receipt IDs, nonces, keys, timestamps, hashes, and signatures are generated at runtime.
Installation
Until the crate is published to crates.io:
[]
= { = "https://github.com/0rlych1kk4/agentic-receipts" }
Example
Run the included example:
Expected output:
The complete example is available in
examples/create_and_verify.rs.
Verification guarantees
Successful verification confirms that:
- the receipt was signed by the private key corresponding to the included or
- trusted Ed25519 public key;
- the signed receipt content has not been modified;
- the input and output hashes remain part of the signed record;
- verification fails when receipt fields are changed;
- verification fails when an unrelated public key is supplied.
Important limitation
A valid receipt proves the authenticity and integrity of the signed statement. It does not independently prove that an external action, physical event, model execution, or GPU computation actually occurred exactly as described. The signer and the process generating the receipt must still be trusted to observe and record the execution correctly.
Receipt chaining
The optional previous_receipt_hash field can connect one receipt to an earlier receipt.
This can be used to create a tamper-evident sequence of:
- agent actions;
- workflow stages;
- distributed jobs;
- tool calls;
- compute tasks.
Changing or removing an earlier receipt can then break the expected chain.
Testing
Run the full test suite:
The integration tests currently cover:
- successful receipt signing and verification;
- rejection of a tampered receipt;
- rejection when verifying with the wrong public key.
For additional checks:
Security considerations
Applications using this crate remain responsible for:
- protecting signing keys;
- establishing trust in public keys;
- securely distributing and rotating keys;
- preventing receipt replay where required;
- checking timestamps and receipt freshness;
- enforcing unique receipt IDs and nonces;
- defining authorization and retention policies;
- validating the truthfulness of the recorded execution metadata.
Private signing keys should never be serialized into receipts, logs, source code, or public repositories.
See SECURITY.md for vulnerability reporting instructions.
Project status
agentic-receipts is currently an early-stage project.
Review the API, serialization format, key-management model, and threat model before using it for production-critical, financial, or compliance-sensitive workloads.
Roadmap
Potential future improvements include:
- stable canonical receipt serialization
- key identifiers and key rotation
- receipt expiration
- replay-protection helpers
- receipt-chain verification
- batch verification
- Merkle-tree receipt aggregation
- optional JSON and CBOR formats
- external key-management integrations
- agent-framework integration examples
- GPU attestation and verifiable-compute integrations
Contributing
Contributions are welcome.
Please keep pull requests focused and include tests for security-sensitive behavior.
Before submitting a pull request:
License
Licensed under either of:
- Apache License, Version 2.0
- MIT License