Alternatives to Microsoft Agent 365 for Agents Running Outside Microsoft: A 2026 Comparison

Last verified November 3, 2026. Written by Prediction Guard, which is one of the platforms compared. Vendor capabilities change quickly, so confirm anything that matters to your decision directly with the vendor.

The short answer

Operational control of agents outside Microsoft starts from a fair baseline: Microsoft Agent 365 is strongest for agents inside Microsoft 365 and can inventory agents from Amazon Bedrock, Google Vertex AI, and other platforms, but its own control plane is Microsoft-hosted, and its observability and audit evidence remain subject to Microsoft's services, licensing, and retention model. For agents on other clouds, open models, third-party MCP servers, and on-prem systems, the alternatives are cross-environment control planes (Prediction Guard, TrueFoundry, and IBM watsonx Orchestrate as a conditional candidate pending on-prem confirmation), cloud-native platforms for single-cloud estates (AWS AgentCore and Google's Gemini Enterprise Agent Platform), and identity, assessment, or inspection layers (Okta, Credo AI, Lakera) that complement a control plane. As a sovereign AI control plane you run inside your boundary, Prediction Guard provides operational control of agents on any cloud or on-prem system once their model and tool calls route through it.

Where Agent 365 is strong

Agent 365 deserves a fair reading, because for the right estate it is hard to beat.

• Microsoft-native agents. Each agent gets an Entra Agent ID, agents can act on behalf of users or with their own access, and Defender and Purview extend to agent activity. Microsoft announced general availability on May 1, 2026, in Microsoft 365 E7 or standalone at $15 per user per month.
• Inline enforcement for Microsoft-resident agents. Entra Conditional Access applies to agents, and Defender can block tool invocations, per Microsoft's service description.
• Cross-platform inventory. Registry sync, which Microsoft's July 2026 update calls generally available, discovers agents on Amazon Bedrock (Agents Classic and AgentCore), Google Vertex AI, Salesforce Agentforce, Claude Managed Agents, Databricks Genie, Oracle Generative AI Agents, and Snowflake Cortex. Synced agents get registry metadata and a subset of governance actions, starting with deletion where a platform's API supports it, per Microsoft's Zero Trust guidance.
• An SDK for agents built elsewhere. Microsoft's SDK FAQ says it works with agents hosted on Azure, AWS, Google Cloud, or on-premises, adding identity, observability, and governed tool access.
• Tool governance and spend limits. Admins can block or allow MCP servers, plugins, and connectors organization-wide, and cost management sets spending limits for Microsoft's usage-based agent services.
• Endpoint coverage. Shadow AI discovery and network controls reach local agents on managed devices.

What happens outside Microsoft

• Other clouds. Microsoft's connected platforms page says management and observability vary by platform, with Salesforce, Databricks, Oracle, and Snowflake observability listed as coming soon. Synchronization is manual, and agent observability data collection is a Frontier preview feature. Deeper identity and telemetry come through the SDK, which is code-level work.
• Open and self-hosted models. Network controls cover Copilot Studio and local agents. We found no documentation of inline inspection of model calls from agents elsewhere [U].
• MCP servers. Org-wide allow and block works for registered servers, and bring-your-own registration is in preview. One report says the admin center discovers only servers registered in the connected gateway [R].
• On-prem agents. The SDK supports them, but the control plane stays Microsoft-hosted. Microsoft's FAQ says SDK observability telemetry (agent spans) is dropped if no user in the tenant has an E7 or Agent 365 license assigned, which is a condition on telemetry ingestion and not a limit on every SDK capability, and Work IQ MCP separately requires a Microsoft 365 Copilot license.

How this comparison was built

Criteria. Coverage outside Microsoft (other clouds, open and self-hosted models, MCP servers, on-prem agents), then runtime enforcement type, agent identity and delegated authority, token and spend enforcement, immutable audit logs and evidence inside your boundary, and compliance mappings (NIST AI RMF, EU AI Act, AIUC-1).

Four categories, defined by rules applied to every platform.

