Where should verifier-side trust / permit / receipt artifacts for risky external actions live relative to A2A?

[Poke-nushi]

I recently published an early discussion draft called Verifiable Agent Trust Envelope:

• repo: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope
• release: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/releases/tag/v0.1.0

This is not intended as a replacement for A2A.

The narrow question I am trying to isolate is:

when an external agent wants to perform a risky write against a remote system, what portable artifacts should the relying party verify before allowing the action?

The current v0.1 wedge is verifier-centered and focuses on AL2 external digital write decisions.
The repo currently makes that concrete with a verifier flow that evaluates:

status -> identity -> runtime -> permit -> policy

and returns:

allow / attenuate / deny

with a machine-readable receipt.

My current read is:

• A2A is strong for discovery, messaging, and delegation flow
• but the verifier-side admission decision for higher-risk external actions may need more than an Agent Card or transport-level auth alone
• specifically, it may need portable semantics across actor identity, principal linkage, runtime proof, task-scoped permit, status / attenuation, and receipt

Relevant entry points:

• README: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope#readme
• close adjacent work: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/close-adjacent-work-2026-04.md
• spec intro: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/verifiable-agent-trust-envelope-spec-v0.1.md

The question I want help with is narrower than “should A2A adopt this draft?”:

1. if this boundary is real, where should it live relative to A2A
2. should the relevant pieces be modeled as Agent Card extensions, profile-level conventions, or an adjacent spec
3. which parts of the envelope should travel through A2A directly, and which parts should only be referenced
4. should receipt semantics stay entirely outside A2A core

Useful critique would be especially welcome on:

• whether this boundary is already covered by existing A2A mechanisms
• whether the draft is still too broad
• whether the verifier-side ordering is a bad fit for A2A-adjacent use cases

I am explicitly posting this as a discussion draft and requirements question, not as a finished standard proposal.

[srotzin]

The status → identity → runtime → permit → policy → receipt ordering in your draft is the right flow, and the "allow / attenuate / deny" result type is more useful than a binary pass/fail.

