Ecosystem integration tracker — signed receipts across agent frameworks

[tomjwxf]

Purpose

Track the adoption and interoperability of Acta signed receipts across the agent governance ecosystem. Each integration produces receipts that verify at exit 0 against npx @veritasacta/verify.

Active Integrations

Framework	Stars	Integration	Status	Verification
Microsoft AGT	930+	Cedar policy bridge + receipts	PR #667	npx @veritasacta/verify ✅
Cedar for Agents	19	WASM bindings for schema gen	PR #64	N/A (policy engine)
Google ADK	18.9K	Audit receipt middleware	RFC #5164	Proposed
Mission Control	3,700+	Receipt signing for MCP audit	PR #556	npx @veritasacta/verify ✅
DeerFlow	57,600+	Persistence layer integrity	Discussion #1855	Proposed
aeoess/agent-governance-vocabulary	—	Canonical naming crosswalk	Crosswalk PR pending	N/A (standards)
Revettr	—	compliance_risk receipts for x402 / MPP agent commerce	A2A Discussion #1734	RFC 7515 compact JWS, ES256, JWKS at https://revettr.com/.well-known/jwks.json
Agent Passport System	—	Governance hook driver + governance_attestation receipts	testvectors#1 (merged)	npx @veritasacta/verify ✅ (6/6 conformance checks)

Verification invariant

All implementations MUST produce receipts that:

1. Verify at exit 0 with npx @veritasacta/verify receipt.json
2. Follow IETF draft-farley-acta-signed-receipts-01
3. Use Ed25519 + JCS canonicalization

How to add an integration

Open a PR or comment on this issue with:

• Framework name and link
• Integration type (receipt signing, policy enforcement, verification)
• Link to PR/issue
• Confirmation that npx @veritasacta/verify validates the output

This issue serves as the canonical tracking point for the ecosystem.

[tomjwxf]

cc @aeoess — tracking this as the canonical interop page. Every integration listed here produces receipts that verify with npx @veritasacta/verify. If the governance vocabulary crosswalk lands, we'd add a column showing which vocabulary primitives each integration maps to.

The active integrations so far:

