Agent Assurance Case

A portable, signed, audit-oriented evidence object for agentic AI release assurance (draft).

DOI: 10.5281/zenodo.20435608 · Release: v0.2-candidate.8 · Release fingerprints · Runtime dependency SBOM · Runtime dependency lock

Agent Assurance Case (AAC) is a draft specification and reference verifier for one release-critical question:

Can this agentic AI workflow be released, and can an auditor verify the evidence offline?

An AAC is a JSON object that binds inventory, detector coverage, findings, policy decisions, release conditions, compliance evidence candidates, a deterministic verdict, and an Ed25519 signature. A verifier recomputes the verdict without network calls, without an LLM, and without trusting the issuer's declared result.

Why It Exists

Agentic systems are assembled from workflows, tools, skills, prompts, memory stores, models, datasets, credentials, policies, and runtime environments. Existing standards cover important adjacent layers: SBOMs and AI BOMs enumerate components, provenance frameworks describe how artifacts were built, and governance frameworks describe organizational obligations.

AAC fills the release-decision gap: a small, portable assurance record that says what was checked, what failed, what is held, what passed, who signed it, and whether the evidence still verifies.

AAC is not a legal compliance certification. It is a signed evidence object that can support release review, audit preparation, and independent verification.

Read OVERVIEW.md first for the one-page model and trust boundary. Read THREAT_MODEL.md, LIMITATIONS.md, REVIEW_GUIDE.md, IMPLEMENTATION_GUIDE.md, RELEASE_FINGERPRINTS.md, SECURITY_POSTURE.md, security-insights.yml, and repository-posture.json before relying on AAC in a release process.

Quick Start

Verify the bundled examples with the demo key:

python3 -m pip install -r verifier/requirements.txt
python3 verifier/verify.py examples/pass-with-coverage.json --allow-demo-key
python3 verifier/verify.py examples/skill-poisoning-hold.json --allow-demo-key
python3 verifier/verify.py examples/critical-exfiltration-fail.json --allow-demo-key

Expected final line for each command:

VERIFIED

--allow-demo-key is only for the bundled examples. It is not a production trust mode. The demo public key is published at keys/demo-issuer-v0.2.pub so reviewers can inspect the exact key used by the examples.

Verify a production case with an issuer key:

python3 verifier/verify.py case.json --public-key issuer.pub

Run the conformance tests:

python3 -m pip install -r verifier/requirements-dev.txt
python3 -m pytest tests/ -q

Run the publication gate:

./VERIFY-PUBLICATION-READY.sh

Verify the published release fingerprint from current main:

python3 scripts/verify_release_fingerprints.py

That command checks the immutable release tag and commit, the signed tag, the publication gate, conformance vectors, bundled examples, public release asset digests, checksum files, and GitHub artifact attestations for the published assets.

What The Verifier Checks

• JSON Schema conformance with format checks enabled.
• Duplicate JSON object keys, NaN, Infinity, floats, and unsafe integers are rejected.
• All timestamps must be UTC RFC 3339 strings ending in Z.
• evidence.content_hash is recomputed over the signed payload.
• evidence.signature is verified with Ed25519.
• Canonicalization behavior is pinned by published byte-level test vectors.
• Canonicalization implements a constrained subset of RFC 8785 (JCS): floats, out-of-safe-range integers, and lone UTF-16 surrogate code points are rejected rather than encoded. The Ed25519-JCS-SHA256-v1 / RFC8785-JCS identifiers denote the canonicalization family used, not full RFC 8785 numeric coverage. See LIMITATIONS.md.
• Sign/verify behavior is pinned by a published golden vector.
• Unsupported profiles return NOT VERIFIED.
• PASS/HOLD/FAIL is recomputed deterministically from the case contents.
• A verifier never silently skips signature verification.

Repository Layout

.
├── README.md
├── OVERVIEW.md
├── SPEC.md
├── THREAT_MODEL.md
├── LIMITATIONS.md
├── REVIEW_GUIDE.md
├── IMPLEMENTATION_GUIDE.md
├── RELEASE_FINGERPRINTS.md
├── SECURITY_POSTURE.md
├── EXTERNAL_REVIEW_LEDGER.md
├── CITATION.cff
├── CHANGELOG.md
├── PUBLICATION.md
├── assets/
│   └── aac-logo.svg
├── keys/
│   └── demo-issuer-v0.2.pub
├── schemas/
│   └── agent-assurance-case-v0.2.schema.json
├── scripts/
│   └── verify_release_fingerprints.py
├── sbom/
│   └── runtime-requirements.cdx.json
├── profiles/
│   ├── aac.core.md
│   ├── runwright.skills.release.md
│   └── runwright.mcp.release.md
├── examples/
│   ├── pass-with-coverage.json
│   ├── skill-poisoning-hold.json
│   └── critical-exfiltration-fail.json
├── test-vectors/
│   ├── canonicalization-v0.2.json
│   └── sign-verify-v0.2.json
├── verifier/
│   ├── verify.py
│   ├── requirements.txt
│   ├── requirements.lock.txt
│   └── requirements-dev.txt
└── tests/
    └── test_verifier.py