• Cross-environment control planes and conditional candidates: documented customer-controlled deployment, inline runtime enforcement, agent-level identity or tool authorization, and audit evidence, covering agents that route through them wherever those agents run. A platform that meets these rules on paper but has an unconfirmed requirement is a conditional candidate. IBM is the one here: on-premises availability of its agent controls is unconfirmed, so it does not yet meet every requirement.
• Cloud-native agent platforms: strong controls inside one cloud's agent runtime, with coverage elsewhere limited or unconfirmed.
• Identity and assessment layers: identity-provider-based agent lifecycle (Okta) or assessment and registry workflows (Credo AI) that complement runtime enforcement.
• Inspection components: runtime inspection of prompts, outputs, or tool calls without a documented identity, authorization, and audit stack (Lakera).

Four distinctions the tables keep apart.

• Inline versus monitoring versus assessment. Inline means the platform can block or rewrite a request or tool call before it runs. Monitoring and inventory observe or list agents. Assessment records risk and compliance evidence.
• Retained versus tamper-resistant. A log can be kept without being tamper-resistant. A mechanism such as hashing or write-once storage must be documented to count.
• Availability. Where a vendor states a status, capabilities are marked (GA), (preview), or (roadmap).
• Evidence tags. [V] the vendor says so in its own materials, which we did not test; [R] a third-party source reports it and we did not find it in vendor materials; [U] unconfirmed, meaning not documented in the sources we reviewed, which is not the same as "no."

Confirmed limit versus not verified. In each entry, a confirmed limit comes from the vendor's own documentation. A "not verified" item is one we could not find, and it may be a documentation gap and not a product gap.

Method and disclosure. Vendor documentation came first; third-party reviews were used only where vendor pages were silent, and most reviewers sell competing products, so treat [R] claims as leads. Every platform gets the same template, including Prediction Guard and Agent 365. We did not test any product. Prediction Guard wrote this page.

Comparison tables

Related reading by criterion

• Runtime enforcement versus assessment only: continuous enforcement versus audits shows why point-in-time assessment and runtime enforcement produce different evidence, and gateway versus control plane separates traffic routing from policy enforcement.
• Immutable audit logs and evidence inside your boundary: audit log implementation covers what a defensible AI audit log contains and where it should be generated and retained, and is the source for Prediction Guard's hashing and WORM claims above, which it states alongside the point that your SIEM stores the logs. Prediction Guard writes Immutable Audit Logs inside your boundary, so evidence for agents on any cloud is not stored in another vendor's tenant.
• Compliance mappings (NIST AI RMF, EU AI Act, AIUC-1): NIST AI RMF mapping walks through each function, and the AI compliance evidence framework covers NIST AI 600-1, OWASP, and EU AI Act audit artifacts.

The eight alternatives

Each entry uses the same template: what it is and its strength, coverage outside Microsoft, identity, log retention, what you operate and license, and its limits.

Cross-environment control planes and conditional candidates

1. Prediction Guard. A self-hosted AI control plane that deploys on-premises, in a VPC, hybrid, or air-gapped and enforces policy on every call inside your boundary. Agent Behavior Controls decide at runtime which actions an agent may take, and Component Input/Output Controls cover each request and response. Strength: delegated per-user authority for MCP connections, with evidence kept inside your boundary.

• Agents outside Microsoft: it covers agents on other clouds, open models, MCP servers, and on-prem systems once their calls route through it.
• Identity and permissions: Prediction Guard binds an agent's access to a named user's delegated authority at the MCP proxy, so the same accountability holds whichever cloud the agent runs in. Its marketplace listing describes per-agent, per-session, and per-workflow token budget limits [V].
• Log retention: Immutable Audit Logs are generated inside your boundary and stored by your SIEM, and the Evidence bundle packages the registration record, AIBOM, policy snapshot, and log export. The guide describes SHA-256 hashing at generation and WORM storage but does not say whether WORM is a default or something you configure.
• What you operate: the deployment itself, under a bundled self-hosted license that its AWS Marketplace listing describes as fixed price and not seat-based [V].
• Limits and open questions: confirmed, it is self-hosted only, covers only agents that route through it, has less native depth than Agent 365 for Microsoft-resident agents, has no assessment workflow like IBM's or Credo AI's, and is smaller than the hyperscalers. Not verified: AIUC-1 coverage beyond its own description of alignment and a logging evidence mapping, and whether tamper resistance holds in your SIEM storage configuration.

