Anchor /claim verdicts to a signed AgentAvow safety attestation?

[kenneives]

@azender1 — the exactly-once guard keying on action_ref is clean, and it already ingests evidai's gated-preflight fixtures, which makes SafeAgent the closest thing in the cohort to a live consumer of external evidence. One addition that builds on that:

On each /claim, also verify an AgentGraph safety attestation for the endpoint being paid (a signed verdict, byte-matched to the v0.4 pre-execution-verdict envelope you've already wired against) — SKIP/deny on critical/high, PROCEED otherwise, with the attestation as the /settle audit anchor.

It composes with what you have — same action_ref, same JCS + SHA-256 — so it's a small verify step, not a rebuild. Happy to open the PR + a fixture if you're up for it. It'd turn the verifier → gateway → guard seam into one that actually enforces a safety verdict, not just demonstrates the wiring.

[azender1]

@kenneives — yes, let's do it.
The composability point is exactly right — same action_ref, same JCS + SHA-256, the verify step slots in cleanly before the COMMITTED write. Turning the verifier → gateway → guard seam into one that actually enforces a safety verdict rather than just demonstrating the wiring is the right direction.
One scoping question before you open the PR: what's the intended behavior when the attestation service is unreachable? I'd want /claim to fail closed by default (SKIP on unverifiable) but configurable — existing integrators shouldn't get surprise denials if attestation is optional in their deployment.
If you're good with a require_attestation flag (default false for backward compat, true for enforcement mode), the fixture would be incredibly useful. Happy to review fast.

[kenneives]

Perfect — and yes, fail-closed is exactly right. Here's the contract I'd propose:

require_attestation (default false) — backward-compatible. When the attestation service is unreachable or returns no verdict:

• require_attestation=false → SKIP (proceed, but write a safety_skipped reason into the record so it's auditable — never a silent pass).
• require_attestation=true → fail closed: DENY before the COMMITTED write.

So existing integrators are untouched; enforcement is one flag. The verdict slots in exactly where you said — verify before COMMITTED, same action_ref, same JCS + SHA-256.

One load-bearing heads-up before you wire it: the jcs() in docs/conformance/verify_fixture.py does json.dumps(dict(sorted(obj.items()))), which only sorts the top-level keys. Real attestations nest objects (attestation.findings.{critical,high,medium,total}), and naive sort leaves the nested keys in insertion order — so the bytes (and the SHA-256) diverge from a true RFC 8785 canonicalization on anything nested. Quick repro:

preimage = {"attestation": {"trust_score": 66,
            "findings": {"total": 7, "critical": 0, "high": 2}}, "nonce": "abc"}
# naive sorted-dumps -> dbf16fed…    rfc8785 -> fb42115e…   (different digest)

Easiest fix is the rfc8785 package on PyPI — it's the canonicalizer we and ~8 other implementations cross-validate byte-for-byte (253/253 against the shared conformance corpus), so you'd be byte-identical to every other verifier for free.

I'll open the PR with: (1) the require_attestation flag + SKIP/DENY behavior above, (2) a verifier wired to rfc8785 that pulls the signed attestation, recomputes binding_digest/action_ref, and checks the Ed25519/JWS against our published JWKS, and (3) a fixture you can run on a fresh clone — our reference fixture already byte-matches an independent verifier 11/11, so it'll line up with your exactly-once-v1.json derivation. Keeping it small and reviewable.

[azender1]

PR #11 merged — 7/7 tests pass, nested JCS fix confirmed, existing flat vectors still byte-match.
Ready to wire the call site into /claim before the COMMITTED write. One question: does attestation come in the request payload from the caller, or does SafeAgent fetch it from AgentGraph directly using the action_ref?

[kenneives]

🎉 thanks for the fast review + merge.

On the wiring: fetch it from AgentGraph directly — with a payload override for resilience.

One correction first: the safety attestation is keyed on the tool/endpoint identity (the resource URI / package ref being paid or called), not the action_ref. action_ref correlates the action (your exactly-once key); the safety verdict is about the target's posture, which can change between scans — so you want it fresh at gate time, not whatever a caller happened to cache.

Recommended shape:

• Default — SafeAgent fetches live by tool/resource identity right before the COMMITTED write, verifies the Ed25519/JWS offline, then runs the gate.
• Optional — caller may pass an attestation in the payload (latency / offline / air-gapped). SafeAgent still verifies the signature offline and checks freshness (reject if older than a configurable freshness_ttl), so a cached verdict can't be replayed stale. Absent/stale → fetch live; fetch fails → your require_attestation policy (SKIP vs DENY).

That keeps the verdict current and independently verifiable, and a caller can't hand you a clean-but-stale attestation. X402SafetyGuard in our SDK already does live-fetch + offline-verify if you want a reference for the fetch path.

[azender1]

@kenneives — thank you, that correction matters. I had the keying wrong — the safety verdict is about the target's posture, not the action identity. Makes sense that it needs to be fresh at gate time rather than correlated to the action_ref.
Recommended shape is clear: live fetch by tool/resource identity as default, caller-supplied attestation as optional with freshness check and signature verification either way. Absent/stale falls back to live fetch, fetch failure hits the require_attestation policy. No path where a stale cached verdict slips through.
Will reference X402SafetyGuard for the fetch path before wiring. Will open a follow-up issue to track the implementation.

[azender1]

@kenneives — wired and deployed. Commit 5884a9d — attestation fetch by tool/endpoint identity before the COMMITTED write, require_attestation env flag, fail-closed on DENY. Live on Railway now. Referenced X402SafetyGuard for the fetch path. Thank you.

[kenneives]

That's the milestone — thank you. A live x402-paid guard fetching the attestation by tool identity and failing closed on DENY before the COMMITTED write is the verify-then-pay loop working end to end, not just wired. Glad X402SafetyGuard was useful for the fetch path.

Two things to keep it solid in prod:

1. Set a freshness_ttl so a slow or cached attestation can't admit a stale clean verdict — bound the preflight-to-reserve window, not just the verdict TTL.
2. When require_attestation is on and the fetch times out, the fail-closed DENY is right — worth surfacing the reason (attestation_unreachable) distinctly in the record so an operator can tell a safety-deny from an availability-deny.

Happy to add a couple of conformance vectors for the fail-closed / stale-verdict paths if that's useful on your side.

[azender1]

@kenneives — both points are right and worth closing properly.
freshness_ttl is the obvious gap — a slow fetch or a cached response could admit a verdict that's no longer current. I'll add a configurable TTL with a sane default and reject anything older.
On the reason codes: agreed, attestation_unreachable should be distinct from safety_deny in the record. An operator needs to know whether the gate fired because of a real safety finding or because AgentGraph was down — those have very different responses.
Yes to the conformance vectors for both paths. If you want to open them against the existing fixture structure that would be incredibly useful, I'll wire the implementation to match.

[kenneives]

Opened both as #12 — attestation_unreachable (availability stop, distinct reason from a safety deny) and attestation_stale (freshness by issued_at / expires_at), with a 5-vector conformance set against the existing docs/conformance/ structure + 7 tests. Both additive and backward-compatible. Wire the live gate to those reason codes and the fixtures drop straight in.

[kenneives]

Two things, one housekeeping.

The reason-code fixtures from #12 are ready to drop in: attestation_unreachable (availability stop) and attestation_stale (freshness by issued_at/expires_at), 5 vectors against the existing docs/conformance/ structure, both additive and backward-compatible. Wire the live gate's reason codes to those two and the set validates as-is. With freshness_ttl plus the two distinct codes, an operator can tell a safety-deny from an availability-deny at read time, which is the property that makes the record worth anything in an incident.

Housekeeping: we renamed AgentGraph to AgentAvow (agentavow.com). The name changed, the wire format did not: same CTEF envelope, same Ed25519/JWS over RFC 8785 JCS, same action_ref. Your deployed fetch keeps working today, because the machine paths on agentgraph.co (/api, /.well-known, /check, /profile) still serve and everything else 301s to agentavow.com. Next time you touch the fetch path, point it at agentavow.com as the canonical host.

I'll update this issue's title off the old name so it doesn't go stale in your tracker.

[kenneives]

Checking in on this one — the #12 reason-code set is still ready to drop in as-is: attestation_unreachable (availability stop) and attestation_stale (freshness by issued_at/expires_at), 5 vectors against the existing docs/conformance/ structure, both additive and backward-compatible. Once the live gate emits those two codes distinctly the set validates on a fresh clone with no changes on your side. That's the last piece that lets an operator tell a safety-deny from an availability-deny at read time during an incident. No rush — ping me if you want a hand wiring the code paths to the fixtures.