• Microsoft AGT: Cedar policy → receipt (PR #667)
• Google ADK: Audit middleware → receipt (RFC #5164)
• Cedar for Agents: WASM bindings (PR #64)

@AlexanderLawson17 — your A2A RFC trust evidence categories from Discussion #1734 could be cross-referenced here. The signed receipts provide the cryptographic backing that the trust evidence taxonomy describes.

[AlexanderLawson17]

Thanks for the cc. Flagging that Revettr should slot in under a compliance_risk row for this tracker. We publish pre-interaction counterparty risk attestations for x402 / MPP agent commerce, which is the category I proposed as an 8th primitive in A2A Discussion #1734 (Discussion #1734 mapping does line up cleanly with the signed receipts column here).

Coordinates:

• DID: did:web:revettr.com
• Discovery: https://revettr.com/.well-known/risk-check.json
• JWKS: https://revettr.com/.well-known/jwks.json (ES256, kid: revettr-attest-v1)
• Revocations: https://revettr.com/.well-known/revocations.json
• Attest endpoint: POST https://revettr.com/v1/attest (free, 10/min per IP)
• Score endpoint: POST https://revettr.com/v1/score (free tier 100/day per IP, paid tier $0.01 USDC via x402)

Envelopes are RFC 7515 compact JWS over a canonical payload, so any spec compliant verifier that can fetch the JWKS should exit 0. Happy to run a receipt through npx @veritasacta/verify and attach the output if that is the shape you want for the Verification column.

One note worth surfacing for receipt verifiers: we shipped revettr-engine PR #20 earlier today which extended a denial of wallet fix to /v1/score and /v1/score/batch and refactored a shared _envelope_signal_view helper across all three signing sites. Free tier envelopes now carry real signal data instead of the previously empty signals.wallet shape, and they also surface wallet.insumer_skipped: true so a verifier can distinguish free tier from paid ($0.01 USDC) attestations without inspecting the x402 receipt separately.

Let me know if you want a PR against this issue body to add the row, or if you prefer to drop it in yourself.

[AlexanderLawson17]

Here's the row in the tracker format, ready to paste into the Active Integrations table:

| [Revettr](https://revettr.com) | — | `compliance_risk` receipts for x402 / MPP agent commerce | [A2A Discussion #1734](https://github.com/a2aproject/A2A/discussions/1734) | RFC 7515 compact JWS, ES256, JWKS at `https://revettr.com/.well-known/jwks.json` |

Columns match the existing shape (Framework, Stars, Integration, Status, Verification). Stars left as em dash placeholder per the aeoess/agent-governance-vocabulary row since Revettr is a hosted service with no public repo yet. Happy to swap the Verification cell for an npx @veritasacta/verify receipt.json output once the Acta verifier supports ES256 alongside Ed25519, or to produce an Ed25519 sibling signature if you want strict parity with the current verify invariant.

[tomjwxf]

@AlexanderLawson17 this is the kind of row I was hoping this tracker would attract, a production system with real endpoints, real cryptographic signing, and a concrete integration surface.

On ES256 support in @veritasacta/verify:
The current verifier is Ed25519-only. The IETF draft (draft-farley-acta-signed-receipts-01) specifies Ed25519 as the mandatory-to- implement algorithm but doesn't prohibit additional algorithms. Adding ES256 verification is a straightforward extension — the JWS compact serialization you're using and the JCS+Ed25519 envelope we use are structurally different but the verification logic (fetch JWKS → resolve kid → verify signature over canonical payload) is the same pattern.

I'll open a tracking issue for ES256 support in @veritasacta/verify. In the meantime, if you can produce an Ed25519 sibling signature alongside the ES256 envelope, we can get you to exit 0 on the current verifier immediately.

On the table row:
Please go ahead and open a PR against this issue body to add the row. I'd suggest one small modification to the Verification column: RFC 7515 compact JWS, ES256 · Ed25519 sibling pending · JWKS at https://revettr.com/.well-known/jwks.json

This makes it clear that the ES256 path exists and works today, and the Ed25519 parity is in progress.
The compliance_risk category is a good addition to the taxonomy — it maps to a gap in the current tracker (all existing rows are either policy enforcement or audit/provenance, none are pre-interaction risk assessment).
Worth cross-referencing in the governance vocabulary crosswalk once that lands.

[AlexanderLawson17]

Thanks for the column modification. Adopting it verbatim.

| [Revettr](https://revettr.com) | — | `compliance_risk` receipts for x402 / MPP agent commerce | [A2A Discussion #1734](https://github.com/a2aproject/A2A/discussions/1734) | RFC 7515 compact JWS, ES256 · Ed25519 sibling pending · JWKS at `https://revettr.com/.well-known/jwks.json` |

On the Ed25519 sibling signature: shipping tonight. New PR against revettr-engine will extend the signing path so every envelope carries both an ES256 signature and an Ed25519 sibling signature over the same canonical payload, with JWKS publishing both keys under distinct kid values. That should get Revettr envelopes to exit 0 on the current @veritasacta/verify immediately, ahead of ES256 landing. I will update this issue with the merge commit and a sample JWS envelope carrying both signatures the moment it is live.

Standing by for the ES256 tracking issue on @veritasacta/verify. Happy to run Revettr envelopes through the verifier the moment ES256 lands, and happy to contribute test fixtures from production attestations if that accelerates the PR. Real envelopes with valid kid, canonical payload shape, and live JWKS resolution are easy to pull on request.

On the governance vocabulary crosswalk: Revettr is already in-flight there. The aeoess/agent-governance-vocabulary crosswalk PR #4 merged Apr 11 15:24 UTC (commits 39457d7 and 063be63), so the cross-reference can land immediately rather than waiting. Revettr's entry there sits under the same compliance_risk slot, so the tracker row and the vocabulary crosswalk will agree on taxonomy position.

On the taxonomy gap: that was the exact motivation for proposing compliance_risk as the 9th category in A2A Discussion #1734. Every existing trust evidence primitive sat in policy enforcement or audit/provenance, leaving pre-interaction risk assessment with no home. The VeritasActa tracker row will mirror the same slot Revettr occupies in the A2A RFC.

[tomjwxf]

@AlexanderLawson17 Ed25519 sibling signature shipping tonight is exactly the right move. Once that's live, send me a sample envelope and I'll confirm exit 0 against the current verifier.

ES256 tracking issue opened: #4. The scope is straightforward — extend the verification path to resolve ES256 keys from JWKS alongside Ed25519, same kid → alg → verify pattern. Your production envelopes with live JWKS resolution would be ideal test fixtures for the PR — real signed payloads beat synthetic vectors every time. Happy to take those whenever you're ready.

Updated the tracker table with your row. The crosswalk PR #4 merge on agent-governance-vocabulary means the taxonomy position (compliance_risk) is now consistent across the vocabulary, the A2A RFC, and this tracker — three layers pointing at the same slot, no translation needed.

[aeoess]

The Revettr row landing here lines up cleanly with the compliance_risk slot on the vocabulary side. Three layers pointing at the same primitive (vocabulary canonical name, A2A RFC category, this tracker row) without translation needed is the convergence pattern this work is supposed to produce.

On the ES256 + Ed25519 sibling approach: the dual-signature pattern @AlexanderLawson17 is shipping is a clean v1 solution that gets envelopes to exit 0 on the current verifier immediately, without waiting on #4 to land. Worth noting it generalizes beyond Revettr — any ES256-native issuer can use the same sibling pattern as a transition path while broader algorithm support is being added.

No spec or vocabulary changes needed from the APS side for this row to land.

[tomjwxf]

@aeoess agreed on both points. The dual-signature sibling pattern as a transition path for ES256-native issuers is worth documenting explicitly. Once #4 lands and the verifier handles both algorithms natively, the sibling approach becomes optional rather than required, but issuers who want maximum backward compatibility can keep shipping both.

On the three-layer convergence (vocabulary canonical name → A2A RFC category → this tracker row): that was the goal. A new issuer should be able to look at one table and know where their receipts fit in the taxonomy, what verification path applies, and which vocabulary primitives they map to, without reading three separate specs.

Standing by for @AlexanderLawson17's Ed25519 sibling envelope to confirm exit 0.

[AlexanderLawson17]

@tomjwxf Ed25519 sibling is live. Both keys are published at the JWKS endpoint:

https://revettr.com/.well-known/jwks.json

Two kids:

• revettr-attest-v1 (ES256, P-256) — primary
• revettr-attest-ed25519-v1 (EdDSA, Ed25519) — sibling

Sample envelope with dual signatures:

{
  "provider": {
    "id": "did:web:revettr.com",
    "category": "compliance_risk"
  },
  "subject": {
    "id": "did:web:agent.example.com"
  },
  "attestation": {
    "type": "ComplianceRiskAttestation",
    "confidence": 0.87,
    "payload": {
      "iss": "did:web:revettr.com",
      "sub": "did:web:agent.example.com",
      "iat": 1775817135,
      "exp": 1775820735,
      "category": "compliance_risk",
      "score": 87,
      "tier": "low",
      "flags": ["wallet_established", "sanctions_clear"],
      "signals": {
        "sanctions": 100,
        "domain": 88,
        "ip": 91,
        "wallet": 74
      }
    }
  },
  "jws": "<ES256 compact JWS>",
  "kid": "revettr-attest-v1",
  "algorithm": "ES256",
  "sibling": {
    "jws": "<Ed25519 compact JWS>",
    "kid": "revettr-attest-ed25519-v1",
    "algorithm": "EdDSA"
  },
  "jwks_url": "https://revettr.com/.well-known/jwks.json",
  "revocations_url": "https://revettr.com/.well-known/revocations.json"
}

The Ed25519 signature covers the same canonical payload as the ES256 primary. Verifiers pick whichever algorithm they support. Once your ES256 path lands (#4), the sibling becomes optional but we will keep emitting both for maximum compatibility.

Happy to generate a live envelope from a real scoring request if that is more useful for testing.

[aeoess]

Adding APS to the tracker. Integration row below in the table's existing format:

Framework	Stars	Integration	Status	Verification
Agent Passport System	—	Governance hook driver + governance_attestation receipts	ScopeBlind/agent-governance-testvectors#1 (merged)	npx @veritasacta/verify ✅ (6/6 conformance checks pass)

The driver shipped in the multi-implementation conformance suite alongside protect-mcp / protect-mcp-adk / sb-runtime. Cross-verification works today: APS-produced enforcement records verify at exit 0 against the Acta verifier, and Acta-produced decision receipts verify against the APS gateway's /api/v1/public/trust/:agentId JWS trust profiles.

On the sibling governance_attestation predicate for in-toto (referenced in in-toto/attestation#549) — once the Decision Receipt predicate lands, APS will file the sibling PR under the veritasacta.com/attestation/ namespace (or whichever namespace this ecosystem converges on) so action-level receipts and session-level attestations become two independently-queryable predicate types that reference each other by hash rather than by embedding.

@AlexanderLawson17 — the Ed25519 sibling landing at the Revettr JWKS is the clean precedent for dual-algorithm issuers. The APS gateway JWKS at https://gateway.aeoess.com/.well-known/jwks.json publishes EdDSA today; if verifier adoption stays Ed25519-primary, the ES256 sibling question doesn't arise on our side, but the pattern you established is the right template for any issuer that starts on a different curve and wants to converge.