AAES
Book a demo

Developers · AAES Operate + Govern

Use Operate and Govern together.

Operate’s agents send their model and tool calls to Govern, and Govern’s approvals reach the manager in Operate. Each product keeps its own permissions.

This documentation describes AAES Operate. Operational controls and private-work permissions are independent of AAES Govern policy and evidence. About AAES Operate

Live deployment qualification of AAES Operate + Govern is still in progress. Confirm the configured controls in your own deployment before you rely on them.

Separate product permissions

Each product owns its authentication, permissions and records. A token for one product or resource is not a token for another. AAES Operate + Govern adds routes between the products; it does not merge them, and it does not turn earlier operational history into governed evidence.

An unavailable Govern service cannot authorize fallback execution. Routed model and tool calls fail closed, the sandbox has no direct route to a provider, and Operate holds no provider key. Operate itself stays up, approvals Govern raised wait until it returns, and grants issued before the outage stay usable until they expire, at most 15 minutes from issue.

How a call travels

A call from an Operate agent in AAES Operate + GovernAn Operate agent runs in a confined sandbox and sends its model or tool call to AAES Govern. Govern checks permissions and policy and seals the decision. When policy requires an approval, Govern posts the request to the manager's Operate inbox. The manager decides under their own identity, Govern seals that decision and the agent is woken to retry. For the permitted call, Govern reserves the spend, forwards it with the credential it holds, seals the outcome and, for a model call, settles the actual usage.Operate agentin a confined sandboxAAES Governmodel gateway and MCPManagerOperate inboxProvider or toolGovern holds the credential1 Model or tool call2 Check permissions and policy, seal the decision3 Approval needed: request in the inbox4 Manager decides, under their own identity5 Agent is woken and retries6 Retry permitted: reserve spend, forward the call7 Outcome sealed, model usage settled
When Govern is unavailable, routed model and tool calls fail closed. There is no direct route to a provider from the sandbox.

What AAES Operate + Govern configures

  • Each Operate workspace you map to Govern gets an AI connection of the gateway kind pointing at Govern’s model gateway, and a remote MCP tool connection pointing at Govern’s MCP endpoint.
  • Each Claude, Codex and HTTP agent in a mapped workspace becomes a Govern actor with an accountable manager, its own model-gateway token and its own MCP credential. Other agent types are left out of the wiring.
  • Each Operate project or routine maps to a Govern task. A call that maps to no task is refused.
  • Operate’s require-approval rules are switched off on the Govern connection, and each agent’s Operate budget is set so that Govern’s limit refuses first.
  • Claude and Codex agent runs execute only in the AAES confined sandbox; Operate refuses to run them anywhere else. The sandbox’s only network peer is an egress gateway that forwards to Govern’s model gateway, Govern’s MCP endpoint and the Operate API; other names do not resolve. The sandbox holds no provider key and no Govern signing material. HTTP agents call an external runtime and are governed for calls routed through Govern.

Approvals across the products

When Govern policy requires a person, Govern raises the approval and returns a tool error that names it. The bridge posts the request to Operate as a comment on the run’s task or a task assigned to the manager. The decision control is served by the AAES front and calls Govern’s approval API with the person’s own identity-provider token; the API refuses Govern caller credentials and the requester. After the decision, the bridge reports the result on the task and wakes the agent, which retries the same request.

One workspace for both products

The shared workspace shows the modules the signed-in person may access. Adding a product makes its modules available after configuration and authorization. Installation or purchase alone does not grant access to private projects, tasks or governance controls.