A scoped evaluation tests what AAES can enforce and record for one agent workflow. It also identifies what remains outside that control boundary. This page is the control-evaluation scope and exit conditions. After you have the evaluation package, technical setup covers how to run it.
These pages describe the product. They are not a certification or a legal opinion.
What an evaluation is
Scope the evaluation around:
- One agent workflow.
- One controlled credential path.
- One approval chain with named approvers.
- One or two tool integrations.
- Agreed negative tests.
- An export-verification exercise.
- A closing control-gap review.
The deliverable is an evaluation report, not a certificate. Client-specific results are produced during the scoped evaluation, not supplied as evidence of a deployment that has already been validated.
AAES governs tool use and actions routed through it. It is not a model gateway: prompts and model completions are not on the brokered path. Enforcement requires control of the agent's credential path. Work that bypasses AAES is invisible. Observation is not enforcement.
Environment and test boundaries
Use synthetic data, client-hosted AAES, and vault-backed credentials. AAES is client-operated only. There is no AAES-hosted cell today. A hosted offering is not available. No SOC 2 report exists today. No production adoption is claimed.
Native adapters are tested against local servers speaking vendor API formats, not live vendor tenants. Label those exercises as local vendor-format tests in the report. Live tenant validation happens during a design partnership; local results must not be presented as client-tenant validation.
The core repository is private. Evaluation binaries are supplied through evaluation. Resolve environment and access details through the evaluation rather than assuming they are available as public downloads.
After you have the package, use technical setup and the OpenAPI document for how to run the evaluation. The current security posture and stated internal checks are described in Security.
Tests a reviewer should require
Agree the expected behavior and evidence before execution. The table describes how to interpret a result if observed. It does not report completed tests or outcomes.
| Intent | What a result would show | What it would not show |
|---|---|---|
| Agent attempts self-approval | A rejected attempt would show that the tested agent could not approve itself through the evaluated approval path. | It would not establish that every approver assignment is appropriate or that approvals outside AAES are controlled. |
| Capability outside permitted scope | A denied request would show that the tested out-of-scope capability was not authorized through AAES. | It would not show that the agent lacks access to the same capability through other credentials or routes. |
| Request exceeds budget ceiling | A refusal recorded before dispatch would show enforcement of the tested ceiling for spending routed through AAES. | It would not establish a cap on vendor spending outside AAES. |
| Decision journal unavailable | Denial with no new grant and no credential minted would show fail-closed behavior for the tested journal-write failure. If the journal cannot be written, there will not be a journal row for that denial. Confirm via the daemon response. | It would not show that previously issued grants were immediately revoked. Outstanding grants remain valid for up to 15 minutes. |
| Grant expired | Rejection of the expired grant would show that expiry was enforced on the tested path. | It would not establish expiry enforcement on untested paths or prevent use of credentials outside AAES. |
| Record modified before verification | A verification failure would show detection of the tested modification against the verification key used. | It would not prove the truth of recorded inputs, completeness of the action history, or independent attestation. |
| Workflow uses credentials outside AAES | A demonstrated bypass would identify an uncontrolled credential path. Work that bypasses AAES is invisible to it. | An absent AAES record would not prove that no action occurred. This test would not establish enforcement over the bypass path. |
A valid sealed record establishes integrity of recorded authorization, scope, named approver, and sealed bytes. It does not establish decision correctness, absence of omitted or bypassed actions, legal non-repudiation, or that a dispatched call achieved its intended outcome.
The default deployment has zero independent witnesses. Independent attestation requires a configured external witness or timestamp authority and trust material obtained separately from the export. See Verification for how to check an export.
What is public, and what is not
This evaluation scope is public. A public sample pack (a synthetic demonstration export, its public key, standalone verifier binaries, and a tamper demonstration) is on the verification page; it demonstrates record integrity checks, not a client evaluation result. Client-specific results stay within the evaluation and, when they include client context, under NDA.
As stated on Security, internal tests cover fail-closed behavior, named approval binding, budget ceilings, and tamper detection. Those checks do not establish production validation or independent certification.
An evaluation report records the scoped exercise and its gaps. It does not determine the client's legal obligations. AAES does not certify that a client has met a regulator's requirements.
What to send when contacting
- The workflow and intended tool actions.
- The credential owner and identity stack.
- The approval owner.
- Deployment constraints.
- The principal risk or audit question.
- Jurisdiction, if relevant.
- Whether a test tenant is available.
Do not send credentials or production data through the public form. Any additional information requirements should be resolved through the evaluation.
Exit conditions and unresolved gaps
Use the closing review to record whether each condition has been met. An unmet condition is a named gap, not an implied success.
- The workflow's credential path is identified, including known bypass routes.
- Approval and denial behavior match the agreed tests.
- The evidence is usable by the nominated reviewer.
- Adapter behavior is validated in the client's test tenant during the design partnership. If only local vendor-format tests were performed, record this condition as unresolved.
- Residual gaps have named owners.
Keep conclusions bounded to the tested workflow, environment, and paths. Reproducing a recorded decision is not reproducing model behavior or the external-world outcome.
Bring one workflow and the control question your reviewer needs to answer.
Related pages: Evaluation contact: https://aaes.ai/contact.html?ref=library-evaluation · Technical setup: https://aaes.ai/developers/evaluation.html · OpenAPI document: https://aaes.ai/developers/openapi.yaml · Verification: https://aaes.ai/library/verification.html · Security: https://aaes.ai/legal/security.html