AAES Govern checks requests to use registered tools and the model calls routed through it. Your team runs it on your infrastructure or has AAES host it, and sets the permissions, approvers, and spending limits. These six controls explain what happens to a request and what evidence a reviewer can inspect.
On a brokered path, AAES Govern uses the configured credential to make a permitted tool call and returns its result. The agent does not receive that credential. A grant is permission limited to a task and a lifetime; a decision journal is the stored log of AAES Govern decisions.
These pages describe the product. They are not a certification or a legal opinion. Enforcement requires control of the agent's credential path. Other activity is visible only where telemetry is supplied; observation cannot block it. Application payloads may contain prompt, completion, or personal data.
The controls also cover the two other routed paths. A model call sent through Govern’s model gateway is decided before it goes out, its estimated spend is reserved in a model budget, and it gets a sealed record; a model budget can require a person’s approval at its cap. Each tool exposed through Govern’s MCP endpoint maps to one registered capability and is decided like any other action. Calls that don’t go through Govern are outside these controls.
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 manager, ultimately answerable to a person. Managers can be people or agents; a company can require a person as every agent’s direct manager. Approvers are named in AAES Govern. 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 Govern, 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 Govern must control the credential path for the action.
- Evidence available today
- Records include the actor, the task, the grant, and the accountable manager. Check stored authorization and approver fields with the records sidecar and its separate export-binding check; an export-only PASS does not check those stored fields. 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 Govern.
- 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 the callable capability list contain only capabilities the agent is permitted to use?
- Control statement
- The callable capability list contains the capabilities the agent is permitted to use. A separate catalog shows eligible capabilities the agent may request access to; visibility in that catalog is not permission to execute.
- Enforcement point
- The callable capability view AAES Govern presents to the agent. This boundary does not govern tools or credentials available outside AAES Govern.
- Preconditions
- Permitted capabilities must be defined for the agent. The deployment must route governed tool use through AAES Govern 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 Govern 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 Govern.
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 Govern grant path. Some calls mint and execute in one step. A separate present-grant path exists.
- Preconditions
- The action must use the AAES Govern 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. Checking the stored authorization and scope requires both the export and records-sidecar binding check. 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 isPOST /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 Govern refuse a routed spending request before it exceeds the configured ceiling?
- Control statement
- For supported spending requests routed through it, AAES Govern reserves the evaluated amount at decision time. A request that would exceed the remaining ceiling is refused before dispatch, and the refusal is recorded. This limits what Govern authorizes, not final provider charges or spending outside Govern.
- 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 Govern 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 Govern, 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 Govern, 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 Govern cannot write its decision journal?
- Control statement
- If the decision journal cannot be written, AAES Govern issues no new grant. Journal failure alone does not revoke outstanding grants; their issued lifetimes are bounded by 15 minutes.
- Enforcement point
- The gateway's decision-journal write requirement, before credential minting.
- Preconditions
- The action must pass through the AAES Govern gateway, and AAES Govern must control its credential path. The deployment, whether client-operated or AAES-hosted, 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
- Journal failure alone does not immediately invalidate outstanding grants. They expire within 15 minutes of issuance; successful revocation can end AAES Govern grant authority sooner. 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 Govern.
Sealed records
- Question
- Can a reviewer check the integrity of recorded action evidence without relying on a live AAES Govern service?
- Control statement
- AAES Govern produces sealed, hash-chained evidence for journaled action decisions. Exports can be verified offline against a key AAES, the company, 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:
aaesverify --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. 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 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 Govern 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.