Comparing AI agent governance approaches

Agent 365 is generally available at USD 15 per user per month standalone or included in M365 E7. Microsoft Cloud subscription customers receive foundational identity, registry, basic usage insights, and core admin governance actions such as deploying, blocking, approving, and managing agent access at no additional cost. Premium licensing adds advanced governance, security, and insights; feature availability depends on integration.

For enterprise customers, the standalone prerequisite is Microsoft 365 E5, or Microsoft 365 E3 (or Office 365 E3 plus EMS E3) with both Microsoft Defender Suite and Microsoft Purview Suite. Frontline and small-business prerequisites differ; consult the FAQ for those plans. These claims follow Microsoft’s licensing FAQ, reviewed October 29, 2026.

Agent 365 may be sufficient when its supported integrations, credential controls, and evidence exports meet your requirements. Evaluate AAES Govern where you need to test the task budget, exact-request approval, and provider-confirmation checks described above.

For each product, test the actual credential path and exported records. Offline verification depends on trusted keys, verifier behavior, and which activity the producer captures. Record integrity does not establish independence from the producer.

Credentials and records: what the requirements mean

Customer-controlled credential custody means you own and hold the secret used against the downstream service, rather than a platform vendor holding it in its service. Examples include Stripe- or Ramp-class payment keys, Twilio-class messaging keys, and SMTP relay credentials.

On a grant path, AAES Govern issues an AAES grant: short-lived permission for one task. It is not a credential for the downstream service and does not shorten that secret’s lifetime. On a brokered-execution path, Govern makes the permitted call with the configured credential without giving it to the agent. Observation-only registrations record reported activity and cannot stop the call. The dated capability matrix identifies implemented, lab-only, and refused credential paths.

Offline integrity verification checks exported fields and record-hash commitments with the vendor’s service offline. Checking stored authorization, scope, and approver fields also requires the records sidecar and its separate binding check. Neither establishes that the downstream action occurred as intended.

AAES Govern connects no external timestamp authority or independent witness by default. Verification against supplied trust material therefore does not establish independence from AAES.

How the supporting requirements join: 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. 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 support also matters to deployment fit. Microsoft documents onboarding for agents from platforms such as AWS Bedrock and n8n, and its May 2026 general availability announcement put registry sync with AWS Bedrock and Google Cloud into public preview. Google documents that Agent Gateway can delegate authorization decisions to third-party engines. Those claims need workflow-specific validation for each vendor. AAES Govern'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; and where the control plane itself runs.

Not every row records a difference: the approval row in particular records real Microsoft capability. Column sources and retrieval dates are listed in Sources. The initial review was September 19, 2026, with subsequent targeted reviews documented below. On October 29, 2026 we rechecked every cited source we could retrieve. A few ServiceNow and third-party pages could not be retrieved, so claims that rest only on them keep their earlier dates in Sources. Not established in reviewed sources describes our review, not the vendor.

Scroll horizontally to compare all platforms.

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.

Three other approaches overlap with these requirements. The vendor pages below were reviewed October 29, 2026.

Peta describes a server-side credential vault and managed Model Context Protocol (MCP) runtime with short-lived agent tokens, policy-required human approval in Peta Desk or the web console, and tool-call audit exports.

SecureAuth documents authorization on every call, decided down to the individual MCP tool and its arguments, a separate identity and narrowly scoped token for each agent, OAuth Rich Authorization Requests (RAR), and asynchronous human approval through Client-Initiated Backchannel Authentication (CIBA).

Ramp markets spend restrictions per agent, per task, and per merchant, a human sponsor for each agent key, a configurable human-in-the-loop approval policy, and command-line (CLI), MCP, and API interfaces. Its introduction identifies the connected-human-identity model as available today; it describes a distinct agent-identity model without the same availability statement.

These are vendor-documented claims, not independently tested enforcement. We have not completed a capability-by-capability review and do not establish which requirements they lack, including durable task budgets, exact-request binding, or equivalent offline integrity checks. They remain sourced mentions rather than matrix columns.

Primary sources and retrieval dates are listed in Sources.

AAES Govern describes task-bound budget reservation before dispatch, exact-request approval where policy requires it, and reconciliation of journaled decisions against provider-confirmed executions on supported, configured routes. Activity outside the routed path is outside this reconciliation. Test the relevant enforcement path in each product; these overlapping approaches do not establish equivalent behavior.

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: enterprise-wide AI asset discovery, governance, and runtime containment where approvals and processes already live, spanning third-party clouds and a bidirectional Agent 365 integration. Ask: does a policy defined here authorize each third-party action before dispatch, or does enforcement remain discovery, workflow approval, and after-detection containment?

IBM watsonx.governance

