RFC-003: Cross-jurisdictional audit-log reciprocity.

Status: Draft. Author: Nazareno Clemente (naza@helloastro.co). Discussion: github.com/ar-agents/ar-agents/discussions. License: CC-BY-4.0.
Companions: RFC-001 (three-layer liability + § 9 audit log spec), RFC-002 (agent-discovery-by-default convention).

1 · The cross-jurisdictional drift problem

Recipe 21 in the cookbook is concrete: a USA-incorporated agent (Wyoming DAO LLC) signs an AP2 mandate, an AR sociedad-IA verifies it, emits the factura, lands the cobro. Each side keeps its own audit log:

• The USA-LLC's log knows: I issued a mandate at T0 for $X to AR-CUIT-Y, payable for T0+24h.
• The AR sociedad's log knows: I received mandate M, verified its signature, ran 8 gates, emitted CAE 123456 for $X.

Both logs are HMAC-signed. Each is verifiable independently. But the cross-jurisdictional contract— "the USA-LLC promised X, the AR sociedad delivered X, the chain matches" — only holds if both sides import each other's evidence + the interchange format is portable.

Today, each pair of jurisdictions invents this format ad-hoc. Lawyers + auditors agree on a spreadsheet template. The spreadsheet becomes the single point of trust. When the spreadsheet is wrong, every dispute downstream is messy.

2 · Proposal

Every agent-entity regime publishing audit logs SHOULD support a portable interchange envelope with these fields:

{
  "$schema": "https://ar-agents.vercel.app/schemas/cross-jurisdiction-audit.v1.json",
  "issuer": {
    "jurisdiction": "AR" | "US-WY" | "MH" | "EE" | "US-DE" | ...,
    "entityId": "ar-sociedad:30123456789" | "wyoming-dao-llc:claw-bank" | ...,
    "publicKey": { /* JWK */ },
    "evidenceCustodyUrl": "https://operator.example/api/audit/{sessionId}?verify=1"
  },
  "sessionId": "uuid-or-token",
  "entries": [
    {
      "id": "...",
      "ts": "ISO-8601 UTC",
      "tool": "...",
      "governance": "...",
      "input": ...,
      "output": ...,
      "hmac": "sha256:..."   // signed by issuer
    }
  ],
  "externalReferences": [
    {
      "counterpartEntityId": "wyoming-dao-llc:claw-bank",
      "counterpartSessionId": "...",
      "counterpartEvidenceUrl": "https://claw-bank.example/audit/...?verify=1",
      "linkType": "ap2-mandate" | "acp-checkout" | "manual",
      "linkId": "claw-bank:tx_42"
    }
  ],
  "issuedAt": "ISO-8601 UTC",
  "expiresAt": "ISO-8601 UTC"   // 30d default; counterpart should re-fetch before this
}

Three guarantees per envelope:

• Self-verifiable. Each entry is signed by the issuer. The counterpart fetches the envelope, recomputes the HMACs against the issuer's public key, and confirms the log is clean before relying on it.
• Cross-linked. The externalReferencesarray points back at the counterpart's evidence URL with the link type that joins them (e.g., AP2 mandate, ACP checkout session, manual spreadsheet row). Either side can walk the graph.
• Time-bounded. expiresAt tells the counterpart how long the envelope is meant to be authoritative. After expiry, fetch a fresh copy. Prevents stale evidence claims.

3 · How AR sociedad-IA would emit this

New endpoint: GET /api/play/audit/{sessionId}.crossjur returns the envelope above, wrapping the existing audit entries. The HMAC layer is the same; we just add the issuer metadata + any recorded cross-links.

Cross-links are populated when the AR side calls a recipe-21-style flow:

// At verify-and-act time, the AR side records the cross-link:
await appendAudit(sessionId, {
  tool: "cross_jurisdictional_factura_emit",
  governance: "audit-logged",
  input: {
    mandate: { issuer, claims },
    counterpartEntityId: mandate.issuer,
    counterpartSessionId: mandate.claims.counterpartSessionId,
    counterpartEvidenceUrl: mandate.claims.counterpartEvidenceUrl,
    linkType: "ap2-mandate",
    linkId: mandate.claims.externalId,
  },
  output: { facturaCae: result.cae, ... },
});

The cross-jurisdictional envelope endpoint reads those records, extracts the externalReferences array, and wraps everything in the portable shape.

4 · How Wyoming / MIDAO / Estonia would emit this

Each foreign regime would implement the same .crossjur endpoint on their audit-log surface. The minimum spec:

• Each entry in entries[]includes an HMAC or equivalent signature against the issuer's public key (JWK in issuer.publicKey).
• Cross-links to AR-side evidence go into externalReferences[] with counterpartEvidenceUrlpointing back at the AR sociedad's public audit endpoint.
• expiresAt at least 30 days out; refresh before expiry.