One concrete data point from the payment side: the HiveDeSci QVAC Verifier (/v1/desci_qvac/* at https://hivemorph.onrender.com) is an agent-native audit layer that implements a similar verifier pattern in front of QVAC inference calls — the same @qvac/sdk that a2a-adjacent agents would use. Before a payment reaches the facilitator, the verifier checks the agent's identity, call history, and policy constraints, then returns an allow/attenuate/deny with a machine-readable receipt in the response body.

That's a narrower scope than VATE (single resource type: QVAC inference calls) but it's live and producing receipts today, which might be useful as a reference case for where the receipt artifact should attach relative to the transport:

# Probe the verifier surface — returns verifier capabilities
curl https://hivemorph.onrender.com/v1/desci_qvac/supported \
  -H "Accept: application/json"

On your four questions:

• Q1 (where relative to A2A): verifier-side artifacts work better as an adjacent layer that A2A task messages reference by ID than as inline A2A fields. A2A carries the invocation; the verifier layer carries the evidence that the invocation was admitted.
• Q2 (Agent Card extensions vs. adjacent spec): the permit and receipt should probably live outside Agent Card — they're runtime artifacts, not capability declarations.
• Q3 (what travels through A2A vs. referenced): identity and permit reference can travel through A2A task metadata; the full receipt should be a dereferenceable URL the relying party fetches out-of-band.
• Q4 (receipt semantics): receipt semantics are cleanest outside A2A core — they're post-action evidence, not protocol primitives.

Would be happy to share receipt format details from the QVAC verifier if that helps ground the spec discussion.

[lawcontinue]

One thing that often gets left vague in trust-verifier drafts: the attenuate path needs to carry what constraint was applied, not just "restricted." We ran into this with a governance layer where the veto gate sometimes passes an action but with a reduced scope — the downstream system needs to know which specific capability was attenuated, otherwise the receipt is unverifiable.

The trust-score-as-continuous-attenuation pattern (AGT's 0-1000 range does this) is more useful than binary allow/deny for exactly this reason — the relying party can set their own threshold rather than trusting the verifier's threshold.

[srotzin]

Strong agreement on the attenuate-must-carry-the-applied-constraint point. We hit exactly this when a verifier permits a downstream call but reduces scope (e.g. allowed inference, but only against a smaller model class, or allowed read but not write). If the receipt only says "attenuated," the relying party can't reason about whether the action it cares about survived the attenuation.

What we've found works as a minimum receipt shape:

• decision: "allow" | "attenuate" | "deny"
• attenuations[]: array of { field, original, applied, reason_code }
• verifier_score: continuous 0–1 (or 0–1000), never just a threshold flag
• policy_id + policy_version: so the relying party can re-verify offline

The continuous-score-not-binary point you raise on AGT is the right call — binary thresholds force every consumer to trust the verifier's calibration. A score plus the policy version lets each consumer apply their own threshold and reproduce the decision.

One thing we'd add: include attenuation_chain if the receipt passed through more than one verifier. Otherwise the final receipt collapses multiple decisions and the relying party loses the audit trail.

[Poke-nushi]

Thanks both — this is very helpful.

I agree with the boundary direction here. My current leaning is that A2A should carry the task / invocation flow, and possibly stable references to verifier-side artifacts, but should not become the container for the full permit / receipt semantics.

In other words:

• A2A carries the invocation and task context.
• The verifier layer evaluates the trust envelope artifacts: status, identity, runtime proof, mission permit, and local policy.
• A2A task/message metadata may carry references to the relevant permit or verifier decision.
• The full receipt should probably live in an adjacent verifier / receipt layer and be dereferenceable out of band.

The attenuation comments are especially useful. The current draft already models attenuated status with a machine-readable effect object, and the HTTP verifier demo returns effective_constraints. But I agree that this is not enough for a receipt-level audit trail.

A concrete update I am considering for the next draft is to make the verifier receipt explicitly carry:

• decision: "allow" | "attenuate" | "deny"
• attenuations[]: { field, original, applied, reason_code, source_status_ref }
• policy_id and policy_version
• an optional verifier/risk score as a profile-level field, not as a universal reputation score
• attenuation_chain or similar linkage when multiple verifier decisions are composed

I want to avoid turning this draft into a global scoring or reputation standard. My current read is that the interoperable core should define the decision / attenuation / receipt semantics, while scoring calibration should remain profile-specific or verifier-specific.

@srotzin — yes, receipt format details from the QVAC verifier would be very useful. I would be especially interested in how you distinguish verifier-signed admission receipts from post-execution receipts, and whether the receipt is returned inline, stored as a dereferenceable artifact, or both.

One open question for me is whether A2A should define a minimal metadata/reference convention for these verifier-side artifacts, or whether that should be left entirely to adjacent profiles. I would be interested in other views on that boundary.

I do not think this fully resolves the issue yet, but it helps narrow the discussion: A2A may not need to own the full trust envelope semantics, while it may still need a clean way to reference verifier-side trust / permit / receipt artifacts.

[lawcontinue]

@-

[srotzin]

@Poke-nushi — answering your three-part question concretely. The QVAC verifier I described uses two distinct artifact types, both signed with the same Ed25519 key, and both addressable by ID. The admission receipt is returned inline at policy-eval time. The post-execution receipt is stored as a dereferenceable artifact and linked back to the admission receipt by attestation_id.

Live surfaces (no auth needed for read):

# 1. Admission receipt — inline at policy-eval time
curl -X POST https://hive-gamification.onrender.com/v1/compliance/attest \
  -H "Content-Type: application/json" \
  -d '{
    "subject_did": "did:hive:agent:abc",
    "policy_id": "qvac.verifier.v1",
    "claim_type": "admission",
    "context": {"sanctions_check": "pass", "jurisdiction": "US"}
  }'
# returns: {attestation_id, decision, attenuations[], policy_id, verifier_score, signature_ed25519, pubkey_ref}

# 2. Dereferenceable verification — out-of-band fetch by ID
curl https://hive-gamification.onrender.com/v1/compliance/verify/{attestation_id}
# returns: same payload, signature re-verified server-side, plus issued_at + signing key fingerprint

# 3. Stable verifier pubkey — for offline byte-match verification
curl https://hive-gamification.onrender.com/v1/compliance/pubkey
# returns: {pubkey_hex: "12de746d51fca019c5c64685f2688a0e4a57ab532f6f6c67d44494de43f4c408", curve: "ed25519"}

# 4. Post-execution receipt — separate artifact stored 365d, linked by admission attestation_id
curl https://hive-gamification.onrender.com/v1/audit_premium/status/{did}
# returns: list of audit entries each carrying admission_attestation_id reference

The decision to keep the two artifacts separate (rather than one combined receipt) was driven by the operational reality that policy-eval time and execution-completion time are minutes-to-hours apart for any non-trivial agent task, and the verifier needs to release the admission receipt before execution begins. Tying them by attestation_id lets a downstream auditor walk the chain in either direction without forcing the verifier to hold state until execution closes.

If it would help the working group, I can post the JSON Schema for both artifact types as a separate gist. The signature surface uses RFC 8785 JCS for canonicalization, byte-validated against the AgentGraph CTEF v0.3.1 fixtures (4/4 pass) — fixture run posted under #1786.

[Poke-nushi]

Thanks — this is exactly the kind of concrete implementation detail I was hoping to see.

The separation between an inline admission receipt at policy-evaluation time and a dereferenceable post-execution receipt makes sense to me. It also clarifies a gap in the current VATE draft: I have been using “execution receipt” somewhat broadly, but this discussion suggests that the receipt phase should be explicit.

One update I am considering is to model receipts along these lines:

• a verifier-signed admission / decision receipt, emitted before execution
• a post-execution receipt, emitted or stored after the action completes
• an explicit linkage field such as admission_receipt_ref or attestation_id
• explicit receipt_phase: "admission" | "post_execution" or similar
• decision, attenuations[], policy_id, and policy_version on the admission receipt

This also seems consistent with the broader direction of adjacent work. ANS / Web Bot Auth can help establish who the agent is and bind requests cryptographically. ACP / SPT-style commerce flows can carry payment or checkout authority. A2A can carry task flow and references. But a relying party may still need a verifier-side layer that records why a risky action was admitted, narrowed, or denied, and then links that admission decision to post-execution evidence.

So my current read is:

• A2A should probably not carry the full trust envelope or receipt bodies.
• A2A may still benefit from a minimal metadata/reference convention for verifier-side artifacts.
• The full admission and post-execution receipts should live in an adjacent verifier / receipt layer.

Yes, a JSON Schema gist for both artifact types would be very useful. I would also be interested in whether you treat attestation_id as the primary correlation key across the whole verifier/audit path, or only as the admission-to-execution linkage key.

[Poke-nushi]

Thanks again for the concrete feedback here.

Quick update: I incorporated the receipt-boundary points from this thread into the draft.

The current main branch now:

• splits receipts into admission and post_execution phases
• makes the HTTP verifier demo emit a verifier-signed admission receipt
• adds policy_version to verifier policy, reports, and receipts
• adds structured attenuations[] for narrowed decisions
• clarifies that A2A should carry task / invocation flow and may carry references to verifier-side artifacts, rather than full permit / receipt bodies

The intended boundary is still that full permit / receipt semantics live in an adjacent verifier / receipt layer, while A2A may only need a minimal reference convention.

Update:
Poke-nushi/Verifiable-Agent-Trust-Envelope@701ac8a

[Poke-nushi]

Small update after narrowing the draft based on the discussion here and adjacent protocol review.

I updated the VATE draft to avoid proposing an A2A core feature. The current direction is an adjacent profile:

• VATE AL2 Verifier Admission Profile v0.2
• reference-only A2A metadata binding
• split receipts into admission_receipt and post_execution_receipt
• full permit / evidence / attenuation / receipt bodies stay outside A2A core
• OAuth, OID4VP, VC/DID, Web Bot Auth, AP2, x402, ACP, and delegated payment tokens are treated as evidence inputs, not protocols VATE replaces

Updated draft links:

• Profile: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/profiles/vate-al2-verifier-admission-profile-v0.2.md
• A2A metadata binding: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/a2a-metadata-binding-v0.2.md
• Receipt model: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/receipt-model-v0.2.md

The main question is now narrower:

Is this kind of metadata-only, by-reference admission / receipt binding compatible with A2A’s extension model, or should it remain entirely as an adjacent VATE profile outside A2A governance?

I am not proposing A2A core state-machine changes here.

[Poke-nushi]

Closing the loop on the v0.2 direction from this thread.

Based on the receipt-boundary and attenuation feedback above, I published a fixed v0.2.0 pre-release review snapshot:

• Release: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/releases/tag/v0.2.0
• Version DOI: https://doi.org/10.5281/zenodo.20043166
• A2A maintainer brief: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/a2a-maintainer-brief-v0.2.md
• A2A metadata binding draft: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/blob/main/docs/a2a-metadata-binding-v0.2.md
• Mini conformance corpus: https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope/tree/main/conformance/al2-vate-v0.2

The current proposal is intentionally narrower than the original question:

• A2A carries task flow and optional digest-bound references.
• VATE defines the adjacent verifier-side admission profile.
• Full permit, evidence, attenuation, and receipt bodies stay outside A2A core.
• Admission decisions stay limited to allow / attenuate / deny.
• Post-execution receipts link back to the admitted effective request.

The main review question is still:

Is this metadata-only, by-reference admission / receipt binding compatible with A2A's extension model, or should it remain entirely as an adjacent VATE profile outside A2A governance?

@srotzin @lawcontinue — tagging you only because your earlier comments directly shaped the receipt split and machine-readable attenuation parts. No pressure, but if this looks like the right boundary, or if it still puts too much into A2A-adjacent metadata, I would appreciate the critique.

[lawcontinue]

The metadata-only boundary is the right call. We run a multi-agent governance layer adjacent to the agent protocol — same trade-off. The thing that sealed it: governance rules change way faster than the protocol, so baking governance semantics into the message schema means every policy update becomes a breaking change.

One suggestion on the digest scope: consider carrying two digests — one for the admission decision (required) and one for the policy snapshot that produced it (optional). We started with decision-only and found we couldn't reconstruct why a decision was made without a separate policy log. The policy snapshot digest is optional because not every verifier needs audit traceability, but when you do need it, it's painful to retrofit.

[Poke-nushi]

@lawcontinue That makes sense, and I think it fits the current v0.2 boundary cleanly.

My read is:

• the required decision digest maps to the admission receipt / decision artifact reference
• an optional policy snapshot digest should not become an A2A core field
• but it is useful as an optional verifier-profile field for audit-heavy deployments

I agree with the concern that policy semantics change faster than the transport protocol. That is exactly why I am trying to keep A2A at the reference-carrying layer and leave policy interpretation inside the adjacent verifier profile.

I will treat optional policy snapshot digesting as a candidate v0.2.x refinement, likely inside the admission receipt policy block and/or as an optional referenced artifact in the VATE metadata binding.

[Poke-nushi]

Small update, not urgent.

Since my last comment, VATE has moved beyond the v0.2 boundary described above and is now at v0.3.1. The direction has stayed the same but narrowed further: VATE is intended as an adjacent verifier-side profile, with A2A carrying only stable references or metadata where appropriate.

The remaining question for this issue is mostly about placement, not adoption:

Should this verifier-side admission / receipt boundary be considered:

1. adjacent-spec / profile territory,
2. an Agent Card or A2A profile-extension convention, or
3. out of scope for A2A entirely?

If this issue is not the right venue for that placement question, I am happy to move the summary to Discussions and close this issue.