The evaluation package runs in your environment and comes only with the paid design partnership. The design partnership costs USD 40,000 for three months and covers AAES Operate and AAES Govern, starting after signing and onboarding. If you continue, the fee is credited in full against the first-year subscription. A scoped evaluation tests what AAES Govern 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
Choose one workflow, such as an agent requesting a payment or sending a customer message. Identify the credentials it uses, who can approve it, and which actions must be blocked. 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.
Proposed design-partner outputs
Subject to the agreed scope and a signed agreement, the proposed package covers one workflow, who controls its credentials, and the checks it must pass. Agree the outputs before the evaluation:
- The configured tool registry and policy, plus an inventory of the deployment.
- Records of requests that should be denied, and a comparison of recorded outcomes with provider-effect evidence.
- An offline evidence pack, with its population, exclusions, verification tooling, and review procedure.
- Operator findings and a statement of the configuration AAES supports.
There are no design partners or customer evaluation results yet. These are proposed outputs, not evidence that a customer deployment has passed.
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 Govern governs registered tool calls and actions. Application payloads may contain prompt, completion, or personal data. Enforcement requires control of the agent's credential path. Other activity is visible only where telemetry is supplied; observation cannot block it.
Environment and test boundaries
Use synthetic data and vault-backed credentials. Operate and Govern can run on your infrastructure or be hosted by AAES. Agree the deployment and operating responsibilities before evaluation. No SOC 2 report exists today. No production adoption is claimed.
Govern vendor 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.
Evaluation binaries are supplied through the design partnership. Agree environment and access requirements when scoping the evaluation.
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
Download the reviewer worksheet (Markdown) to record request-binding, expiry, self-approval, spending, and bypass checks, with a place for evidence and retest outcomes. For questions that can be reused with any implementation, see the public control evaluation kit and procurement checklist.
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 Govern are controlled. |
| Capability outside permitted scope | A denied request would show that the tested out-of-scope capability was not authorized through AAES Govern. | 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 Govern. | It would not establish a cap on vendor spending outside AAES Govern. |
| Decision journal unavailable | A denial with no new grant or brokered execution 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. Journal failure alone does not revoke outstanding grants; their issued lifetimes are bounded by 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 Govern. |
| 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 Govern | A demonstrated bypass would identify an uncontrolled credential path. Unreported activity outside AAES Govern is not visible to it. | An absent AAES Govern record would not prove that no action occurred. This test would not establish enforcement over the bypass path. |
Export verification checks projected entry fields and record-hash commitments. Checking stored authorization, scope and approver fields also requires the records sidecar and its separate binding check; see Verification. 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, Apache-2.0 aaesverify release binaries, and a tamper demonstration) is on the verification page; it demonstrates record integrity checks, not a client evaluation result. Using the public aaesverify release under Apache-2.0 requires no separate evaluation authorization. The proprietary platform and operator tools have separate software terms. 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.
Evaluating AAES Operate
The tests and exit conditions above are AAES Govern criteria. AAES Operate, the operating layer, has private-work permissions, operational reviews and recorded-spend limits. These controls are independent of Govern policy and evidence, so its standalone evaluation uses separate criteria. Operate acceptance outputs are agreed in the design partnership and cover:
- Deployment in your environment.
- Configured model-provider or agent-runtime connections.
- Agents and roles configured.
- Workspace isolation, project membership, task assignment and access refusals.
- Initially paused schedules that an owner or administrator enables; separately reviewed Govern task orders for combined execution.
- Failure recovery.
- Cost reporting boundaries.
- Deployment responsibilities: what AAES supplies and what your team operates.
- Agreed support scope.
A design partnership that evaluates only AAES Operate delivers these outputs on the same terms. The design partnership costs USD 40,000 for three months and covers AAES Operate and AAES Govern, starting after signing and onboarding. If you continue, the fee is credited in full against the first-year subscription.
When you use both, the Claude and Codex agents in Operate send their AI model calls and tool calls through Govern. Other connected agents (HTTP agents) send their tool calls through Govern, and their model calls too once an administrator connects them. Govern checks only what is sent through it.
Bring one workflow and the control question your reviewer needs to answer.