We don't need to dictate theiraudit-log implementation. RFC-003 only specifies the interchange envelope. Wyoming DAO LLC operators using a different signing scheme (e.g., an on-chain commitment) can wrap their evidence in the envelope as long as the signature is verifiable against the issuer's published key.

5 · How reconciliation works in practice

1. Auditor (or automated compliance script) fetches AR side's envelope at https://ar-agents.vercel.app/api/play/audit/{sid}.crossjur.
2. Verifies each entry's HMAC against the AR side's published key.
3. For each externalReference, fetches the counterpart's envelope.
4. Verifies the counterpart's entries against the counterpart's key.
5. Cross-references: the AR side's factura-emit entry should point to the Wyoming side's mandate-issue entry, both referencing the same linkId.
6. A discrepancy (e.g., Wyoming says "mandate issued for $X", AR says "factura emitted for $Y") is mechanically detectable + adjudicable.

6 · Why this matters now

Three trends compounding:

• AR sociedad-IA ship 2027. The headline use case for the regime is cross-jurisdictional agent commerce (RFC-001 § 7).
• MIDAO is operational in Marshall Islands. Wyoming DAO LLCs exist. Estonia e-Residency is a decade old. The set of foreign agent entities the AR side can transact with is non-empty today.
• Spreadsheet-based reconciliation doesn't scale past ~50 cross-jurisdictional transactions per month. A marketplace with multiple foreign sellers + automated AR incorporation per recipe 20 hits that ceiling fast.

7 · What we'd need from foreign jurisdictions

• A public audit-log endpoint that returns HMAC-signed (or equivalent) entries.
• A published public key (JWK or X.509) for each issuer entity, with rotation procedure documented.
• Willingness to implement the .crossjur envelope. Backwards-compatible add — they can keep their existing audit format.

Wyoming DAO LLC operators using on-chain attestations (e.g., Ethereum/Polygon) can satisfy the spec with publicKey: { "kty": "eth-attestation", "address": "0x..." } plus an EAS-style attestation per entry. The interchange envelope accepts any signature scheme that's independently verifiable.

8 · Implementation plan for the AR side

1. Define schemas/cross-jurisdiction-audit.v1.json (JSON Schema, draft 2020-12).
2. Ship GET /api/play/audit/{sessionId}.crossjur on ar-agents.vercel.app. Reuses existing primitives in src/lib/audit.ts; adds envelope wrapping + external-reference extraction.
3. Update recipe 21 to populate externalReferences on every cross-jurisdictional tool call.
4. Add a verifier library (@ar-agents/crossjur-verify) that takes an envelope + the counterpart's envelope and returns a reconciliation report.
5. Add a cookbook recipe (recipe 25) showing the auditor flow end-to-end with sample envelopes from both sides.

9 · Security

• Signature scheme is per-issuer. RFC-003 doesn't mandate HMAC-SHA256; it requires that the signature be verifiable against the published key. ES256/JWS (per AP2), HMAC-SHA256 (per RFC-001 § 9.2), Ethereum EAS, on-chain commitments — all acceptable.
• Replay defense. The envelope includes issuedAt + expiresAt. Consumers should reject envelopes whose issuedAt is in the future or whose expiresAt is in the past.
• Privacy. The envelope is public-readable. Operators must not log PII / secrets / customer-specific identifiers in the underlying entry input / output. Same discipline as RFC-001 § 9 (no PII in the audit log).
• Key rotation. The envelope's issuer.publicKey is current-valid; prior envelopes signed with a previous key remain verifiable as long as the issuer publishes their key history (recommended path: /.well-known/keys.json with kid + validFrom + validUntil).

10 · Why not just use the existing format from one jurisdiction

Two reasons:

• Sovereignty. No jurisdiction wants to import a format defined by another. RFC-003 is deliberately jurisdiction-neutral so each regime can adopt without ceding format authority.
• Signature scheme heterogeneity. The AR side uses HMAC-SHA256. Wyoming DAO LLCs use on-chain commitments. Estonia OÜ uses ID-card + X-Road signing. The envelope is the common surface; the inner signatures stay native.

11 · Adoption path

Step 1: ship the AR-side endpoint. Step 2: write a reference verifier library + cookbook recipe. Step 3: propose to MIDAO / a Wyoming DAO LLC platform to implement the counterpart endpoint. First cross-jurisdictional reconciliation between two real entities is the proof point.

If you operate an agent-entity in any of these regimes and want to coordinate, drop a comment in the discussions.

12 · References

• RFC-001 § 9 — AR-side audit log spec.
• RFC-002 — agent-discovery-by-default (cross-jurisdictional verifier libraries would consume RFC-002 wells to find counterpart endpoints).
• Cookbook R21 — the AP2 mandate verification flow this RFC builds on.
• /comparison — Wyoming / MIDAO / Estonia / Delaware regime context.
• RFC 7519 — JWT, the format model for the envelope claims.
• Ethereum Attestation Service — alternative on-chain signature scheme the envelope can wrap.