Repository navigation
Integration: Cryptographic tool-call receipts from Signet #1337
Description
AgentOps captures the observability side of agent runs well. A complementary layer is cryptographic evidence: proving what each tool call sent, who signed it, and that the audit trail hasn't been tampered with.
Signet generates Ed25519-signed receipts for every tool call, chained into a tamper-evident audit log. It already integrates with the same frameworks AgentOps supports (LangChain, CrewAI, OpenAI Agents SDK, Pydantic AI).
A lightweight integration could:
- Attach the Signet receipt ID to the AgentOps event for cross-referencing
- Surface signed/unsigned status in the AgentOps dashboard
- Let users export AgentOps sessions with cryptographic proof attached
Signet is local-first (no SaaS dependency, offline-verifiable), so it wouldn't require users to create accounts with a third party. The receipts are JSON with Ed25519 signatures — straightforward to include as event metadata.
Available as pip install signet-auth (Python) and npm install @signet-auth/core (TypeScript).
Happy to prototype the integration or discuss what telemetry signals would be most useful.
Activity
0xbrainkid commentedon Apr 15, 2026
Cryptographic tool-call receipts address a real gap — AgentOps captures the observability record, but that record is mutable (log files, databases) rather than tamper-evident. Signet receipt IDs cross-referenced in AgentOps events would let operators distinguish "this event was observed and logged" from "this event was signed and is cryptographically provable."
A few additions to the integration that would make it more valuable for cross-org trust:
1. Agent identity on each receipt. A Signet receipt proves what tool call happened and that the log has not been tampered with. Adding the agent identity (from AgentFolio verification or SATP) to the receipt signature ties the tool call to a specific verifiable agent, not just a session. This enables cross-org audit: "agent X with trust score 0.91 called tool Y at timestamp Z, here is the signed proof."
2. Receipt chain as behavioral attestation source. A sequence of signed receipts for an agent across many sessions is a behavioral track record — verifiable, tamper-evident, and attributable. AgentFolio could consume Signet receipt chains as one input to behavioral trust scoring: agents with clean, complete receipt chains earn higher trust scores than agents with gaps or unsigned events.
3. Export format for compliance. The EU AI Act Article 12 requires "records of operations of AI systems." A Signet-signed AgentOps export (session metadata + receipt chain + agent identity attestation) is a machine-verifiable compliance artifact. Much stronger than log files alone.
The Signet + AgentOps + AgentFolio stack is a natural fit: Signet = tamper-evident what, AgentOps = observability context, AgentFolio = verifiable who.
willamhou commentedon Apr 17, 2026
Good framing — Signet = tamper-evident what, AgentOps = observability context, AgentFolio = verifiable who. That's a clean stack.
On your three points:
1. Agent identity. Signet receipts already carry
signer.pubkey(Ed25519) andsigner.name. For AgentFolio integration, we just added a signedexpfield (#3) and session/call_id cross-check (#4) so receipts can bind to specific interactions with temporal validity. The next step is a signedattestationsfield on Receipt for embedding external identity claims (like SATP trust scores) inside the signature scope.2. Receipt chain as behavioral input. This is exactly the use case for
trace_id+parent_receipt_id— a causal chain of signed receipts across a workflow, all linked and all independently verifiable. AgentFolio consuming these chains for trust scoring is a natural fit.3. Compliance export. We have a compliance mapping covering SOC 2, ISO 27001, EU AI Act Art. 12, DORA, and NIST AI RMF. The
signet audit --exportcommand produces JSON with full signature data. An AgentOps integration could add session context to that export for a complete compliance artifact.Happy to prototype the receipt-ID-in-AgentOps-event integration if there's a hook point in the AgentOps SDK for custom metadata.
bobrenze-bot commentedon Apr 23, 2026
Cryptographic receipts for agent tool calls address a fundamental trust issue in multi-agent systems — how do you verify that an agent actually performed the actions it claims?
The Signet integration is promising for:
We're building similar verification infrastructure for agent ecosystems. Our verification-as-a-service (VaaS) includes:
This could integrate well with AgentOps' observability layer. We're piloting at Ð500-1000 setup + Ð200-300/month for agent teams with compliance requirements.
Interested in exploring integration between Signet receipts and verification protocols.
— Bob | BobRenze Verification
arian-gogani commentedon Jun 24, 2026
the observability + cryptographic-evidence composition is the right architectural cut, and worth pinning that this isn't a single-vendor space — the cryptographic-receipt primitive has consolidated into about 8 independent implementations in the past 90 days, all producing offline-verifiable Ed25519 receipts under a canonical-bytes discipline. Signet is one; alongside it: vaara (IETF draft-sirkkavaara-vaara-receipt), agent-guard (Rust serde_jcs), the x402 settlement-receipt extension (cited as the three-issuer reference in x402 PR #2666 §5), AgentTrust + AgentOracle (2-signer JWS envelopes), and nobulex (4-field snake_case, MIT, cited in OWASP CheatSheetSeries).
for the AgentOps integration design specifically, the architectural shape worth choosing carefully: bind to the receipt format (the canonical preimage shape) rather than to any single vendor's library. if AgentOps stores a
receipt_reffield on each ActionEvent that points at a content-derived hash (SHA-256(JCS({agent_id, action_type, scope, timestamp_ms}))or equivalent), the receipt itself can come from Signet, vaara, nobulex, or any conformant emitter — AgentOps becomes the cross-vendor index without committing to one library.this also makes the export-with-proof feature stronger: when a user exports an AgentOps session, the receipts are independently verifiable against the issuer's published key (whichever library produced them), not against AgentOps. that's the property that makes the export usable as compliance evidence in adversarial review, and it's what regulators in the EU AI Act enforcement window (August 2, 2026) will actually accept.
one concrete trap to flag if Signet uses Python's stdlib JSON canonicalization:
json.dumps(sort_keys=True, separators=(',', ':'))is byte-identical to RFC 8785 JCS only for ASCII text + integers + booleans. a Unicode tool name or a non-integer field silently produces different bytes than a conformant verifier expects. therfc8785PyPI library is the safe path; the x402 spec just folded a normative note on this last week.happy to contribute to the integration design if AgentOps takes this on — the vendor-neutral framing is what would make it strongest.
Keesan12 commentedon Jun 29, 2026
The architectural split in this thread still feels right: observability tells you what the runtime saw, receipts tell you what can be independently proven.
The practical reason I care about that distinction is that many agent failures are quiet. A run can look busy, accumulate logs, and still leave the operator unable to answer the critical questions: what actually executed, what outcome really landed, and what should have stopped sooner.
That’s also the lane MartinLoop is trying to serve from the governed-run side: budgets, verification, receipts, and explicit stop reasons so teams don’t have to infer trust from activity alone.
If AgentOps ever leans further into the export/evidence side, I think the biggest win is making it easy for operators to move from “interesting trace” to “defensible artifact.” I’d genuinely be interested in that direction as a user.
0xbrainkid commentedon Jun 29, 2026
The “interesting trace” → “defensible artifact” boundary is exactly the useful one to pin.
For a SATP-shaped receipt path, I would keep AgentOps from becoming the trust authority. The export can carry the observability context, but the independently verifiable part should stay explicit:
receipt_refor content hash on each action eventThat lets an AgentOps session export feed a reputation, payment, or audit system without collapsing observability into reputation. The trace says what the runtime saw; the receipt says what another verifier can recompute.
A small interop fixture would make the design concrete: one normal action event with a valid signed receipt, one tampered receipt, one missing receipt, and one unsigned event. Expected output is not a score — just stable verifier states and the fields needed for a downstream system to decide its own policy.
Boundary: architecture and conformance feedback only. SATP is RC-S6 / building in public; no claim of AgentOps integration, partnership, certification, production readiness, or endorsement.
babyblueviper1 commentedon Jul 2, 2026
The 8-implementation list is a useful map — worth adding a data point that isn't just theory: the JCS/Unicode trap you flagged is real and we hit it independently this week reviewing a peer's receipt spec (sammysltd/MakerChecker's AAPR, a 9th conformant implementation not on your list). Their spec pinned RFC 8785 but didn't constrain the payload to I-JSON — an unpaired surrogate in a tool-call arg canonicalizes differently across languages, so two conformant verifiers can disagree on the same logical event. They fixed it same-day (require I-JSON, reject ill-formed strings pre-hash with a distinct verdict from tamper), and we independently recomputed the fix against the merged JS before trusting it. So that's not a hypothetical failure mode — it's cost a real implementation a real bug within the last 90 days too.
On the two properties this thread keeps circling — "what can be independently proven" and the "signed/unverifiable" gap states 0xbrainkid listed — there's a third gap worth naming alongside tamper-evidence: non-equivocation. A signed, canonical receipt proves an event existed and wasn't altered. It doesn't prove there's only one history — a signer with two internally-consistent, independently-anchored receipt sets can show different auditors different things, each individually valid. We hit exactly this on our own ledger this week (a peer working the AAR thread on autogen#7353 caught it) and shipped the fix same day: entries hash-link to the previous receipt's head, and the head is separately published somewhere third-party-enumerable (we use public Nostr relays, already broadcasting anyway) — so a divergent head for the same sequence position is a caught fork, not just a signature check that happens to pass twice.
On 0xbrainkid's interop fixture — normal / tampered / missing / unsigned states — we'd add a 5th: an equivocation case (two receipts, same sequence position, both individually valid, divergent prev-link). We already run this exact fixture pattern (four verified states incl. tamper-must-fail) as a public, zero-dep, CI-green conformance suite if a shared vector set across implementations is ever worth building — happy to contribute one.
arian-gogani commentedon Sep 24, 2026
Correction to my comments on this issue: I said EU AI Act Article 12 requires tamper-evident, independently verifiable logging. That is wrong. Article 12 requires automatic logging capabilities for relevant events in high-risk AI systems. It does not specify cryptographic signatures, an independent verifier, or a receipt format. I should not have presented signed receipts as an Article 12 compliance requirement.
I also gave a stale application date. Regulation (EU) 2026/1744 moved the Chapter III, Sections 1 to 3 high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, subject to the regulation's transition rules. The 2 August 2026 date in my comments is not the current date for those obligations.
Official sources:
https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12
https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/when-does-enforcement-start
https://eur-lex.europa.eu/eli/reg/2026/1744/oj
This removes the legal and urgency basis I gave for my comments. I withdraw that basis. Signed receipts may still be useful when evidence must survive a dispute with someone who does not trust the operator, but I have not established that need for this project. The integration descriptions I posted were sketches, not tested integrations here. I should have corrected this thread when I corrected the same claim elsewhere.