Strength: model lifecycle, assessments, and regulatory mapping, with Enforcement Tracking collecting watsonx Orchestrate agent evaluation metrics and recording pass/breach results against governance thresholds. This evidence integration does not by itself establish per-action dispatch authorization or offline proof equivalent to AAES Govern. Ask: which integration gates the action itself at decision time?

What AAES Govern provides

• Budget before dispatch. For supported actions whose amount can be determined beforehand, Govern commits the approved request against the task’s budget before dispatch and refuses the excess. This covers routed commitments, not final vendor charges or spending outside Govern.
• Approval of the exact request. Where policy requires approval, it must be supplied before dispatch and cannot be reused for a changed request.
• Provider confirmation. On supported, configured routes, Govern matches journaled decisions to executions confirmed by the downstream provider. A claimed dispatch without confirmation appears as an anomaly. Activity that never enters the routed path is outside this reconciliation.
• Customer-controlled custody. The credential an agent uses against a third-party service stays customer-owned. On a grant path, AAES Govern issues an AAES grant: short-lived permission for one task. It is not a credential for the downstream service and does not shorten that secret’s lifetime. On a brokered-execution path, Govern makes the permitted call with the configured credential without giving it to the agent. 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. Exported projected fields and record-hash commitments checked with an offline verifier, with the Govern service off. The public Apache-2.0 aaesverify v0.3.0 source and release binaries verify the aaes.export/v3 exports that current AAES Govern deployments write, and retained aaes.export/v2 exports such as the public sample. The earlier v0.2.0 release reads v2 only. Stored authorization, scope and approver fields require the records sidecar and its separate binding check with aaesctl evidence verify. 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 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. The proposed design-partner outputs describe the evidence to agree within a signed scope; no customer evaluation result is claimed.
• 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. Several vendors claim cross-estate coverage 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. Govern claims it for the routed subset only; activity outside Govern is visible only where telemetry is supplied.

Evaluate these controls on your own workflow. Local implementation tests do not establish live integration coverage or independent assurance.

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:

• Configure the action to require approval, attempt it without approval while the journal is writable, and confirm a recorded refusal.
• Approve the exact request, alter it, and confirm the approval cannot be reused.
• Configure the agent as its own approver and confirm policy rejects the self-approval.
• 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. Previously issued grants can remain usable for up to 15 minutes; confirm that each platform you evaluate states and enforces its own expiry bound.
• 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 these tests supports only the tested configuration; broader deployment still requires bypass testing, concurrency testing, and an assessment of evidence provenance. 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 Govern?

Agent 365 may be sufficient when its supported integrations, credential controls, and evidence exports meet your requirements. Evaluate AAES Govern on one concrete task: whether the evaluated amount is reserved before dispatch, required approval covers the exact request, and recorded decisions are matched to provider-confirmed executions on supported, configured routes. A claimed dispatch without provider confirmation appears as an anomaly; activity outside the routed path is outside this reconciliation.

Also check customer-controlled credentials, such as payment or messaging keys, and records that can be verified offline. 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. Cross-platform coverage is also claimed by Microsoft and other vendors; validate each product against your deployment requirements.

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 evaluates behavior against defined criteria. An AAES Govern decision record shows the recorded authorization decision; separate evidence is needed to establish what happened in the downstream system. Most regulated organizations need both, which is why this page compares approaches rather than declaring a single winner.

Can AAES Govern records be verified offline?

Yes. The standalone verifier checks exported fields and the cryptographic links, summaries, and signatures that make changes detectable. Specifically, it checks projected entry fields, record-hash commitments, chain, tree head, anchors, and signatures against trusted keys. Checking stored authorization, scope, and approver fields also requires the records sidecar and a separate aaesctl evidence verify binding check.

Neither check establishes that every action was recorded or that a reported outcome occurred. An external witness counts only when checked against separately supplied trust material; none is connected by default. No auditor, examiner, or insurer acceptance of AAES artifacts is established. The receiving reviewer decides whether the evidence meets their needs.

Why are Zenity, Credo AI, Okta, and similar vendors not in this comparison?

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 products such as Credo AI, OneTrust, and ModelOp are covered in the AAES guide to enterprise AI governance platforms.

Peta, SecureAuth, and Ramp also overlap with parts of these requirements; the section on where each approach fits summarizes their documented claims.

Evaluate each product on the enforcement paths needed for your workflow. No categorical claim is made that card networks or platform meters cannot reach those paths. This page compares five approaches spanning hyperscaler control planes, workflow and program governance. It is an editorial selection, not an exhaustive market map.

The program-governance products are covered in our platforms guide.

