Verifiable Agent Trust Envelope v0.3.1 - Credibility and Reviewability Patch Draft

Verifiable Agent Trust Envelope v0.3.1 - Credibility and Reviewability Patch Draft

v0.3.1 is a credibility and reviewability patch for the current VATE AL2 verifier admission discussion draft.

This pre-release supersedes the archived v0.3.0 review snapshot for current main-branch review purposes. It does not mutate the v0.3.0 GitHub release or Zenodo archive artifacts.

v0.3.1 does not broaden VATE beyond the VATE-AL2-Verifier-Admission-v0.3 discussion-draft boundary. It remains a review aid for verifier-side admission, attenuation, receipt, external SUT comparison, and report-bundle integrity semantics.

Summary

The main change in v0.3.1 is that canonical AL2 attenuation and receipt review surfaces are now easier to inspect and harder to misread.

This release includes:

• VATE-AL2-Verifier-Admission-v0.3
• a 66-case AL2 v0.3 draft conformance corpus
• canonical emitted AL2 attenuation.effective_constraints names for admission receipts
• fail-closed attenuation fixtures for legacy emitted aliases and malformed attenuation forms
• stricter admission receipt schema coverage for attenuation.changes
• stricter admission receipt schema coverage for supported attenuation.mode values
• a constraints-only app-effect-0.2 attenuation effect shape for status/input effects
• a receipt audit walkthrough for following digest-bound admission, post-execution, policy snapshot, conformance report, implementation report, and report-bundle references
• README and A2A review package links to the new audit walkthrough

What Changed

v0.3.1 keeps the existing AL2 verifier-admission boundary from v0.3.0 and tightens reviewability around attenuation.

Admission receipts now describe emitted attenuation through a single attenuation object. The schema requires non-empty structured attenuation.changes entries, and attenuation.mode is limited to:

• narrow
• require_new_permit
• deny_if_not_accepted

The canonical emitted attenuation.effective_constraints fields are:

• max_amount
• tool_allowlist
• target_resource
• approval
• expires_at

Legacy or input-side aliases such as max_amount_usd, bare resource, and string-valued approval are not canonical emitted AL2 receipt fields. The reference runner fails closed when those forms appear in emitted attenuation constraints.

schemas/attenuation-effect.schema.json now keeps the status/input attenuation effect shape constraints-only. Admission receipts use attenuation.effective_constraints; status-layer or legacy candidate objects remain input signals that must be normalized before receipt emission.

Added

• docs/receipt-audit-walkthrough-v0.3.1.md
• conformance/al2-vate-v0.3/cases/deny-attenuation-approval-string.json
• conformance/al2-vate-v0.3/cases/deny-attenuation-legacy-effective-constraints.json
• conformance/al2-vate-v0.3/cases/deny-attenuation-malformed-money.json
• corresponding attenuation fixtures and denial receipt examples
• strict schema negative cases for unsupported attenuation mode, empty changes, incomplete changes, unsafe change roots, legacy effective constraint aliases, string-valued approval, malformed money, and admission-only effective_constraints on attenuation effect objects

What Implementers Can Test

Implementers can run their verifier against the v0.3 corpus, emit a SUT result file matching the repository schemas, and compare that result with the reference runner.

Minimal comparison command:

python3 scripts/vate_conformance.py compare \
  --corpus-root conformance/al2-vate-v0.3 \
  --sut-results examples/conformance/sut-results-pass.example.json \
  --report /tmp/vate-v0.3.1-compare-report.json \
  --implementation-report /tmp/vate-v0.3.1-implementation-report.json

Passing the comparison means one SUT result matched one corpus snapshot under the repository comparison rules.

It does not grant a compatibility badge, certification, endorsement, production approval, or general compatibility claim.

Release Boundary

This is:

• a discussion draft
• a conformance review aid
• an interoperability review aid
• an A2A-shaped metadata review package
• a reference runner and package-private helper set
• a receipt and report-bundle reviewability patch

This is not:

• production-ready
• certified or certification-ready
• an official A2A extension
• endorsed by A2A
• an SDK or A2A middleware package
• a production JOSE / JCS / PKI verifier
• a complete security review
• a general compatibility proof
• a certification, endorsement, badge, or production-readiness statement

Not Production Ready

This patch does not provide:

• production JOSE / JCS / PKI verification
• an official A2A extension
• AP2, AgentKit, AgentBook, World ID, or other adjacent-protocol profile expansion
• an attenuation primitive registry
• a broad policy language or general constraint grammar
• independent multi-implementation certification
• production approval or endorsement

