Agentmarketplace
All posts

Agent 365 and Non-Microsoft Agents: Can It Govern AWS Bedrock and Google Vertex AI?

Marcus Reyes, Editorial · Aug 14, 2026 · Last updated August 14, 2026 · 8 min read

No agents in this category in the preview.

See the full catalog →

What it does

Connects to
security-scanned
model-agnostic scoped access human-in-the-loop

What it does not do

Permissions it needs

Published by

Open the full listing →
Deployed · Live
Demo

Yes. As of August 2026, Microsoft Agent 365 can synchronize agents from six non-Microsoft platforms into its agent registry: Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents and Oracle Generative AI Agents. An admin authenticates once per environment on the Connected platforms page in the Microsoft 365 admin center, then triggers a sync. The agents appear alongside your Copilot Studio and Foundry agents in one inventory. The catch is that this is a discovery and management channel, not a governance channel: the Entra, Purview and Defender controls that make Agent 365 valuable do not automatically extend to an agent running in someone else's cloud.

That distinction is the whole article. If you are an enterprise with agents scattered across three clouds and a board asking who is accountable for them, the answer of what Agent 365 does and does not reach determines whether you have solved the problem or moved it.

Which platforms sync into the Agent 365 registry?

Microsoft's Connected platforms documentation was last revised on August 10, 2026, and it names six providers. The authentication requirements differ meaningfully, and they are worth seeing side by side before you commit an afternoon to any of them.

PlatformStatusWhat you have to create
Amazon BedrockSupportedAn IAM user with ten bedrock: permissions, plus fourteen more bedrock-agentcore: permissions if you want AgentCore harnesses and runtimes. Access key ID and secret
Google Vertex AISupportedA service account with the Vertex AI Administrator role, or a custom role with reasoningEngines list, get and delete. Project ID, region, secret key
Salesforce AgentforceSupportedAn External Client App with the client credentials flow enabled and four OAuth scopes. My Domain URL, consumer key, consumer secret
Databricks GenieSupportedA service principal with workspace admin access. Workspace URL, client ID, client secret
Anthropic Claude Managed AgentsPreviewA dedicated workspace and a workspace-scoped API key. Microsoft flags the connection as preview because Anthropic's Managed Agents APIs are in beta
Oracle Generative AI AgentsSupportedAn OCI group, an API-only service user, an API key pair and an IAM policy. Six values to supply

One footnote on the Anthropic connection that will cost somebody an hour: Microsoft says to create a new workspace rather than using the default one, "because the default workspace doesn't expose a workspace ID that you can use when you create the connection." The setup simply will not complete against a default workspace.

Read the permissions before you paste the key

This is the part that deserves a second look from whoever owns cloud security, because the connection is not read-only and the documentation does not lead with that.

The Bedrock permission list Microsoft asks for includes bedrock:DeleteAgent. The Vertex AI custom role includes aiplatform.reasoningEngines.delete. The AgentCore additions include five more delete permissions covering harnesses, runtimes, gateways, gateway targets and memory. That is by design, since the registry supports management actions and not just discovery, but it means an Agent 365 connection is a credential that can destroy agents in your production AWS or Google environment.

Oracle is the one place Microsoft documents the alternative properly. It offers two IAM policy options and explicitly recommends the narrower one, describing Option A as "more permissive than the app requires because it also allows create and update operations" and labelling Option B "Least privilege (recommended)." Option B grants read across the agent family and restricts management to delete only. If you want the same posture on AWS or Google, you will have to construct it yourself by omitting the delete permissions and accepting that delete-from-registry stops working.

Microsoft is also clear about where the liability sits. Your use of these outside products remains subject to each provider's terms of use, and you are responsible for complying with them. Connecting Bedrock to a Microsoft tenant does not transfer that obligation to Microsoft. For teams that already maintain a control matrix, this is the point where a new connection becomes a new control to evidence, and mapping it into whatever framework you report against, whether that is SOC 2 and ISO 27001 control mapping or an internal standard, is cheaper to do at connection time than at audit time.

What the sync does not give you

Four limits decide whether this replaces your existing multi-cloud inventory or merely supplements it.

1. Sync is manual today

After a connection validates, an admin presses the Sync agents button. Microsoft says you will be able to "configure future synchronizations to occur on a scheduled basis, in a future release." Until then, the registry is exactly as current as the last time a human remembered. For a compliance artifact that is a real weakness, and it argues for a recurring calendar reminder rather than trusting the dashboard to be live.

2. Governance does not follow the agent home

