# AAES control and evidence review worksheet

Version: October 3, 2026. Prepared by AAES for reviewers to complete.

This is a blank evaluation aid. It reports no completed independent review, customer deployment, or certification. Record observations and gaps in your own words. Use `not run`, `observed`, `failed expectation`, or `inconclusive`; leave no unexecuted check marked as passed.

## 1. Identify the exercise

- Reviewer and affiliation:
- Date and environment:
- Exercise type: public synthetic sample / local vendor-format test / live provider-tenant evaluation
- Workflow, provider, and capability under review:
- AAES version or source revision:
- Verifier version or source revision and build method:
- Export filename and SHA-256:
- Public-key fingerprint and how the key was obtained:
- Credentials and routes included in scope:
- Known bypass paths or excluded systems:

Keep secrets and customer data out of any public copy. A public sample exercise can be performed with the materials below. Agent execution tests require an agreed evaluation environment and package; they cannot be established by inspecting the sample export alone.

## 2. Public materials

- [Product facts and current availability](https://aaes.ai/about.html)
- [Verification procedure and sample downloads](https://aaes.ai/library/verification.html)
- [Evidence export specification](https://aaes.ai/spec.html)
- [Public verifier source](https://github.com/aaes-ai/aaesverify)
- [Trust model](https://aaes.ai/library/trust-model.html)
- [Scoped evaluation method](https://aaes.ai/library/evaluation.html)
- [Capability matrix](https://aaes.ai/library/capability-matrix.html)

The public sample contains synthetic demonstration records. Its public key, binaries, and checksum manifest come from AAES-controlled distribution; matching them does not independently authenticate that distribution. Follow the sample page's execution precautions and build from source if your review requires it.

## 3. Public verification checks

Keep the command output, exit code, verifier revision, and file hashes for each check. Agree the expected behavior before running it.

| ID | Check | Expected observation | Actual result and evidence |
|---|---|---|---|
| V1 | Verify the unchanged sample with its supplied public key using the documented command. | `result: CONSISTENT` against that key. `result: PASS` requires an independent witness or an independent timestamp, which this sample does not have. The published aaesverify v0.2.0 binaries still print `result: PASS` for this witness-less check; retain that older wording as the integrity check, not as independent attestation. Retain the warnings about placeholder timestamps and zero independent witnesses. | Not run: |
| V2 | Run the documented `tamper-demo.sh`, which edits a copy of one record hash. | The unchanged export succeeds; the edited copy exits 1 with `chain: FAILED` and `merkle root: FAILED`. A download or permission error is inconclusive. | Not run: |
| V3 | After retaining the export, key, and verifier, repeat verification in an isolated evaluation environment without network access or a running AAES service. | Verification can complete from the retained local materials. Record how network isolation was established. | Not run: |
| V4 | Record the provenance of the key and any external witness or timestamp trust material. | The public sample supplies no independent witness evidence. A deployment's external attestation can be assessed only against separately obtained trust material. | Not run: |

The public verifier checks export projections and record-hash commitments. To assess stored scope or approver fields, obtain the records sidecar and use the separate operator pack-binding check (`aaesctl evidence verify --pack <dir> --pubkey <key.pub>`).

The tamper demonstration detects its specified edit. A valid signature does not prove complete history, truthful inputs, correct authorization decisions, successful provider execution, or absence of bypass. A party controlling the signing key can create a different internally consistent history. Do not generalize these checks into an audit or security certification.

## 4. Scoped agent-action tests

Run these only in an agreed, non-production evaluation with synthetic data and controlled downstream effects. Fix the intended authorization, request, policy, approval lifetime, and budget before each test. Capture the provider-side observation as well as the AAES response; a recorded dispatch is not evidence of successful execution.

| ID | Test | Expected control to evaluate | Actual result and evidence |
|---|---|---|---|
| A1 | Request a capability requiring human approval and withhold approval. | The tested action does not dispatch before valid approval. | Not run: |
| A2 | Approve a specific request, then alter its material parameters before submission. | The old approval cannot authorize the changed request; new approval is required. | Not run: |
| A3 | Submit after the approval expires. | The expired approval cannot authorize the tested action. Record the configured expiry and observed time. | Not run: |
| A4 | Have the requesting agent attempt to satisfy mandatory human approval. | Agent self-approval is rejected on the tested approval path. | Not run: |
| A5 | Request an out-of-scope capability or an amount exceeding the agreed ceiling. | The action is refused before dispatch on the controlled path. Record scope and spending rules separately. | Not run: |
| A6 | In the controlled test environment, make the required decision journal unavailable, then request a new decision. | No new grant or brokered execution is authorized. A journal-write failure can leave no journal row; retain the daemon response and provider-side observation. Previously issued grants may remain usable for up to 15 minutes. | Not run: |
| A7 | Inspect whether the agent can use alternative direct credentials or a route outside AAES. | Identify each bypass. AAES cannot block an uncontrolled path; an absent AAES record does not establish that no action happened. | Not run: |
| A8 | Compare a permitted request's AAES record with the downstream provider result. | Record actual provider outcome and discrepancies. A local vendor-format simulation does not establish live tenant compatibility. | Not run: |
| A9 | Cause an uncertain response or failed outcome-recording step after a controlled downstream effect, then reconcile the original intent. | A timeout or brokered 503 is not proof of non-effect. Retain the request and effect key; establish the provider outcome before a documented same-key repeat. A duplicate 409 alone does not prove success. | Not run: |
| A10 | Submit the same governed effect concurrently and submit separate effects near the agreed shared budget ceiling. | Check provider-side effect count and the ceiling across concurrent requests. Retain original effect identifiers; a single successful request does not establish concurrency safety. | Not run: |
| A11 | Restore the evaluation deployment from the agreed backup and exercise its recovery/rollback procedure. | Verify readiness, retained authority and exports against independently retained keys/checkpoints. Record any lost or uncertain work; recovery must not silently authorize a repeated effect. | Not run: |
| A12 | For each tested refusal, inspect the downstream system for the intended absence of effect. | No dispatch or protected change is observed on the controlled path within the agreed window. The AAES denial alone does not establish downstream non-effect or absence of a bypass. | Not run: |

## 5. Findings and disposition

For each finding, record:

- Test ID and narrowly stated observation:
- Evidence location and integrity hash:
- Environment and scope to which the result applies:
- Expected behavior and actual behavior:
- Severity or business consequence, if supported:
- Reproduction steps:
- Remediation owner and target date:
- Retest outcome:
- Remaining uncertainty:

## 6. Publication decision

- Which observations are independently reproduced?
- Which results depend on vendor-supplied information?
- Were any tests not run or inconclusive?
- Are all synthetic, local, and live-tenant results labeled accurately?
- Has the customer authorized disclosure of any customer-specific results?
- Are affiliations and any compensation disclosed?
- Does the conclusion stay within the tested scope?

A reviewer chooses their own conclusion, including unfavorable or inconclusive findings. AAES makes no request for a positive review. For factual corrections, use the contact details on the product-facts page and identify the affected claim and evidence.