Audit offline.
Plan locally.

How to get the CLIs

Request an evaluation. We send a package with aaesctl andaaescp, plus release-verification public keys and setup instructions. Supported platform packages are supplied by request under their software license or written evaluation authorization. The separate Apache-2.0 aaesverify release is available on the verification page. Any supplied test credentials or keypairs are identified as synthetic and must not be used for production; deployment signing keys are generated under your control (aaesctl keygen). A deployment bundle includes the same operator tools. Remaining setup notes ship with the package.

Start with the audit export

The public Apache-2.0 aaesverify v0.2.0 source and release binaries verify current aaes.export/v2 exports, including the public sample.

Verify

Verify the export against its public key, using trust material you hold or authenticate separately. A key supplied only alongside an export does not establish provenance by itself. Verification checks the exported sealed bytes, signatures, and chain links; it does not prove the truth of recorded claims, completeness of capture, policy correctness, enforcement effectiveness, or regulatory compliance.

aaesverify --export <export.jsonl> --pubkey <key.pub>

This checks record integrity. To require independent attestation, supply separately obtained witness keys or timestamp trust roots and add --require-independent. Neither an external witness nor a timestamp authority is connected in the default deployment.

aaesverify --export <export.jsonl> --pubkey <key.pub> \
  --witness-trust <trusted-witnesses.json> --require-independent

The witness-trust file maps trusted witness IDs to their public keys obtained separately from the export. With --require-independent, verification additionally requires supported witness or timestamp evidence validated against that separately obtained trust material. The evidence concerns the signed head within the witness or timestamp service's scope; it does not independently verify the underlying actions.

For an export made before its first anchor interval, the current verifier accepts a signed head.pre_anchor commitment. An older or rotated-key export with only an unsigned header flag requires a deliberate --allow-pre-anchor opt-in. That option accepts the stated absence of anchors; it does not add independent attestation.

The following proof and inspection commands belong to the separately licensed aaesctl operator CLI.

Bind the stored records to the export

The public aaesverify CLI checks the export's hashes, signatures, and the fields included in the export. The evidence pack also contains a companion file (aaes.records/v1) with the stored authorization, scope, and approver fields. To check that these records match the hashes in the export, use the separately licensed operator tool:

aaesctl evidence verify --pack <pack-directory> --pubkey <key.pub>

This checks that each companion record matches its record_hash, as well as verifying the export. It does not prove that an event happened or that an approval was correct.

Prove

Produce the verifier's proof material for sequence 42 in this export. The output concerns the record's cryptographic relationship to the exported structure; it is not proof that the recorded action occurred, succeeded, or complied with law. Verify the resulting proof against the appropriate authenticated trust material using the release's documented procedure.

aaesctl prove --export <export.jsonl> --seq 42

Inspect

Inspect the export offline.

aaesctl inspect --export <export.jsonl>

Replace <export.jsonl> and <key.pub>with the files from your evaluation install.

Operator command groups

Use aaesctl for operator workflows. The table is a command index, not a set of complete invocations. A pipe separates available subcommands.

Coverage is an AAES-defined accounting measure over the configured and captured population described by the report. It is not a measure of all enterprise agent activity, proof that bypasses are absent, or an assessment of control effectiveness or compliance. Reports state their population, the denominator each percentage is computed over, the exclusions, and the observation or enforcement rules.

Inventory and adapter checks in an evaluation use local or synthetic vendor-format sources. A live vendor tenant is a design partnership.

aaescp: a local planner

aaescp never calls a cluster or the network. Its tenant commands and planning operate locally with a registry file. An aaescp plan is a local planning result.

Inspect the local tenant registry

aaescp tenant list --registry <registry.json>

The tenant command group supports add, list,show, activate, suspend, andoffboard, with --registry <registry.json>.

Plan for a tenant

aaescp plan --registry <registry.json> --tenant acme

Here, --tenant acme selects a tenant for local planning. This is distinct from daemon API authentication, where the caller's bearer credential resolves the tenant.

Multi-call binary

Both CLIs are also available through aaes. Put the CLI name before its command.

aaes aaesctl inspect --export <export.jsonl>
aaes aaescp plan --registry <registry.json> --tenant acme

Integrating an agent?

Use the daemon API,MCP facade, orSDKs for agent integration. Remaining integration notes ship with the evaluation package.

Request an evaluation, return to the developer overview, or contact hello@aaes.ai.