Anumati (ACAP): a versioned consent and per-action adherence extension for A2A

[ravikiran438]

We are proposing the Agent Consent and Adherence Protocol (ACAP) as a
non-breaking A2A extension that addresses usage-policy adherence —
what the callee's Terms of Service actually permit, whether the
caller parsed those terms, and whether the caller honoured them
per-action. This is a distinct layer from agent identity,
authentication, trust scoring, or OAuth-style permission scopes, and
is intended to coexist with proposals at those layers.

Under UETA §14 the human principal is bound by whatever terms their
agent accepts, and under the EU AI Act Articles 14 and 50 high-risk
agent deployments need auditable records of how policy was honoured
per-action. A2A today has no object for either.

The preprint, reference implementation, TLA+ specification, and a
working demo (two agents using Gemini 2.5 Flash for claim parsing)
are public.

Resources

• Paper (arXiv): https://doi.org/10.48550/arXiv.2604.16524
• Repository: https://github.com/ravikiran438/agent-consent-protocol
• Extension URI: https://github.com/ravikiran438/agent-consent-protocol/v1

What the extension does

ACAP introduces three primitives that sit on top of A2A's
capabilities.extensions mechanism without any changes to the core
specification:

• PolicyDocument, a versioned and content-addressed usage policy
  that the callee publishes alongside its AgentCard
• ConsentRecord, the caller's per-agent-pair record of having parsed
  the callee's policy clause-by-clause
• AdherenceEvent, a per-action reasoning record that cites the
  specific clause evaluated before each skill invocation

Enforcement is carried out by middleware at the caller and callee
boundaries such that the A2A runtime itself needs no modification.

ACAP does not define agent identity, authentication, trust scoring,
or permission scopes; it assumes those are handled at other layers.

How it relates to existing discussions

This is complementary to the governance-metadata proposal in #1717.
The two address different questions: #1717 focuses on trust metadata
that a receiving agent can use to assess a caller before engaging,
while ACAP focuses on recording the calling agent's per-clause
evaluation of the callee's usage policy once an interaction is under
way. We mention the parallel for context; neither proposal depends
on the other.

What we have

• Protobuf schema and TLA+ specification (7 safety + 2 liveness
  properties model-checked under TLC)
• Python reference implementation with 35 unit tests and a micro
  benchmark (microsecond-scale validator overhead, reproducible)
• End-to-end demo with a marketing-insights caller and a
  data-analysis callee, using Gemini 2.5 Flash for claim parsing,
  showing the consent handshake, a blocked skill call on a disputed
  purpose, and a permitted skill call
• Four extension proposals maintained in the repository under
  extensions/ (governance tiering, category preferences,
  regulatory context, audit projection)

Feedback welcome

Feedback on the design and the accompanying repository is welcome,
here or as issues on the ACAP repository itself.

[arian-gogani]

really interesting to see this formalized — the three primitives map cleanly to what i've been building in a different context.

the PolicyDocument → ConsentRecord → AdherenceEvent pipeline is essentially the same pattern as covenant → enforcement → action log that we use in Nobulex. the key design choice you've made that i think is right is separating this from identity/auth — those are different verification problems with different evidence types.

a few things i noticed going through the spec:

1. content-addressed policy versioning is a good call. we hash covenants with SHA-256 so the verifier can confirm the exact policy version that was enforced. sounds like you're doing something similar?

2. per-action reasoning records — this is the hardest part to get right in practice. if the adherence record is just "allowed/blocked" it's easy. if you're recording why (which clause matched, what condition was evaluated), that gets expensive fast. how are you handling the recording overhead? in our benchmarks, covenant evaluation is ~0.7µs per action for a 3-rule policy, but the logging adds ~3µs on top.

3. the TLA+ specification is a nice touch — model checking the safety properties is the right approach for something that's supposed to provide audit guarantees.

one question: does ACAP assume the adherence middleware runs on the caller side, the callee side, or both? in Nobulex the enforcement runs on the agent's own middleware (self-policing), and the verification is done externally by the counterparty through a hash-chain integrity check. curious how ACAP handles the trust boundary there.

[ravikiran438]

Thanks for the careful read, @arian-gogani. Yes, the structural parallel is similar: both pipelines have a declaration, an enforcement point, and a hash-chained log, and both use SHA-256 content addressing.

The main difference is authorship. In Nobulex the agent declares the rules it will follow. In ACAP the callee publishes its own Terms of Service as the PolicyDocument, and the caller's AdherenceEvents are per-clause attestations against that policy. Both produce tamper-evident history but for different questions: whether the agent followed its own rules, versus whether the caller honored the callee's terms.

On content-addressing: yes, SHA-256 over canonical JSON (RFC 8785), with the hash field zeroed before hashing to break the self-reference.

On the trust boundary, ACAP runs on both sides with asymmetric roles. The caller emits AdherenceEvent with per-clause reasoning (self-attestation). The callee validates chain integrity, enforces the "no permit on disputed claim" invariant, and gates skill execution at the request boundary via require_permit. So the callee is the active enforcement point, not a post-hoc verifier. The reason is the threat model: ACAP assumes the caller may be compromised, so self-policing alone would let an attacker submit plausible-looking but dishonest records. That said, self-policing avoids the round-trip and can be faster in deployments where the caller is already trusted.

[chopmob-cloud]

The AdherenceEvent primitive — a per-action record citing the specific clause evaluated — is the right object, and AlgoVoi runs a production form of exactly that today. Worth mapping, since the EU AI Act Art. 14/50 "auditable per-action record" requirement is the hard part, not the consent handshake.

AlgoVoi issues a signed scoped-authorization receipt per high-impact action, advertised on a live agent card:

https://api.algovoi.co.uk/ext/scoped-authorization-receipts/v1 (probeable now)

Where it lines up with ACAP, and where it adds something:

• Per-action identity. Each action carries action_ref = SHA-256(JCS(...)) — a content-addressed handle for the exact action, the same content-addressing instinct behind PolicyDocument. An AdherenceEvent could cite the action_ref it adhered for.
• The outcome is load-bearing, not advisory. A closed categorical enumeration — ALLOW / REFER / DENY — rather than a pass/fail flag. For Art. 50 disclosure this matters: a REFER can carry a reporting obligation a DENY does not, and that distinction has to survive into the auditable record.
• Offline, years-later re-verification. The record is an EdDSA/Ed25519 JWS over JCS-canonical (RFC 8785) bytes with the canonicalisation rule pinned in-band, binding action, resource, request_digest, provider_did, issued_at, jurisdiction. An auditor re-verifies from retained bytes alone against the published jwks_uri — no call home, no out-of-band registry, which is what a statutory retention period actually demands.

ACAP records that a clause was honoured; a signed categorical receipt makes that record independently verifiable long after the fact. The two compose cleanly.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/compliance-receipt