2. TrueFoundry. An AI gateway, an MCP gateway, and a deployment platform with VPC, on-premises, and air-gapped deployment. Strength: model serving and GPU orchestration, plus gateway-driven Okta token exchanges for MCP servers.

• Agents outside Microsoft: agents that route model and tool calls through the gateway are governed wherever they run, and models you host run under the same policies [V].
• Identity and permissions: RBAC and authn/authz for agents and MCP servers [V]. Per-user delegated authority is [U].
• Log retention: its audit logging docs describe platform activity logs (admin and API actions) with SIEM export, and request logging follows your logging config [V].
• What you operate: a Kubernetes-native platform and its data stores, installed as a Helm chart. Per its self-hosted security docs, the control plane and gateway still exchange authentication, licensing, and telemetry with TrueFoundry's central servers, and security logging and monitoring are your responsibility [V]. VPC and air-gapped installs are on the Enterprise plan, per its pricing page [V].
• Limits and open questions: confirmed, its audit-logging docs cover platform activity, tamper resistance appears only in a vendor blog, and standard self-hosted installs contact TrueFoundry's central servers. Not verified: a published NIST AI RMF, EU AI Act, or AIUC-1 mapping, how air-gapped installs handle central authentication, and a plan-by-plan feature matrix for self-hosted installs.

3. IBM watsonx.governance and watsonx Orchestrate (conditional candidate). watsonx.governance is a lifecycle assessment platform with EU AI Act, NIST AI RMF, and ISO 42001 accelerators. IBM's June 2026 Agentic Control Plane in watsonx Orchestrate adds policy enforcement, content checks, agent identity and access control, and cost control. Strength: it combines an assessment platform, installable on-prem software, and an agent control plane in one portfolio.

• Agents outside Microsoft: Orchestrate can scan supported third-party environments such as Amazon Bedrock [V].
• Identity and permissions: agent identity and access control in Orchestrate [V]; not documented for watsonx.governance [U].
• Log retention: audit trails and factsheets [R], inside your boundary only when IBM software runs on your infrastructure.
• What you operate: on-prem software runs on Cloud Pak for Data or IBM Software Hub, which you install and maintain, per IBM's install docs [V]. Licensing is not confirmed here [U].
• Limits and open questions: confirmed, IBM's announcement says the Agentic Control Plane is available on AWS and IBM Cloud. Not verified: on-prem availability of its agent controls, inline blocking by watsonx.governance (IBM cites content checks; reviewers disagree), and MCP specifics.

Cloud-native agent platforms

4. AWS Bedrock AgentCore. AWS's managed platform for agents built with any framework and any model provider, with Identity, a Gateway that acts as a managed MCP server, Policy, and Observability, per its release notes. Strength: Cedar-based Policy that evaluates every Gateway tool call before it runs, generally available since March 2026, plus VPC egress and a GovCloud region.

• Agents outside Microsoft: strongest for agents on AWS. Using AgentCore services for agents hosted elsewhere is [U].
• Identity and permissions: OAuth on-behalf-of token exchange and a token vault [V]; Gateway works with Cognito, Okta, Auth0, or your own OAuth provider.
• Log retention: traces and logs go to CloudWatch and CloudTrail in your AWS account. AWS's agentic AI guidance presents tamper-evident retention as something you build, through a log-archive account, deny-delete bucket policies, CloudTrail log file validation, and optionally S3 Object Lock [V].
• What you operate: AWS-managed services configured in your AWS account. Pricing is usage-based [U].
• Limits and open questions: confirmed, the runtime and Gateway are AWS-managed. Not verified: per-agent spend enforcement, coverage for non-AWS agents, and built-in tamper resistance.