Profiles

The schema defines shape. A profile defines the evidence bar.

aac.core is the portable baseline. It is the part intended to stand independently of any one product, vendor, or implementation.

runwright.skills.release and runwright.mcp.release are vendor profiles included as reference examples. They build on aac.core; they do not define AAC itself and they may not relax the core rules. Other organizations can define their own profiles for their own assurance surfaces.

This separation is deliberate: AAC can be cited, implemented, archived, and discussed as a standalone assurance format even if Runwright evolves separately or is built by someone else.

What This Is / What This Is Not

For a one-page statement of scope, claims, and the boundary between what is self-verified and what has been independently reviewed, read VALIDATION_BOUNDARY.md. In short: AAC is a draft specification, a deterministic reference verifier, and signed examples; it is self-verified and not yet independently reviewed; it is not a certification, not a guarantee that any detector finds every defect, and not an employer-endorsed product.

Status

Current draft: v0.2-candidate.8.

The citable artifact is the signed, DOI-archived release tag v0.2-candidate.8, not the tip of main. main may contain unreleased hardening that is not part of the archived release; cite or audit the tagged commit unless you are deliberately reviewing in-progress work. The next synchronized release is cut per PUBLICATION.md.

The draft schema identifier is pinned to the candidate tag:

https://raw.githubusercontent.com/jlov7/agent-assurance-case/v0.2-candidate.8/schemas/agent-assurance-case-v0.2.schema.json

This draft supersedes an unpublished v0.1 design that had trust-critical defects around signature verification and evidence metadata binding. Those bug classes now have regression tests.

Do not claim AAC v1.0 conformance yet. This repository is open for implementation feedback on:

• verdict semantics;
• evidence binding and canonicalization;
• profile boundaries;
• privacy posture for external evidence artifacts;
• compatibility with audit and release-review workflows.

Current public review thread: RFC: external review for AAC v0.2-candidate.8. Current external review status: no accepted independent review yet; see EXTERNAL_REVIEW_LEDGER.md. Reviewers can start with the 10-minute and 30-minute recipes in REVIEW_GUIDE.md. Ledger candidates can use the machine-checkable review-report-template.json described in REVIEW_GUIDE.md. Independent verifier/parser authors can use the implementation report issue form.

Standards Alignment

AAC is designed to sit beside, not replace:

• CycloneDX ML-BOM and SPDX AI profiles for component inventory;
• OpenTelemetry GenAI conventions for runtime evidence;
• Sigstore, in-toto, and SLSA for provenance;
• NIST AI RMF, ISO/IEC 42001, and EU AI Act documentation workflows;
• W3C Verifiable Credentials for future portability wrappers.

Citation

This repository includes CITATION.cff and codemeta.json so GitHub, archives, and software metadata indexers can generate citations and discovery metadata.

The v0.2-candidate.8 release is archived at 10.5281/zenodo.20435608. The superseded v0.2-candidate.7 archive remains available at 10.5281/zenodo.20379393, and the superseded v0.2-candidate.6 archive remains available at 10.5281/zenodo.20345018. The concept DOI 10.5281/zenodo.20159773 always resolves to the latest version. To list the work on an ORCID record, add the final version DOI as a work item through ORCID. See PUBLICATION.md for the release checklist.

Contributing

Issues and pull requests are welcome while the draft is under review. Please keep proposals scoped, include a concrete example, and explain how the change affects deterministic verification. For broad external review, use the current AAC v0.2-candidate.8 RFC thread, start from the review recipes, or submit a structured review report through the external review issue form.

Specification text, profiles, examples, and documentation are licensed under CC BY 4.0. Code, schemas, keys, tests, and CI are licensed under Apache 2.0.

Security-sensitive reports should follow SECURITY.md.

Threat model assumptions are summarized in THREAT_MODEL.md.

Independence Notice

This is personal, independent work by Jason Mark Lovell. It is not authored, sponsored, endorsed, or reviewed by, and does not represent the views of, any employer, client, or affiliated organization.