AAES Govern checks agent actions and the model calls routed through it: it checks permission before an AI agent uses a registered tool or calls a model through Govern’s model gateway. Your team runs the software and sets the rules. Its boundary is the tool actions and model calls routed through AAES Govern, not the whole agent or business process.
Key terms
- Capability
- A registered tool operation, such as sending a message or reading a record.
- Credential path
- The way an agent gets the access needed to use a tool. AAES Govern can block a call only when it controls that access and the agent cannot use another route.
- Grant
- Permission for a defined task and limited lifetime. An AAES Govern grant is an authorization, not a downstream provider credential.
- Brokered execution
- AAES Govern makes a permitted call with the configured credential and returns the result without giving that credential to the agent.
- Decision journal
- The stored log of AAES Govern decisions. Sealed records can be exported and checked for changes.
- Telemetry
- Activity reports supplied to AAES Govern. Reports can help a reviewer observe work; they cannot give AAES Govern the power to stop it.
These pages describe the product. They are not a certification or a legal opinion. AAES does not certify that a client has met a regulator's requirements. The client remains the regulated entity.
Product boundary
AAES Govern governs supported actions routed through it, including actions of agents you already run on other platforms. In AAES Operate + Govern, the model calls and MCP tool calls of Operate’s sandboxed agents are routed through AAES Govern. AAES Operate, the operating layer, is outside the scope of these control mappings except for actions routed through Govern. Agents created in AAES Operate use your configured model connection; Govern’s permissions, approvals, and spending controls apply only to their calls routed through it. These controls do not establish that a model’s response is correct.
AAES Govern governs registered tool calls and actions, and the model calls sent through its model gateway. Application payloads may contain prompt, completion, or personal data. The daemon hashes tool-call arguments in memory; the action record stores them as a digest. AAES Operate separately retains instructions and run transcripts on encrypted volumes; Operate sends model requests to the endpoint you select, or through AAES Govern's model gateway in AAES Operate + Govern.
For routed actions, AAES Govern can enforce task-scoped grants, named approval requirements, and budget ceilings. Actions classified as irreversible require approval by an authorized person. Policies can require approval for other actions too. Budget ceilings apply to spending routed through AAES Govern, not vendor spending outside it.
Enforcement boundary
Enforcement requires control of the agent's credential path. For example, if an agent still holds a direct provider key, it can use that key without asking AAES Govern. Activity outside AAES Govern is visible only where telemetry is supplied. Observation is not enforcement.
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. These properties do not prevent work performed through credentials or paths outside AAES Govern.
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 a complete action history, the truth of recorded inputs, the absence of bypassed actions, or that a dispatched call achieved its intended outcome.
Deployment and assurance status
- Deployment
- Self-host Operate and Govern, or have AAES host them. Client-operated options include Docker Compose, Kubernetes and isolated on-premises deployments.
- Hosted offering and SOC 2
- AAES can host Operate, Govern or both under an agreed client deployment. No SOC 2 report exists today.
- Production status
- No production adoption is claimed.
- Adapter validation
- Action adapters and capability packages are tested against local servers speaking vendor API formats, not live vendor tenants. Live tenant validation happens during a design partnership. Model-gateway live results are on the Models page.
- Independent witnesses
- 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. Neither is connected by default.
- Internal checks
- Internal tests cover fail-closed behavior, named approval binding, budget ceilings, and tamper detection. These checks do not establish production validation or independent certification.
Security posture and limitations is the source for current security details. Deployment-specific questions are resolved through evaluation.
Can AAES Govern control this workflow?
Use these questions to scope an evaluation. An unresolved answer is a boundary to investigate, not evidence that the workflow is governed.
| Check | Question for the client |
|---|---|
| Credential control | Can you place the agent's credential path under AAES Govern control for the actions in scope? |
| Identifiable tool actions | Can you identify the tool calls and actions to be routed through AAES Govern, separately from prompts and model completions? |
| Named human approval owner | Can you assign each registered agent an accountable human manager and name authorized approvers in AAES Govern? An agent cannot approve itself. |
| Client operation | Can your team operate the software in a client-controlled deployment? |
| Bypass paths | Can alternate credentials and direct tool-access paths be removed so AAES Govern controls the credential path for the actions in scope? |
| Bypass monitoring | If a path remains outside AAES Govern, can it be monitored separately, with that exclusion recorded? Monitoring a bypass is not enforcement. |
| Budget and approval policy | Can you agree which actions require approval and which routed spending is subject to a budget ceiling? |
| Evaluation data | Can the evaluation be conducted without production-sensitive data? |
| Client test tenant | Are you willing to validate the required adapters on your test tenant during a design partnership? |
The evaluation page states the control-evaluation scope and exit conditions. Results from a client's test tenant are produced during a scoped evaluation.
What this library is not
- Not a general-purpose model platform. AAES Govern checks the model calls routed through it for spend, approvals and records. It does no model hosting, routing optimization or response caching, and its model gateway does not store prompts or completions. On the action path it governs registered actions; applications may include prompt or completion text in their payloads.
- Hosting by agreement. AAES can host Operate and Govern for clients; the deployment and responsibilities must be agreed.
Bring a defined workflow, its credential paths, and the approval owners to an evaluation.