AAES
Evaluate AAES →Request a demo

Evidence Library · Controls

Action controls

What AAES can enforce on a brokered path, the evidence a reviewer can inspect,and the remaining gaps.

Last reviewed:

AAES is a client-operated governance layer for enterprise AI agents. These six controls describe what AAES governs, where enforcement depends on the deployment, and what a reviewer can establish from the available evidence: named approval, permitted capabilities, scoped grants, budget ceilings, fail-closed journal writes, and sealed records.

These pages describe the product. They are not a certification or a legal opinion. Enforcement requires control of the agent's credential path. Work that bypasses AAES is invisible. Observation is not enforcement. Prompts and model completions are not on the brokered path.

Assurance claims and internal check descriptions are published on Security and assurance. How to check an export is described in Verification. Results from a client's test tenant are produced during a scoped evaluation. No production adoption is claimed.

Named approval

Question
Can an agent authorize its own work, and who must approve an irreversible action?
Control statement
Every registered agent has at least one accountable human manager. Approvers are named in AAES. An agent cannot approve itself. Actions classified as irreversible require approval by an authorized person. Policies can require approval for other actions too.
Enforcement point
The authorization decision for actions routed through AAES, before the action is permitted to proceed.
Preconditions
The agent must be registered with an accountable manager. Authorized approvers and applicable approval policies must be configured. AAES must control the credential path for the action.
Evidence available today
Records include actor, work, grant, and accountable manager attribution. Recorded authorization and named approver information can be checked within the sealed record. Security and assurance describes internal checks for named approval binding.
Known gap
A valid record does not establish that an action was correctly classified, that the underlying decision was correct, or that no action bypassed approval outside AAES.
Client responsibility
Name accountable managers and authorized approvers, establish action classifications and approval policies, and prevent alternate credential paths from bypassing the control.

Permitted capabilities

Question
Does an agent see only the capabilities it is permitted to use?
Control statement
Agents only see permitted capabilities in AAES.
Enforcement point
The capability view AAES presents to the agent. This boundary does not govern tools or credentials available outside AAES.
Preconditions
Permitted capabilities must be defined for the agent. The deployment must route governed tool use through AAES and control the associated credential path.
Evidence available today
Inspect the capabilities list and catalog the agent is shown. Agents discover permitted capabilities through AAES and can request additional access through the catalog. The evaluation is the source for deployment-specific demonstrations of capability visibility.
Known gap
A sealed action record does not, by itself, prove everything an agent could see or access. Tools available through a bypass remain outside this control.
Client responsibility
Define permitted capabilities, review access assignments, and identify tools or credentials that remain reachable outside AAES.

Scoped grants with TTL

Question
Is delegated authority limited to a task and a finite lifetime?
Control statement
Grants are task-scoped and have a time to live, or TTL.
Enforcement point
The AAES grant path. Some calls mint and execute in one step. A separate present-grant path exists.
Preconditions
The action must use the AAES grant path, with control of the agent's credential path. The scope and lifetime needed for the client's workflow must be examined during evaluation.
Evidence available today
Grant attribution is recorded. A valid record establishes integrity of recorded authorization and scope. See Verification for how to check an export. Deployment-specific grant behavior is examined through evaluation.
Known gap
The in-process brokered path does not use a separate present step. Recorded scope does not establish the absence of alternate credentials or bypassed actions. The one-step path is /v1/brokered; the present-grant path is POST /v1/grants/present.
Client responsibility
Review task scopes and grant lifetimes against the intended workflow. Identify which grant path is used and remove alternate authority that would defeat its limits.

Budget ceiling

Question
Can AAES stop routed spending before it exceeds the configured ceiling?
Control statement
Budgets can be committed at decision time for spending routed through AAES. Over the ceiling, the call never leaves and the refusal is recorded.
Enforcement point
The budget decision before dispatch of the routed call.
Preconditions
A budget ceiling must be configured for the governed spending. The spending action must route through AAES under its credential control.
Evidence available today
The refusal is recorded when an over-ceiling call is denied. Security and assurance describes internal budget-ceiling checks. Client-tenant results are produced during evaluation, not supplied as a public result pack.
Known gap
This does not cap vendor spending outside AAES, reveal spending that bypasses it, or provide comprehensive reconciliation of vendor invoices. A dispatched call's record does not prove its external outcome.
Client responsibility
Set ceilings, establish which spending is routed through AAES, and reconcile vendor charges using the client's financial records. Account separately for spending outside the governed path.

Fail-closed journal

Question
What happens if AAES cannot write its decision journal?
Control statement
If the decision journal cannot be written, AAES issues no new grant and no credential is minted. Outstanding grants remain valid for up to 15 minutes.
Enforcement point
The gateway's decision-journal write requirement, before credential minting.
Preconditions
The action must pass through the AAES gateway, and AAES must control its credential path. The client-operated deployment must be included in the failure evaluation.
Evidence available today
If the journal cannot be written, there will not be a journal row for that denial. Confirm via the daemon response. Security and assurance describes internal fail-closed checks.
Known gap
Outstanding grants remain valid for up to 15 minutes; that is not immediate invalidation. Internal checks do not establish production validation.
Client responsibility
Evaluate journal failure behavior in the intended deployment, account for the outstanding-grant interval, and ensure that operational fallback paths do not bypass AAES.

Sealed records

Question
Can a reviewer check the integrity of recorded action evidence without relying on a live AAES service?
Control statement
AAES produces one sealed, hash-chained record per action. Exports can be verified offline against a key AAES does not hold. The daemon hashes tool-call arguments in memory; the action record stores them as a digest.
Enforcement point
Action recording and sealing, followed by offline verification of the export. Integrity verification is an evidence check, not proof that the external action succeeded.
Preconditions
The reviewer needs the export and verification key. Independent attestation additionally requires a configured external witness or timestamp authority and trust material obtained separately from the export.
Evidence available today

The offline integrity-check command is:

aaesctl verify --export <export.jsonl> --pubkey <key.pub>

Verification explains the checks and their limits. Security and assurance describes internal tamper-detection checks.

Known gap
The default deployment has zero independent witnesses. Neither an external witness nor a timestamp authority is connected by default. A valid record establishes integrity of recorded authorization, scope, named approver, and sealed bytes. It does not prove complete action history, true inputs, absence of omitted or bypassed actions, legal non-repudiation, decision correctness, or the intended external outcome. Reproducing a recorded decision does not reproduce model behavior.
Client responsibility
Arrange export review and verification-key access. Configure independent attestation if required, with separately obtained trust material. Use other control records to assess completeness, input truth, and external outcomes.

Selected AAES record properties, including current gaps, are listed on the AIUC-1 note.

See Scope and status for the broader evidence boundary.

Evaluate the control boundary

Use a scoped evaluation to examine the credential path, configured policies, failure behavior, and evidence produced in the client's test tenant.

Read the evaluation procedure

Scope an evaluation

Related pages: Controls: https://aaes.ai/library/controls.html · Scope: https://aaes.ai/library/scope.html · Security and assurance: https://aaes.ai/legal/security.html · Verification: https://aaes.ai/library/verification.html · AIUC-1: https://aaes.ai/library/frameworks/aiuc-1.html · Evaluation: https://aaes.ai/library/evaluation.html · Scope an evaluation: https://aaes.ai/contact.html?ref=library-evaluation