This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern
Read this first
This page compares AAES Govern with selected Microsoft, Google, and AWS services: Agent 365, Agent Gateway, and Bedrock AgentCore. Compare each service’s supported integrations, deployment model, and evidence against your requirements. Native controls may already meet them.
In short. Native controls may be enough when your agents stay on one platform and its supported integrations meet your requirements. Evaluate AAES Govern when you need one control point for agents on several platforms, credentials the agent never holds, spending reserved before authorization, or records a reviewer can check offline. Either way, test the credential path: no product can stop a call that bypasses it. For every vendor claim with its dated source, see the full comparison.
Review scope. Published by AAES. The evaluation package runs in your environment and comes only with the paid design partnership. AAES can host Operate and Govern for clients. Competitor findings refer to the dated sources on the comparison table. “Not established in reviewed sources” means the documentation reviewed did not answer the question; it does not establish that a feature is absent. On October 29, 2026 we rechecked the cited Microsoft, Google, and AWS sources against their current versions. The comparison table lists the source and date behind each claim. See Security for assessment status.
Accountable agents and approval routing
AAES Govern records each agent’s accountable managers and uses configured reporting lines to route approvals and escalations. Manager sets can include people or agents, and every chain of managers ends at a person. An agent cannot approve its own requests or satisfy the required human approval for an irreversible action. Escalation follows the reporting lines you configure in Govern.
Microsoft requires at least one sponsor, an accountable user or group, on every agent identity at creation, defines managers as responsible for the agent within the organization's hierarchy, automatically transfers sponsorship to the sponsor's manager when a sponsor leaves, and lets sponsors request access packages on behalf of their agents through approval cycles.
What we did not establish in the reviewed Microsoft material is that this reporting line gates an agent's individual action at decision time: the sponsor and manager machinery governs lifecycle and access-package entitlements, and whether a manager's place in the hierarchy decides if a specific action may proceed at dispatch is not established.
Govern uses configured organizational relationships as inputs to authorization and escalation for supported actions; we have not established whether an equivalent configuration is available in the Microsoft services reviewed.
Microsoft sources for this claim: owners, sponsors, and managers in Entra Agent ID and governing agent identities (retrieved October 29, 2026).
Your third-party credentials stay in your custody
For supported brokered integrations, Govern resolves the configured credential from your vault, executes the authorized request, and returns the result. On a grant path, the agent receives a short-lived Govern authorization. These paths do not hand the downstream credential to the agent; confirm the configured custody model and test for leakage or bypass before deployment.
Identity management, gateway authorization, and storage of third-party credentials are separate functions, and the native services handle them differently: Entra Agent ID is operated by Microsoft, gateway access is authorized with Google's IAM/IAP, and AgentCore Identity's credential providers are operated by AWS. Whether these services support a customer-operated store for the third-party secrets used through them is not established in their reviewed documentation.
The linked comparison row records, per product, the documented store, its operator, and any supported customer-operated alternative. Custody still matters in a dispute: it affects who controls credential use and some associated records, though it does not determine which other records (application logs, downstream-provider records, network records) exist, or which evidence a reviewer will consider reliable. Controlling the credential path can enable AAES Govern to enforce authorization before a supported request is dispatched. Its records describe the decisions and activity captured on that path; credential custody alone does not prove downstream execution or make those records independent.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
Approval before dispatch
All three platforms document ways to bring a human into an agent workflow, and Microsoft documents multistage approvals in Copilot Studio agent flows in preview, combining manual stages, AI stages, and conditions, answered in Teams, Outlook, or the Power Automate portal. Google’s preview Semantic Governance documentation describes checking approval verification before an invoice tool call using LLM policies, whose verdicts it warns may be inaccurate. Its demo material separately shows an application-built approval pattern.
A managed dispatch gate with named approvers is not established by these sources. AWS documents tool-call authorization at the gateway, with a human approval step being an application the customer builds around the agent. The evidence table distinguishes provider-supplied approval interfaces from components the customer configures or builds.
Where policy requires it, Govern binds approval to the exact request and checks it before granting authority or dispatching a brokered action. Changed requests need new approval; approvers can narrow scope, and agents cannot approve themselves. Eligible manager agents may approve where policy permits, but irreversible actions require human approval. These controls cover the routes governed by AAES Govern. The reviewed vendor workflow examples use different approval arrangements; evaluate the relevant policy options for your deployment.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
Spending limits before authorization
Govern reserves the evaluated request amount against the configured budget before authorization and rejects commitments that exceed the remaining balance. The reservation belongs to the business task, such as processing one supplier invoice. It is separate from a platform-usage meter or a card-rail limit. Durable accounting handles concurrent requests and retries; unused reservations are released only when the gateway can establish that authority was not used.
On supported, configured routes, Govern can reconcile provider-confirmation queries or receipts with journaled decisions, so an uncertain or claimed dispatch without confirmation surfaces as an anomaly. Activity that never enters the routed path is outside this reconciliation. The separate aggregate coverage ratio uses externally supplied rail evidence: it counts client-reported confirmation statements over journaled decisions, and its source field is a label rather than source authentication.
That ratio does not establish complete capture or uniformly verified provider execution. The limit applies to evaluated commitments, not final provider invoices or activity outside Govern.
Microsoft’s reviewed Copilot Credits limits govern platform consumption. Google’s preview Semantic Governance policies can evaluate dollar thresholds on proposed tool calls using an LLM; Google warns that verdicts may be inaccurate. Durable aggregate task-budget reservations and provider-confirmation reconciliation are not established in that source. Google billing controls separately concern Google Cloud usage.
AWS also documents AgentCore Payments sessions with optional spending budgets: these control payments through supported providers and flows, not merely AWS service charges. Compare each control’s covered actions, amount calculation, payment-provider support, and enforcement point. AAES Govern’s budget applies to supported commitments routed through Govern; it does not cap all business spending or final provider charges. AWS Payments and Google Semantic Governance were rechecked October 29, 2026.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
An audit export your reviewer checks with Govern off
Govern exports a signed evidence bundle and supplies an offline verifier. With Govern stopped and trusted keys supplied separately, the public export verifier checks projected entry fields, record-hash commitments, chain, tree head and anchors. Checking stored authorization, scope and approver fields also requires the records sidecar and its separate binding check with aaesctl evidence verify; see Verification. New decisions fail closed when the required journal cannot be written; previously issued grants can remain usable for up to 15 minutes. Record integrity alone does not prove complete capture, trustworthy event time, or downstream execution.
The reviewed native services generate audit records and support export or delivery to configured destinations. AWS, for example, documents CloudTrail log-file integrity validation for delivered log files.
The narrower question is whether the reviewed configurations supply portable cryptographic evidence of an individual authorization decision: that is not established in the reviewed Microsoft or Google sources, CloudTrail's mechanism addresses the integrity of the delivered file rather than the semantics of each authorization record, and neither approach alone establishes authorization correctness or downstream execution.
Whether any native control plane refuses an action because its own audit write failed is likewise not established in reviewed sources. Offline verification does not provide independent corroboration: no external timestamp authority or independent witness is wired by default.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
Capability packages and connector libraries
The hyperscalers' libraries are enormous: Microsoft documents standard, premium, and custom connector categories across a large catalog, and Google and AWS operate MCP tool registries and gateways. Connector catalogs, tool registries, gateways, and AAES capability packs are different units and are not directly comparable by count. A connector answers one question: how does the agent reach this API? Endpoint, authentication pattern, schema.
A connector definition alone does not establish how each action through it will be governed: risk tier, irreversibility, spending authority, and credential custody live in the surrounding policy, authorization, and gateway controls, which vary by configuration, and buyers should examine both together for each integration.
An AAES capability package defines actions, risk tiers, data classes, credential references, and allowed destinations. The library contains 95 reviewed application packages and 13 in review. Reviewed packages are pinned in the distribution manifest. Documentation review does not establish live connectivity; test each integration in your environment. Operators can raise risk classifications while retaining the package recommendation and mandatory action floors. Per-provider API version coverage still needs to be checked in the package documentation.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
Customer-operated deployment
AAES Govern runs in a customer-operated deployment using Docker Compose or Kubernetes deployment artifacts. Images can be transferred for installation without a registry connection. Configured identity, vault, and provider integrations may still need network access; cloud service calls require connectivity to those services.
In a customer-operated deployment, your team operates infrastructure, keys, storage, backups, monitoring and availability. The evaluation package runs in your environment and comes only with the paid design partnership. AAES can also host Operate and Govern for clients. No availability SLA is offered today.
An enterprise without an agent operating layer can pair AAES Govern with AAES Operate, which runs and coordinates agents on your infrastructure. AAES Operate has private-work permissions, operational reviews and recorded-spend limits. It does not include AAES Govern. Govern adds spending reserved before an action is authorized, signed decision records you can check offline, and governance for agents you already run on other platforms. When you use both, the Claude and Codex agents in Operate send their AI model calls and tool calls through Govern. Other connected agents (HTTP agents) send their tool calls through Govern, and their model calls too once an administrator connects them. Govern checks only what is sent through it.
The sourced comparison rows behind this claim, with vendor sources and retrieval dates →
Design-partner offer and production pricing
The design partnership costs USD 40,000 for three months and covers AAES Operate and AAES Govern, starting after signing and onboarding. If you continue, the fee is credited in full against the first-year subscription. The evaluation package runs in your environment and comes only with the paid design partnership.
Production pricing is shared on request. Contact us to request it.
Check the claims yourself
Use the sourced comparison to inspect product-specific findings and the evaluation checklist. Test the controls that matter for your workflow, including refusals, approvals, retry behavior, and exported evidence.