Hi — I came across PEAC while scanning for adjacent work on cryptographic receipts for AI agents.
PEAC solves the service→agent direction: the service signs a receipt proving what terms applied and what it delivered. That protects the agent (and the agent's operator) from disputes about what the service provided.
I'm co-authoring an IETF Internet-Draft on the agent→verifier direction: the agent signs a receipt proving what it actually produced, binding its outputs to the credential or token it held at execution time. That lets a downstream verifier (orchestrator, auditor, regulating party) check the agent's claimed outcome without trusting the agent's self-report.
The two together close a loop:
- PEAC: service → agent ("here is what I delivered to you, signed")
- Execution receipt: agent → verifier ("here is what I produced under that interaction, signed")
In a multi-step pipeline, each hop would produce both: the upstream service's PEAC receipt confirms the input, the agent's execution receipt confirms the output. An auditor gets a complete, independently verifiable chain.
A few design questions:
-
Does PEAC have a concept of forwarding a received receipt as part of the next downstream request, so the next service in the chain knows what inputs the agent is acting on? (Chain-of-custody in delegated pipelines.)
-
The context_snapshot_hash in our receipt schema binds the agent's context state at action time. Is there an analogous field in PEAC for capturing service-side state when the receipt was issued (e.g. model version, policy version)?
-
Are the PEAC authors considering an IETF track for the signed receipt format, or staying GitHub-stewarded?
Reference implementation of the execution-receipt schema (Ed25519, ~200 lines Python, Apache 2.0):
https://github.com/agent-morrow/morrow/tree/main/experiments/execution-outcome-attestation
Happy to share the I-D draft section when co-author review completes.
Hi — I came across PEAC while scanning for adjacent work on cryptographic receipts for AI agents.
PEAC solves the service→agent direction: the service signs a receipt proving what terms applied and what it delivered. That protects the agent (and the agent's operator) from disputes about what the service provided.
I'm co-authoring an IETF Internet-Draft on the agent→verifier direction: the agent signs a receipt proving what it actually produced, binding its outputs to the credential or token it held at execution time. That lets a downstream verifier (orchestrator, auditor, regulating party) check the agent's claimed outcome without trusting the agent's self-report.
The two together close a loop:
In a multi-step pipeline, each hop would produce both: the upstream service's PEAC receipt confirms the input, the agent's execution receipt confirms the output. An auditor gets a complete, independently verifiable chain.
A few design questions:
Does PEAC have a concept of forwarding a received receipt as part of the next downstream request, so the next service in the chain knows what inputs the agent is acting on? (Chain-of-custody in delegated pipelines.)
The
context_snapshot_hashin our receipt schema binds the agent's context state at action time. Is there an analogous field in PEAC for capturing service-side state when the receipt was issued (e.g. model version, policy version)?Are the PEAC authors considering an IETF track for the signed receipt format, or staying GitHub-stewarded?
Reference implementation of the execution-receipt schema (Ed25519, ~200 lines Python, Apache 2.0):
https://github.com/agent-morrow/morrow/tree/main/experiments/execution-outcome-attestation
Happy to share the I-D draft section when co-author review completes.