Watch the complete agent-workflow walkthrough to see agent identity, permissions, human review and retained records in a synthetic local demonstration.
An invoice workflow through AAES Govern
Recording transcript: An invoice workflow through AAES Govern
In this narration, “AAES” refers to AAES Govern.
AI agents already work inside enterprise systems. AAES puts a defined scope, a task budget, and an accountable person around their actions. This walkthrough uses synthetic invoice data and isolated local systems. Start with the invoice agent. Its directory entry identifies its manager and its assigned capabilities: invoice reads and payment requests.
Open the invoice task. It has an assigned agent, a deadline, and a one hundred and fifty dollar budget. These limits describe the task the agent is working on.
Now submit a scoped invoice read through the live request console. This is a real call to the local AAES gateway. The response records that the request was allowed and executed, with confirmation from the synthetic connected system.
Request access to the invoice archive instead. That capability is outside this agent’s assigned scope. The gateway refuses the request. A capability being registered does not automatically give every agent permission to use it.
Next, review the existing one hundred and twenty dollar payment request. The authorized reviewer sees the exact agent, task, action, and amount before confirming approval. Approval authorizes this request; it does not itself execute a payment.
Finally, open the task records. Inspect the receipt chain and distinguish the confirmed invoice read from the refused and held requests. Retain the recorded evidence for further review. No real payment is made in this demonstration.
AAES. Autonomy. With Accountability. Visit us at aaes.ai.
Choose how to start
AAES Operate setup documentation is provided in the evaluation package. Offline verification and local planning do not require a running daemon.
Start with Operate developer documentation to build agents and connect to its interfaces. The API, MCP, CLI, SDK and appearance references below describe Govern.
Create agents and assign their work in AAES Operate. Connect agents you already run to Operate to give them work, and to AAES Govern to control their actions and model calls. AAES Govern applies permissions, approvals, spending controls, and records to actions routed through its governed paths, including model calls through its model gateway and tool calls through its MCP endpoint.
To connect an existing agent to AAES Govern, register it in the Govern console, assign an accountable manager whose chain of managers ends at a person, grant the capabilities it needs, and complete its generated setup handoff in your application or agent platform. Connected agents keep their existing runtime.
Your organization or AAES runs the AAES Govern service, also called the daemon. It stores the rules, registered actions, and application credentials used to govern requests. Existing applications connect through the HTTP API, a language SDK, or the MCP adapter. Administrators use the operator-console screens on a separate address and port; custom branding changes its appearance while the same controls apply.
For example, an invoice agent requests a registered action to read an invoice. AAES Govern checks its permissions and the task's rules. On a brokered route, Govern records the decision and makes the allowed call with the configured application credential. Other routes can authorize an action without executing it.
- Task and capability
- A task identifies the work, its manager, deadline, and budget. A capability identifies a registered action the agent may request.
- Grant
- Authorization to act within stated limits. Receiving a grant does not prove an action ran.
- Record and receipt
- A record is a sealed entry in AAES Govern's decision journal. A receipt is the API object describing decision and effect evidence. Read APIs return selected fields as JSON views.
- Export
- The bundle used to check record integrity offline. An individual API response is not automatically a complete verification export. See the evidence export specification.
AAES Infer is for model access with jurisdiction controls and company billing. The API includes text chat and native Messages and Responses interfaces, with streaming and client tools where the signed offer supports them. Integration access requires a qualified offer; model-source support in Operate or Govern does not qualify an Infer offer.
AAES Infer documentation
Text-chat API, authentication, jurisdiction headers and request limits. Public API access is not open.
AAES Operate documentation
Agent creation, runtime connections, private projects and tasks, and Operate APIs, SDKs, MCP and CLI.
AAES Govern documentation
Govern APIs, language clients, MCP, CLI and console appearance, with the authorization boundary of each surface.
Start an evaluation
Request the package, install on a test host, and run one bounded workflow you can check.
Govern HTTP API
Decide actions, request access, and read receipts through the OpenAPI 3.1 contract. /v1/action records a decision and, when allowed, mints a grant; it does not execute the downstream action.
Govern MCP
Connect over stdio or HTTP. Discover built-in tools followed by the capabilities this caller may use. HTTP tools/call sends an operator-issued bearer token.
Govern CLI
Administer Govern with aaesctl, verify exported journals offline, and manage local tenant registries with aaescp.
Govern SDKs
Integrate with Python or TypeScript. The Python SDK is on PyPI and the TypeScript SDK on npm. Other languages call the HTTP API using the OpenAPI contract. The SDK methods page lists authorization scope for each entry point.
Govern Appearance
Set operator-console colors, type, and logo per tenant, or build your own UI on the OpenAPI contract and SDKs.
Use the products together
Read the AAES Operate + Govern integration guide for separate identity and authority, reviewed execution bindings and the shared workspace. Configure and qualify the exact release before relying on combined execution.
Connect to your AAES Govern service
Ask your operator for the HTTPS service address and an access token. There is no hosted API-key dashboard. Set AAES_ENDPOINT to that address and AAES_TOKEN to the operator-issued bearer token. The token identifies your organization's deployment account, or tenant; callers do not choose a tenant on API calls.
The address is configured by platform -listen, which defaults to 127.0.0.1:8090. Packaged Compose uses TLS by default. A native install needs a certificate/key pair and trusted certificate roots. Plain HTTP requires explicit -allow-insecure-http opt-in; the loopback HTTP examples assume a dedicated test deployment with that setting.
Once your operator provides a running deployment and a token, set both environment variables and read the capabilities this caller may use:
curl -sS "$AAES_ENDPOINT/v1/capabilities" -H "Authorization: Bearer $AAES_TOKEN"Capabilities describe what the caller may use. The catalog describes what the caller may ask for. Refusals are JSON with a reason and, when the daemon can identify the smallest satisfying change, a remedy.
How agents get data on a brokered-execution path
The agent authenticates to AAES Govern and requests a registered capability. Govern evaluates policy, obtains any required approval, journals the decision, and executes the permitted call using the configured customer-controlled credential path. The broker returns the permitted result rather than handing the downstream credential to the agent. This describes brokered execution, not observation-only integrations.
Credential exposure through downstream responses, errors, logs and records remains a deployment test requirement. Credential isolation is not data isolation: AAES does not control arbitrary subsequent use of data already delivered to an agent.
Public docs and the evaluation package
Start with the evaluation guide and download the OpenAPI 3.1 contract without sign-in. The SDK methods page lists language entry points and authorization scope. The evaluation package runs in your environment and comes only with the paid design partnership. Discuss the paid design partnership for Govern binaries, aaesctl, release-verification public keys, and setup notes. The Govern SDKs are public packages installed separately from PyPI or npm; using them requires a configured deployment and an operator-issued token. Remaining setup notes ship with the evaluation package.