Read this first
This page compares the architecture AAES is designed to offer with selected Microsoft, Google, and AWS services: Agent 365, Agent Gateway, and Bedrock AgentCore. Those services differ in deployment model and supported agent environments, and some support agents or resources outside their provider's cloud. If your agents live on one vendor's cloud and that vendor's tooling satisfies your reviewers, those tools are a reasonable answer; this page is not for you. Where the approaches may still differ is structural, and each section below states one proposed difference as a claim, then explains it.
Our position, disclosed. This page is published by AAES, a pre-launch company that intends to sell one of the approaches discussed. AAES is pre-launch and at design-partner stage. No SOC 2 report, no penetration test. No independent certification or assessment of AAES exists. Everything on the AAES side below is planned design, not generally available or independently validated, and each claim section says so again. Claims about other vendors come from a dated review of their documentation (most competitor rows reviewed September 19, 2026; the approval, spending, library, deployment, and pricing-meter rows reviewed September 21, 2026) covering the products, editions, and configurations listed in the evidence table. Where a claim reads not established in reviewed sources, it means our review found no supporting statement within that scope. It is not a finding that the capability is unavailable, and the differences below are evaluation questions, not proven AAES advantages. Cross-estate coverage is table stakes (Microsoft and Google claim it too), so it is not a difference we sell. The cell-by-cell evidence, with sources and retrieval dates, is on the sourced comparison. If anything here is wrong, tell us and we will correct it.
Claim: agents are registered like employees, and the reporting line executes
AAES's proposed identity model assigns each agent a named accountable manager and a place in the reporting line, intended to route approvals and escalations. Under the proposed rules an agent's sponsor is always a person, an agent cannot sponsor or approve for itself, and escalation follows the same reporting line your org chart already defines.
To be fair to the incumbent, Microsoft's sponsorship model is genuinely strong: 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. AAES is being designed to use 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 September 21, 2026).
Claim: your third-party credentials stay in your custody
For supported brokered integrations, AAES is being designed so that the key your agent's work depends on against a third-party service (a payment-provider key, a messaging key, an SMTP relay credential) stays owned and held by you: the agent would receive a short-lived, task-scoped grant or a brokered result, not the downstream credential itself. The integration specification will identify what the agent receives, who operates the credential store, and whether AAES or its operators can access the credential.
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 evidence table compares, per integration, 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 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.
Claim: approval is a precondition of dispatch, not a step in a workflow someone remembered to build
All three platforms document ways to bring a human into an agent workflow, and Microsoft's is genuinely capable: as of this review, 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. For Google, launch coverage describes human-in-the-loop checkpoints in the Agent Designer (a third-party report), and Google's own demo material shows an event-driven approval agent built as a pattern: auto-approve under a threshold, human review above it. 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.
The workflow examples we reviewed implement approvals as a step inside a flow the builder wrote, and we have not evaluated every policy-enforcement option available across these vendors. AAES's proposed distinction is enforcement at its own authorization boundary, for supported, non-bypassable execution paths: the approval decision binds to the exact request and cannot be reused if the request changes, an approver can narrow a request but never widen it, an agent can never approve itself, and policy can require multiple approvers with escalation along the reporting line. On supported enforced paths, AAES is being designed to refuse dispatch, and the release of authority, when the required approval is absent or does not match the authorized request. That does not prevent equivalent actions through credentials or routes outside AAES's boundary.
Claim: a credit limit on every agent, not an alert on the platform's bill
For supported actions with an amount determinable before dispatch, AAES is being designed to reserve that amount against a configured budget and to refuse and record requests that would exceed the remaining balance, the way an employee operates under a corporate card limit, except that here the ceiling binds at authorization time. This caps commitments recorded through AAES, not final vendor charges, adjustments, or spending outside AAES. Budget scope (per agent, per work item, or shared) and the retry, concurrency, and reservation rules will be defined in the budget specification.
The specific billing features we reviewed meter the providers' own services. Microsoft documents per-agent monthly consumption limits with alerts and a hard stop, and separately documents policy- and user-level spending limits; the reviewed controls are metered in Copilot Credits, Microsoft's platform consumption. The evidence table identifies each control, its documented enforcement behavior, and its review date. Google's and AWS's billing controls we reviewed likewise govern their own platforms' usage. Within that review scope we did not establish a turnkey per-action ceiling on what an agent may commit your business to pay through your own payment, card, or banking credentials, which does not exclude custom implementations or other vendor services. One kind of limit caps what the agent costs their platform; the other would cap what the agent commits your business to.
Claim: an audit export your reviewer checks with AAES off
AAES plans to provide signed, per-action authorization-record exports and an openly specified offline verifier, so a reviewer could check the export's integrity with every AAES service off, using trust material supplied out of band. The verifier is not yet released, and integrity checks would not by themselves establish completeness, trustworthy event time, or downstream execution. The evidence model is fail-closed by design on enforced paths: an action whose decision cannot be durably journaled would not be dispatched; observed paths cannot be blocked, and their records may be incomplete.
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. One further limit we print beside this claim: offline integrity verification is not independence from AAES, because no external timestamp authority or independent witness is wired by default.
Claim: a connector is not a governed capability
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 pack is proposed as one reviewed JSON per vendor, and it answers different questions: what class of action is this, what data does it touch, can it be undone, who must approve it, what may it commit, and where does the credential live? The proposed pack schema declares, per action, a risk tier, data class, irreversibility class, custody model, and egress allowlist, distinguishing declarations from runtime-enforced controls, and publication status will identify the reviewer, the review date, the covered API version, and the review's limitations; unreviewed drafts are excluded from the published library. AAES plans to prioritize documented governance attributes and review depth over catalog breadth, and to stay smaller on purpose: reviewing a pack means reading the vendor's documentation and classifying every action it exposes.
Claim: AAES runs in your boundary, not theirs
The selected native services are provider-operated control planes; deployment regions, administration interfaces, availability commitments, operator access, and applicable legal terms vary by service and contract. AAES is designed to place operation of the control plane with the customer. Planned targets are a single VM with Docker Compose and your Kubernetes cluster via Helm and Terraform, with deployment artifacts not yet generally available. An offline installation mode is under evaluation: its supported integrations, runtime network dependencies, update process, and disconnected operating limits remain to be validated, and an air-gapped control plane cannot itself call external payment or messaging services, so supported disconnected use cases will be documented explicitly. Customer operation would put keys, storage, and availability under your control, though on its own it does not determine legal jurisdiction.
The honesty that belongs beside this claim: client-operated means client-operated. For the proposed customer-operated deployment, your team would carry infrastructure availability, backups, monitoring, patching, and disaster recovery, the operational burden the hyperscalers carry for you on their platforms. AAES support commitments are not yet defined. For estates that would want a managed option, AAES is considering a hosted deployment for design partners; availability, isolation architecture, and terms are not yet committed, and any hosted pilot would have separate written responsibility and availability terms.
Claim: governance priced on capacity, not seats
As of this review, Microsoft lists Agent 365 at USD 15 per user per month standalone following its May 2026 GA, or included in M365 E7. The published price, its standalone and E7 packaging, the noted E5-class prerequisites, and the official announcement source are recorded on the pricing comparison, which also notes that list-price multiplication is not contractual billing. Per-user licensing and capacity pricing respond to different usage patterns: incremental cost depends on existing entitlements, which users require licenses, workload volume, and operating costs, so we do not claim an AAES cost advantage before publishing commercial terms.
AAES intends a capacity-based commercial model rather than per-user licensing: the cost of governance would scale with the work governed, not with how many people you let use it. The billing unit, minimum commitments, overage rules, and rates are not finalized, and customer infrastructure and operating costs would be additional for self-hosted deployments. The per-seat arithmetic at 10, 100, and 1,000 users (labelled as arithmetic, not a quote, and excluding discounts, taxes, and prerequisite licenses) is on the pricing comparison.
Check the claims yourself
Every difference on this page is recorded cell-by-cell, with vendor sources and retrieval dates, in the evidence table on the sourced comparison, including the rows where the vendors are strong and the cells that read not established in reviewed sources, which describes our review, not their products. The buyer checklist on that page sets out proposed acceptance tests for a future design-partner evaluation (one bounded workflow, ten checks) as questions to put to any vendor, AAES included; it is not evidence that the current prototype passes them.