5. Google Gemini Enterprise Agent Platform. Google's agent platform, announced at Cloud Next 2026, with an Agent Registry, Agent Identity, and Agent Gateway in its Govern layer, per Google's overview. Strength: a workload-bound cryptographic agent identity that Agent Gateway uses for default-deny access policies, Model Armor inspection of tool payloads, and allow and deny decisions logged to Cloud Logging.

• Agents outside Microsoft: the launch blog describes connectivity across any environment, and the Agent Gateway overview shows what that means. Agent-to-Anywhere egress governs calls from agents on Agent Runtime and Gemini Enterprise to servers, tools, and agents anywhere, including third-party MCP servers. Agents running on other clouds are not a listed runtime, so connectivity to external destinations is not governance of external agents [V].
• Identity and permissions: a unique cryptographic ID per agent, with managed user-delegated OAuth [V].
• Log retention: gateway decisions go to Cloud Logging, as the monitoring docs describe, and Cloud Audit Logs cover Agent Platform operations [V].
• What you operate: Google-managed services in your Google Cloud project. Licensing is [U].
• Limits and open questions: confirmed, enforcement attaches to agents on Agent Runtime and Gemini Enterprise, and Gemini Enterprise supports egress only. Not verified: which Govern components are generally available, spend enforcement, and tamper resistance.

Identity, assessment, and inspection layers

6. Okta for AI Agents. Okta extends its identity platform to agents. Agent SSO, based on the open Cross App Access standard, is included in core Okta SSO, and the separate Okta for AI Agents subscription registers every agent, discovers shadow agents, assigns human owners, and adds certification reviews. Strength: a kill switch that cuts off an agent's access across connected resources in one action, with active-token revocation at the gateway still planned.

• Agents outside Microsoft: it registers agents regardless of where they were built, including import from platforms such as AWS Bedrock and Salesforce Agentforce [V].
• Identity and permissions: registry in Universal Directory, Cross App Access tokens, and agent-to-agent connection rules [V].
• Log retention: agent events are captured in Okta's System Log, which can stream to your SIEM, and agent-to-agent handoffs form an auditable chain [V]. Tamper resistance is [U].
• What you operate: little, apart from the MCP Bridge, a self-hosted proxy delivered through professional services [V]. Okta for AI Agents is a separate subscription [V].
• Limits and open questions: confirmed, Okta's September 22 announcement and its product announcements document, which says dates are calendar year, target Agent Gateway for general availability in Q3 CY26, endpoint discovery in early access now with general availability in Q4 CY26 (CrowdStrike) and Q1 CY27 (Okta Verify), and the gateway kill switch and Configuration Designer for Q4 CY26. Enforcement today is therefore identity-time unless Agent Gateway has shipped. Not verified: whether Agent Gateway reached general availability by September 30 (one trade report says it is, and we found no Okta page confirming it), and any inspection of model traffic.

7. Credo AI. A governance, risk, and compliance platform with an AI registry, policy packs for the EU AI Act, NIST AI RMF, ISO 42001, and SOC 2, and automated evidence generation. It supports AIUC-1 and says it does not issue certification. Strength: GAIA, its governance agent, has been generally available since May 13, 2026 and speeds use case intake, drafts questionnaire responses, recommends risks from Credo AI's library, and suggests risk-matched controls.

• Agents outside Microsoft: its registry integrates with major clouds and data platforms [V].
• Identity and permissions: an agent registry with agent cards [V]. Identity enforcement happens elsewhere [U].
• Log retention: evidence lives in the platform. Credo AI's self-hosting documentation describes Kubernetes installation with online and air-gapped methods [V].
• What you operate: if self-hosted, a Kubernetes cluster, object store, and database, with a license uploaded at install [V]; little if SaaS.
• Limits and open questions: confirmed, Credo AI's May 13, 2026 GAIA announcement names continuous production monitoring with policy enforcement and intervention at the point of use as the next step on its roadmap, separate from GAIA's intake and risk work. Its Agent Governor page describes enforcement inside the agent harness (block, allow, escalate, or advise before tool calls) as a research preview, not generally available, with no production SLA and Claude Code the only harness live today. Not verified: identity enforcement, spend controls, and tamper resistance.