Agent 365's security story rests on Microsoft Entra enforcing risk-based access, Microsoft Purview applying information protection and DLP, and Microsoft Defender providing runtime threat detection. Those apply to agents with an identity in your tenant. A Bedrock agent that appears in your registry is visible and, if you granted the permissions, deletable. It is not suddenly covered by your Conditional Access policies. Visibility and control are different products, and the sync buys you the first one.

The path from one to the other is the Microsoft Agent 365 SDK. Microsoft's own description of what extending an agent produces: "Once extended, an agent instance has Entra-backed agent identity, enhanced notification capabilities, extended observability, covered MCP tooling, and an IT-approved template system." That is the mechanism for pulling an outside agent genuinely inside the boundary, and it takes engineering effort rather than a credential paste. The full picture of how licensing, the registry and the SDK fit together is in our guide to Microsoft Agent 365.

3. Draft agents are mostly invisible

Microsoft states it plainly: "Currently, you can only view draft agents from Copilot Studio. Support for draft agents from other platforms, such Agent Builder, Foundry, and SharePoint, aren't currently available." Half-built agents on three of the four main Microsoft paths do not show up, and unpublished work in connected clouds varies by platform integration. If your worry is what somebody is prototyping against production data, the registry is not the whole answer.

4. The counters start when you switch it on

Every usage metric in Agent 365, active users, agent run-time, trending agents, carries the same note: "This metric begins when your organization activates Agent 365 licenses." There is no backfill. A tenant that activates in November has no view of what happened in October, ever.

The practical consequence is a genuinely useful piece of advice: turn the free tier on now, even if you are twelve months from buying. Viewing the inventory costs nothing. Microsoft confirms that "Viewing all agents in the Microsoft 365 admin center doesn't require a specific license," and that an admin only needs the AI Reader role, which Microsoft calls the recommended least-privilege option. Activating early is how you get a baseline instead of a starting line.

Does this replace platform-native governance?

No, and treating it as a replacement is the mistake to avoid. What Agent 365 gives a multi-cloud organization is a single answer to "how many agents do we have and who owns them," which is genuinely hard to produce otherwise and is usually the question an auditor or a board actually asks. What it does not give you is one policy engine across six clouds.

QuestionAgent 365 registry syncPlatform-native tooling
How many agents exist across all our platformsYes, in one viewNo, one console per cloud
Who owns each agentYes, with ownerless agents flaggedVaries
Conditional Access and identity governanceOnly for agents with an Entra Agent IDNative IAM per platform
Runtime threat detectionDefender, for agents inside the boundaryNative per platform
Real-time stateNo, manual syncYes
Delete an agent from a central consoleYes, if you granted delete permissionsYes

Read that table honestly and the shape of the right deployment appears: use Agent 365 as the system of record for inventory and ownership, keep platform-native controls for enforcement, and use the SDK selectively on the agents that touch data you actually care about. Trying to make it the single control plane for a genuinely multi-cloud estate in 2026 will disappoint you.

Is it worth connecting if you only run a few outside agents?

Probably not yet, and it is worth saying so. Each connection costs a service account, a credential rotation obligation and a permission set that includes delete. For an organization with four agents in Bedrock and one in Vertex, a spreadsheet is honestly more secure and takes ten minutes. The registry earns its keep at the point where nobody can confidently list the agents, which in practice arrives somewhere between thirty and fifty and arrives faster than teams expect once Copilot Studio is open to business users.

There is also a third option that a surprising number of teams skip past. The governance problem exists because agents are being built in five places by people with different levels of oversight. Buying a finished agent that does one job well, with its permissions visible before you deploy it, does not create a new registry entry to govern in the first place. You can browse ready-made AI agents by category and see exactly which integrations and permissions each one needs up front. For teams comparing the vendor catalogs themselves, AI agent marketplaces covers how AWS, Google, Salesforce and ServiceNow structure theirs, and Microsoft Agent Store covers what Microsoft's own catalog carries.

The short version

Agent 365 does govern non-Microsoft agents, in the specific sense of seeing them, attributing them to an owner and acting on them through the platform's own APIs. Six platforms are supported as of August 2026, one of them in preview. The connections grant more than read access unless you deliberately narrow them, the sync is manual, and the deeper Entra and Purview controls need the SDK rather than a credential. Switch on the free inventory today because the metrics do not backfill, and size the paid tier once you can see what you are actually governing. The licensing detail, including why this is priced per user rather than per agent, is in our breakdown of Microsoft Agent 365 licensing and the agent registry.

Find your agent

Browse vetted, ready-made AI agents, deploy one in a click on your own stack, and run on any model. No lock-in.

Browse agents