The matrix uses the same questions for each vendor. A cell states a capability only when its cited source supports it; not established in reviewed sources describes our review, not an absence in the product. Vendor documentation is evidence of vendor claims, not independently tested enforcement. Product packaging and pricing change; check current vendor documentation before deciding.

The initial review was September 19, 2026. Added rows and targeted source reviews are dated below; a later update does not refresh every competitor cell. September 27 additions used report-level sources, including a third-party licensing analysis corroborated by Microsoft’s overview; subsequent primary-source checks are recorded separately.

AAES Govern limits accompany its claims: observation-only pass_through custody cannot block calls, records cover routed actions and separately supplied reports, and no institutional acceptance of AAES artifacts is established. Send corrections to hello@aaes.ai.

• October 29, 2026: Rechecked the cited vendor sources. Corrected ServiceNow’s kill switch to revoke credentials at configured enforcement points, of which Okta is one. Added Microsoft’s preview registry sync and its current Agent 365 SDK documentation, Google’s current Agent Gateway runtime scope and primary Agent Identity documentation, AWS’s one-click Gateway integrations and Payments charging, and IBM’s published pricing, deployment options and Gartner placement. Updated the SecureAuth and Ramp summaries to current vendor wording and moved the Gemini Enterprise editions source to Google’s documentation. Updated the MCP gateway coverage link after MintMCP renamed itself Mintive. The ServiceNow product and Gartner pages, the Medium article and the Build session page could not be retrieved; they keep their earlier dates.
• October 16, 2026: Removed the pricing-meter row and the links to the retired pricing comparison. AAES production pricing is shared on request. No other competitor cell changed.
• October 8, 2026: Renamed the AAES column to AAES Govern, the AAES product that provides these controls. AAES Operate, the operating layer, is not a governance product and has no column. No competitor cell changed.
• October 3, 2026: Checked Google’s primary app pricing, including its limited-rollout zero-seat-fee usage option, and Microsoft’s primary Power Platform connector count. Credited IBM’s documented agent evaluation and Enforcement Tracking integration. Qualified AAES approver authentication by deployment mode. Other competitor cells retain their earlier source-review dates.
• September 30, 2026: Credited ServiceNow’s documented central server-credential storage, rotation and scoped per-connection tokens while retaining the unestablished customer-operated-custody boundary. Added Google’s preview LLM tool-call thresholds and approval-verification checks, with its probabilistic-verdict warning. Replaced the adjacent Peta and Ramp summaries with current primary vendor sources and qualified Ramp availability. Shortened the comparison leads without removing the supported-route, custody, or evidence limits; linked the proposed scoped evaluation outputs.
• September 30, 2026: Added documented AgentCore Payments spending budgets and the specific AgentCore pricing source. Corrected Microsoft licensing prerequisites and included foundation governance actions against its licensing FAQ. Clarified policy-conditional AAES approval, eligible manager-agent approval, and the irreversible-action human floor.
• September 27, 2026: Added task-budget, exact-request approval, and supported-route provider-confirmation criteria. Corrected reconciliation to match journaled decisions against provider-confirmed executions and exclude activity outside the routed path. Added the Agent 365 foundation-tier report and adjacent Peta, SecureAuth, and Ramp mentions. Qualified vendor claims, availability, and evidence limits. Other competitor cells were not re-reviewed.
• September 26, 2026: Expanded ServiceNow’s documented cross-vendor discovery, runtime monitoring, credential-revocation containment, Microsoft integration, and Gartner placement. Added Microsoft Agent 365 SDK and Google Agent Identity details. These targeted source reviews corrected earlier scope descriptions.
• September 23, 2026: Updated AAES implementation and customer-run evaluation status. No competitor claim was re-reviewed.
• September 23, 2026: Clarified published pack artifacts, supported spending paths, journal-write requirements, the 15-minute outstanding-grant limit, and unpublished production rates. Added September 21 retrieval dates to AWS sources; no competitor cell was re-reviewed.
• September 21, 2026: Corrected evidence claims to distinguish integrity from independence and downstream execution. Separated grant and brokered-execution paths, aligned matrix questions, removed unsupported leadership and FedRAMP claims, and expanded the buyer tests. Existing competitor cells were not re-reviewed.
• September 21, 2026: Added approval, spending, tool-library, deployment, and pricing rows using Microsoft, Google, and AWS sources retrieved that day. Sources identify third-party counts and reports. Earlier cells did not change.
• September 21, 2026: Added links to individual matrix rows and corrected AAES deployment availability. This historical availability description was updated on September 23; no competitor cell changed.
• September 20, 2026: Clarified customer-controlled credentials and offline record integrity as evaluation requirements. Cross-platform coverage is also claimed by other vendors. No competitor cell was re-reviewed.
• September 19, 2026: First publication.