8. Lakera (Check Point AI Guardrails). Runtime inspection for prompts, outputs, tool calls, tool responses, and tool descriptions, plus a tool allow and deny list, per its agent security docs. Strength: a mature prompt-layer defense that also inventories agents and connected MCP servers, with self-hosting for Enterprise licensees, including air-gapped installs. Check Point announced the acquisition on September 16, 2025 and closed it on October 22, 2025.

• Agents outside Microsoft: it discovers agents across the platforms where they run [V], and its Guard API screens traffic wherever you call it.
• Identity and permissions: not documented [U]. You supply identity and authorization.
• Log retention: self-hosting keeps data inside your boundary [V].
• What you operate: the inspection containers and their integration into your applications, under an Enterprise license for self-hosting [V].
• Limits and open questions: confirmed, it is a inspection component and not a full control plane. Not verified: an audit-log feature, tamper resistance, and how procurement works after the acquisition, since new sales reportedly route through Check Point [R].

Which one fits

• Agents that live inside Microsoft 365, Copilot Studio, or Foundry: Microsoft Agent 365. For agents that live entirely inside Microsoft 365, Agent 365's native Entra, Purview, and Defender integration matters most, and Prediction Guard, which is built for agents outside Microsoft, is not a better fit there.
• Agents on several clouds, open models, MCP servers, or on-prem systems, with enforcement and evidence inside your boundary: Prediction Guard or TrueFoundry. Prediction Guard applies one policy set to every agent that routes through it, on other clouds, with open models, across MCP servers, and on-prem, because the control plane runs inside your boundary and not in any one vendor's cloud. Choose it when agent authority and audit evidence are the center of the requirement, and TrueFoundry when you also want model serving and GPU orchestration. Add IBM if you already run IBM software and can confirm the agent controls on-prem.
• An estate that is mostly on one cloud: AWS Bedrock AgentCore or Google's agent platform, with a cross-environment control plane for everything else.
• Cloud-neutral agent identity and lifecycle through your identity provider: Okta for AI Agents.
• An assessment and compliance workflow with framework packs: Credo AI.
• Inspection of prompts, outputs, and tool calls that you can self-host: Lakera.

Many teams keep Agent 365 for Microsoft-resident agents and add a control plane for the rest, with an identity layer or inspection component beside either.

Five questions to ask every vendor

• How does an agent get covered, and what happens to one that is not?
• Where does enforcement occur, inline on the request path or after the fact?
• Who controls identity and permissions, your institution or a directory you do not run?
• Where are logs retained, and is there a documented tamper-resistance mechanism?
• What must you operate and license yourself?

FAQs

1. Can Microsoft Agent 365 govern agents that run on AWS or Google Cloud?

It can inventory them. Registry sync discovers agents on Amazon Bedrock, Google Vertex AI, and other platforms, with management and observability varying by platform, and the control plane is Microsoft-hosted, with observability and audit evidence subject to Microsoft's services, licensing, and retention model.

2. Can Agent 365 govern MCP servers that Microsoft does not host?

Partly. Admins can block or allow registered MCP servers organization-wide, and bring-your-own registration is in preview, but one report says the admin center discovers only servers registered in the connected gateway.

3. Does Agent 365 work for agents running on-premises?

The SDK supports agents hosted on-premises, adding identity and observability, but the control plane is Microsoft-hosted, so telemetry and audit logs flow to Microsoft's cloud. For agents that send observability telemetry through the SDK, Microsoft's FAQ says the telemetry is dropped unless at least one user in the tenant has an E7 or Agent 365 license assigned. That is a condition on telemetry ingestion, not a limit on every SDK capability.

4. Do I still need a separate control plane if I use Agent 365?

If nearly all of your agents are Microsoft-native, Agent 365 may be enough. If you also run agents elsewhere, or need enforcement and evidence inside your boundary, a control plane you operate fills the gap, and the two can coexist.

5. What should I check before relying on registry sync or an SDK integration?

Test one agent end to end before you treat a platform as covered. Confirm which capabilities are generally available for that platform, whether tool calls and model access are enforced inline or only listed, and where the resulting audit records are retained.