Comparing AI agent governance approaches

Agent 365 is generally available, priced at USD 15 per user per month standalone or included in M365 E7 (per Microsoft's GA announcement, May 2026; verify current packaging), and integrated with the Entra, Purview, and Defender tooling many firms already run.

Agent 365 may be sufficient where its supported integrations, credential controls, and evidence exports meet your requirements. Evaluate the approach AAES is designed to offer on two requirements that separate custody from telemetry: customer-controlled credential custody for third-party effects, and exported records designed for offline integrity verification. Offline verification still depends on trusted keys, verifier behavior, and the record producer's capture boundary; it is not independence from the producer.

Both requirements deserve precise definitions. Customer-controlled credential custody means the secret an agent uses against a third-party service (illustrative secret types include payment-provider keys of the Stripe or Ramp class, messaging keys of the Twilio class, or SMTP relay credentials) stays owned and held by you rather than custody resting in a platform vendor's service. Custody paths differ in what crosses the trust boundary. On a grant path, AAES issues a short-lived, task-scoped AAES grant: an authorization, not a downstream credential. On a brokered-execution path, AAES executes the permitted call with the configured credential and returns the result without handing the downstream credential to the agent. A short-lived AAES grant does not make the downstream secret ephemeral. Observation-only registrations record reported activity and cannot stop the call. Not every custody model is available: the dated capability matrix records which models are wired, which are lab-only, and which are refused at startup. Offline integrity verification means an exported record can be checked for integrity with the vendor's service off. It establishes that a record is internally consistent and unmodified; it does not by itself prove the downstream action executed as intended, and in AAES's default deployment it does not establish independence from AAES, because no external timestamp authority or independent witness is wired.

How the two requirements join: 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. Telemetry about an effect remains the actor's own report. What we did not establish in reviewed Microsoft sources is that Agent 365 brokers a customer-owned third-party secret (for example, a payment-provider key) or emits an artifact a reviewer can check offline without a Microsoft service dependency. Read the matrix cells for the exact wording, which describes our review, not Microsoft's product.

Cross-platform coverage is deliberately absent from the evaluation criteria above. As of the May 2026 GA, Microsoft's material claims cross-estate discovery and onboarding for agents from platforms such as AWS Bedrock and n8n, and Google Agent Gateway can delegate authorization to third-party engines. A comparison that sells "we cover other vendors' agents" is selling a feature the incumbents already claim. AAES's cross-platform routing is stated as a scoped capability in the matrix, not as a differentiator.

The rows ask every column the same questions: what traffic and deployments are supported; who operates the credential store and who can access its secrets; what authorization or execution facts are recorded; whether supplied artifacts can be checked offline given specified trust material; what that check does not establish; how human approval works at decision time; whether spending limits bind the agent's actions; what a tool or capability entry carries beyond connectivity; where the control plane itself runs; and what the pricing meter measures. Not every row records a difference: the approval row in particular records real Microsoft capability. Column sources are listed in Sources; competitor rows were reviewed September 19, 2026, except the approval, spending, library, deployment, and pricing-meter rows, which were reviewed September 21, 2026. Not established in reviewed sources describes our review, not the vendor.

One substantiated strength and one evaluation question per competitor. Agent-security vendors (Zenity, Noma, WitnessAI), identity vendors (Okta), and the program-governance pure-plays (Credo AI, OneTrust, ModelOp) answer different buying questions; the pure-plays are covered in our enterprise AI governance platforms guide.

Microsoft Agent 365

Strength: estate-wide agent registry, identity, and security integrated with Entra, Purview, and Defender, included in M365 E7 for eligible tenants under the described packaging. Ask: which of our agents and third-party effects are outside its enforcement path, and what evidence would our auditor accept?

Google Agent Gateway

Strength: framework-agnostic policy on agent traffic over MCP, A2A, REST, and gRPC, with the option to delegate authorization to third-party engines. Ask: what happens to effects produced by agents outside Google Cloud runtimes?

AWS Bedrock AgentCore

Strength: managed agent infrastructure including credential management for third-party services via AgentCore Identity. Ask: who operates the credential store, and can our reviewers validate the records without an AWS service dependency?

ServiceNow AI Control Tower

Strength: AI asset and workflow governance where approvals and processes already live. Ask: does a policy defined here enforce the same guardrails on third-party agents as on native ones, or are external agents registered read-only?

IBM watsonx.governance

Strength: program governance a risk committee recognizes: model lifecycle, assessments, regulatory mapping. Ask: which integration gates the action itself at decision time?

What AAES is designed to offer

• Customer-controlled custody. The credential an agent uses against a third-party service stays customer-owned. Custody paths differ in what crosses the trust boundary. On a grant path, AAES issues a short-lived, task-scoped AAES grant: an authorization, not a downstream credential. On a brokered-execution path, AAES executes the permitted call with the configured credential and returns the result without handing the downstream credential to the agent. A short-lived AAES grant does not make the downstream secret ephemeral. Observation-only registrations record reported activity and cannot stop the call. The dated capability matrix records which custody models are wired, lab-only, or refused at startup, and the Capability Library lists the vendor packs that declare those custody models, with each pack's review state and release identity shown.
• Offline integrity verification. Signed per-action receipts with an open verifier, designed so a reviewer can check integrity offline with the AAES service off. 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. The default deployment wires no external timestamp authority and no independent witness, so independence from AAES itself is not established out of the box; verification still depends on trusted keys, verifier behavior, provenance, and the record producer's capture boundary.
• Cross-platform routing: a capability, not a differentiator. One policy and evidence layer across agents running on any platform (Microsoft, Google, AWS, or self-hosted) for the capabilities routed through it. Cross-estate coverage is table stakes as of May 2026: the matrix above records Microsoft claiming onboarding of agents from platforms such as AWS Bedrock and n8n, and Google delegating authorization to third-party engines. AAES claims it for the routed subset only; work that bypasses AAES is invisible to it.

These are design commitments, not shipped differentiators. The credibility question is not whether AAES looks good next to Microsoft; it is whether an unshipped design should be read as a proven product. It should not.

Whether you evaluate AAES or any alternative, run one bounded workflow in a sandbox or a controlled, reversible equivalent (do not make your first test an irreversible production effect), and test the control path directly:

• Attempt the action without approval and expect a recorded refusal.
• Approve the exact request, alter it, and confirm the approval cannot be reused.
• Confirm an agent cannot approve itself.
• Attempt the same action directly against the provider with the agent's own credential (a bypass attempt) and confirm whether anything stops or records it.
• After a refusal, confirm at the downstream provider that the refused action had no effect.
• Present the same approval or grant twice, and concurrently, and confirm it cannot be replayed or double-counted.
• Make the decision journal unavailable and confirm new requests fail closed; check how long previously issued grants remain usable.
• Drive two concurrent requests against a nearly exhausted budget and confirm the shared accounting refuses the overflow.
• Export the records and verify them offline with the network disabled, using keys trusted through a separate channel.
• Require independence on the default export and confirm the verifier rejects it, since no external witness is wired by default.

A platform that passes these tests in a sandbox has cleared a first gate, not an expansion decision: passing smoke tests does not rule out bypassable credentials, replayable grants, broken shared accounting, or fabricated but consistently signed history. A presentation alone does not demonstrate these action-layer controls. The AAES architecture, interfaces, and record format are documented in the open, and the API schema downloads without sign-in.

Review the architecture Discuss a design partnership

When is Microsoft Agent 365 enough, and when should we evaluate AAES?

Agent 365 may be sufficient where its supported integrations, credential controls, and evidence exports meet your requirements. Evaluate the approach AAES is designed to offer on the two requirements that separate custody from telemetry: customer-controlled credential custody for third-party effects (illustrative secret types include Stripe-, Ramp-, Twilio-, or SMTP-class credentials), and exported records designed for offline integrity verification. 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. Cross-platform coverage is table stakes: Microsoft's GA material claims it, and this page's matrix records it. AAES is pre-launch; validate its specifications against your deployment needs and each alternative's current capabilities.

What is the difference between program governance and action governance?

Program governance (the center of products such as IBM watsonx.governance) inventories AI systems, maps them to frameworks, tracks assessments, and produces reports. Action governance constrains what a deployed agent may do at the moment it acts: which credential path it must use, who approved the action, and what it may spend. An assessment is a claim about intended behavior; an enforcement record is evidence of what happened on the governed path. Most regulated organizations need both, which is why this page compares approaches rather than declaring a single winner.

Can AAES records be verified offline?

The design goal is verification without an AAES service dependency: exported records and an open verifier allow offline integrity checks. Offline verification establishes that a record is internally consistent and unmodified; it does not by itself prove the downstream action executed as intended. Verification still depends on trusted keys, verifier behavior, provenance, and the record producer's capture boundary: a signer can produce a different internally consistent history. In the default deployment, independence from AAES is not established: no external timestamp authority and no non-AAES witness are wired; the verifier counts independent witnesses only against trust material supplied out of band. No auditor, examiner, or insurer is known to accept AAES artifacts today. This is a proposed evidence format, not an accepted standard.

Why are Zenity, Credo AI, Okta, and similar vendors not here?

They answer different buying questions. Agent-security vendors such as Zenity, Noma, and WitnessAI center on discovery and threat detection; identity vendors such as Okta center on workforce and workload identity; program-governance pure-plays such as Credo AI, OneTrust, and ModelOp are covered in the AAES guide to enterprise AI governance platforms. This page compares five approaches spanning the three hyperscaler control planes, the workflow platform, and a program-governance product. It is an editorial selection, not an exhaustive market map. The pure-plays are covered in our platforms guide.

For the pricing side of the same decision (per-seat control planes versus capacity-metered governance, with the arithmetic at 10, 100, and 1,000 users), see Agent governance pricing: seats vs capacity.

Competitor cells were reviewed against the vendor sources listed below on September 19, 2026; the approval, spending, library, deployment, and pricing-meter rows were added and reviewed on September 21, 2026 against the sources marked with that date. A capability is stated plainly only when the cited source supports it; otherwise the cell reads not established in reviewed sources, which is a statement about our review, not about the vendor. Product packaging and pricing change; check the vendor's current pages before deciding. AAES's own limits are printed beside its claims throughout: observation is not enforcement for pass_through custody, records cover routed actions only, and no institution is known to accept AAES artifacts today. Corrections are welcome at hello@aaes.ai and will be listed here.

• September 19, 2026: First publication.
• September 20, 2026: Repositioned. Customer-controlled credential custody and offline-verifiable evidence now lead the hero, the evaluation criteria, and the AAES section; cross-platform coverage is restated as table stakes (the matrix already records the hyperscalers claiming it). The AAES "typical evaluation fit" cell now names the custody requirement. No competitor cell changed; the matrix was not re-reviewed on this date.
• September 21, 2026: Corrected after external adversarial review. Retired the "a vendor cannot credibly attest" sentence everywhere, including structured data; replaced "without trusting the vendor" and "neutral" evidence language with offline-integrity-verification scope; separated which custody paths issue AAES grants from which execute without exposing downstream credentials; rebuilt the matrix on identical per-column questions (supported traffic, credential-store operation, recorded facts, offline verification, and what the check does not establish); removed the unsupported market-leadership, "most," and FedRAMP claims; extended the buyer test list. No competitor cell was re-reviewed against vendor sources on this date.
• September 21, 2026 (second change): Added five matrix rows (human approval at decision time, spending limits on agent actions, tool and capability libraries, where the control plane runs, and the pricing meter), reviewed against Microsoft Learn's multistage-approvals, Copilot Credits, and connector documentation, Google Cloud's demo material, and AWS's AgentCore documentation, all retrieved the same day; third-party counts and reports are marked as such in Sources. No earlier cell changed.
• September 21, 2026 (third change): Added per-row anchors to the matrix so claim-level links from other pages land on the corresponding row, and aligned the AAES deployment cell with the planned-design status: deployment artifacts not yet generally available, offline installation under evaluation, and the hosted option under consideration rather than in early access, consistent with the disclosure that AAES has no product in market and no design partners. No competitor cell changed.