Verification

The final local verification gate was run on the release content tree for:

3bdbb8163e2ca0c2d958e3ef35d66ccd8105399c

Gate summary:

• working tree clean
• corpus case count: 66
• Python compile checks: pass
• repository sanity check: pass
• strict schema validation: pass
• v0.3 corpus run: 66 passed / 0 failed
• SUT compare: 66 passed / 0 failed
• implementation report generation: 66 passed / 0 failed
• corpus index regeneration diff: no changes
• bundle verification: 23 passed / 0 failed
• deterministic npm install: pass
• TypeScript check: pass
• TypeScript tests: 6 test files / 16 tests passed
• npm audit, moderate or higher: 0 vulnerabilities
• final external release-boundary review: approve, no P0/P1/P2 findings

Citation and DOI

At GitHub release publication time, the Zenodo archive DOI for v0.3.1 may not yet be available.

Until the Zenodo record exists, cite the repository URL and exact release target commit:

3bdbb8163e2ca0c2d958e3ef35d66ccd8105399c

After Zenodo ingests this GitHub release, cite the Zenodo version DOI for the exact v0.3.1 archive when reproducibility matters.

For references to the evolving project across all archived versions, use the Zenodo all-version concept DOI:

10.5281/zenodo.19839768

A separate citation metadata patch may update CITATION.cff and README citation text after the v0.3.1 archive DOI is available.

Verifiable Agent Trust Envelope v0.3.0 - AL2 Evidence Reference Hardening Draft

Verifiable Agent Trust Envelope v0.3.0 - AL2 Evidence Reference Hardening Draft

v0.3.0 is an AL2 verifier admission hardening discussion-draft pre-release.

This pre-release supersedes the archived v0.2.0 review snapshot for current main-branch review purposes. It does not mutate the v0.2.0 GitHub release or Zenodo archive artifacts.

Summary

The main machine-readable change in v0.3.0 is that AL2 admission requests now require at least one digest-addressed evidence_refs entry.

An empty evidence_refs array is schema-invalid and should fail closed with SCHEMA_INVALID and FAIL_CLOSED.

This release includes:

• VATE-AL2-Verifier-Admission-v0.3
• a 63-case AL2 v0.3 draft conformance corpus
• a fail-closed conformance case for empty evidence_refs
• v0.3 A2A-shaped metadata review documents
• v0.3 receipt, metadata, report, and SUT result schema alignment
• reference runner support for the v0.3 corpus
• package-private TypeScript helper packages

What implementers can test

Implementers can run their verifier against the v0.3 corpus, emit a SUT result file matching the repository schemas, and compare that result with the reference runner.

Passing the comparison means one SUT result matched one corpus snapshot under the repository comparison rules.

It does not grant a compatibility badge, certification, endorsement, production approval, or general compatibility claim.

Release boundary

This is:

• a discussion draft
• a conformance review aid
• an A2A-shaped metadata review package
• a reference runner and package-private helper set

This is not:

• production-ready
• certified or certification-ready
• an official A2A extension
• endorsed by A2A
• an SDK or A2A middleware package
• a production JOSE / PKI / JCS verifier
• a general compatibility proof

Verification

The full pre-release gate was run on:

830f15a5532690f63b158ad1efcab7015f778f41

Gate summary:

• working tree clean
• corpus case count: 63
• Python compile checks: pass
• repository sanity check: pass
• strict schema validation: pass
• v0.3 corpus run: 63 passed / 0 failed
• SUT compare: 63 passed / 0 failed
• implementation report generation: 63 passed / 0 failed
• bundle verification: 23 passed / 0 failed
• TypeScript check: pass
• TypeScript tests: 6 test files / 16 tests passed
• npm audit, moderate or higher: 0 vulnerabilities
• final external release-boundary review: GO, no P1 blockers

Citation and DOI

Before the v0.3.0 archive DOI exists, CITATION.cff remains pointed at the archived v0.2.0 snapshot.

For unarchived v0.3.0 work, cite the repository URL and exact commit SHA:

830f15a5532690f63b158ad1efcab7015f778f41

A separate citation patch should update CITATION.cff and README citation text after the v0.3.0 archive DOI is available.

Verifiable Agent Trust Envelope v0.2.0 - AL2 Verifier Admission Profile Draft

Verifiable Agent Trust Envelope v0.2.0

AL2 Verifier Admission Profile Draft

v0.2.0 DOI: https://doi.org/10.5281/zenodo.20043166
Concept DOI: https://doi.org/10.5281/zenodo.19839768

This is a pre-release discussion draft, not a production-ready protocol release.

v0.2.0 freezes a review snapshot for the AL2 verifier-side admission boundary: how a relying party can evaluate a risky external agent action before execution, decide allow / attenuate / deny, and bind that decision to later receipt evidence.

What Changed

This release adds a narrower v0.2 profile around verifier-side admission for AL2 external digital actions.

It keeps VATE adjacent to A2A, MCP, OAuth, VC, DID, OID4VP, Web Bot Auth, AP2, x402, ACP, and delegated payment-token systems. Those systems remain evidence or transport layers. VATE defines how a relying party evaluates those inputs before execution and records the decision.

Added

• docs/profiles/vate-al2-verifier-admission-profile-v0.2.md
• docs/a2a-metadata-binding-v0.2.md
• docs/receipt-model-v0.2.md
• docs/v0.2-in-5-minutes.md
• docs/a2a-maintainer-brief-v0.2.md
• conformance/al2-vate-v0.2/
• v0.2 schemas for admission requests, artifact references, evidence references, A2A metadata, admission receipts, and post-execution receipts
• v0.2 examples for A2A metadata, admission allow, admission attenuate, admission deny, and post-execution success
• mini conformance cases for valid admission, max-amount attenuation, expired permit denial, audience mismatch denial, and post-execution receipt linkage

What A2A Maintainers Can Evaluate

This release is designed to make one narrow question reviewable:

Can A2A carry digest-bound references to verifier-side admission and receipt artifacts without expanding A2A core?

Relevant files:

• docs/a2a-maintainer-brief-v0.2.md
• docs/a2a-metadata-binding-v0.2.md
• schemas/a2a-vate-metadata.schema.json
• examples/a2a/metadata-admission-issued.json
• conformance/al2-vate-v0.2/cases/attenuate-max-amount.json

Not Production Ready

This release does not provide:

• final proof packaging requirements
• a multi-implementation certification suite
• a normative A2A extension accepted by A2A governance
• production security review
• stable persistent namespace assignment

Main Feedback Question

Is a 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?

Verification

Validated before release:

python3 scripts/check_repo.py
python3 scripts/check_repo_strict.py

Verifiable Agent Trust Envelope v0.1.0 — Discussion Draft

This release publishes the first public discussion draft of Verifiable Agent Trust Envelope.

It is a narrow draft for one specific boundary:

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 repository makes that boundary concrete through an HTTP verifier demo that evaluates:

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

and returns:

allow / attenuate / deny

with a machine-readable receipt.

What This Draft Adds

• a composite artifact model across identity, runtime proof, task-scoped permit, status, and receipt
• explicit verifier-side ordering for risky external actions
• payload schemas and examples
• an educational reference demo
• a machine-readable AL2 HTTP conformance corpus

What This Draft Does Not Replace

This draft is not trying to replace:

• A2A
• MCP
• OAuth / OpenID
• VC / JWT
• workload identity systems
• agent platforms or control planes

It is intended to compose with those layers rather than supersede them.

Close Adjacent Work

This repo should not be read as if adjacent public work does not exist.
The closest comparisons currently include:

• Agent Permission Protocol (Crittora APP)
• Open Agent Passport / APort
• Agent Passport System (APS / AEOESS)
• AgentROA
• Agent Auth / AIP

Direct comparison note:

• docs/close-adjacent-work-2026-04.md

Feedback Requested

The most useful critique for this draft is currently:

• is the verifier-side boundary clear enough
• is the status -> identity -> runtime -> permit -> policy ordering sound
• are permit, status, attenuation, and receipt semantics coherent together
• is the difference from close adjacent work stated honestly and precisely enough
• what should remain core versus move into profiles or extensions

Fast Reading Path

If you are new to the repo, start with:

1. README.md
2. docs/close-adjacent-work-2026-04.md
3. docs/use-cases.md
4. section 0 and section 1 of docs/verifiable-agent-trust-envelope-spec-v0.1.md
5. reference/http-verifier-demo/README.md

Current Status

• repository type: protocol discussion draft
• maturity: early draft
• language: English-first
• current battlefield: AL2 external digital write
• production readiness: no

This release is published to invite technical critique, not to claim a finished standard.