Microsoft Puts AI Agents on the Identity Org Chart: Agent 365 Brings AWS, Google, and Salesforce Agents Under Entra Control

Microsoft has shipped the third installment of its Agent 365 series, and the strategic message is hard to miss. The company wants to be the control plane for AI agents no matter which cloud those agents actually run on. With Agent 365 and Microsoft Entra, IT and security teams can now surface, identify, and govern agents operating across AWS Bedrock, Google Vertex, Databricks Genie, and Salesforce AgentForce, then manage them with the same Conditional Access machinery they already use for employees and apps.

For organizations running workloads across more than one provider, this is a notable play. The pattern echoes what Microsoft did years ago with identity for SaaS applications: rather than competing to host every workload, it positions Entra as the neutral identity authority that sits above the providers. Agent 365 applies that same logic to the fast-growing problem of autonomous and semi-autonomous AI agents.

What changed

Until now, agents created on different platforms lived in their own silos. An agent spun up in Amazon Bedrock had whatever permissions its builder gave it, governed by AWS IAM. An agent in Google Vertex answered to Google's controls. Security teams had little to no consolidated view of what AI was running, who built it, or what data it could reach. The result is the same shadow IT problem the industry spent a decade fighting, except the actors are now non-human and capable of acting on resources at machine speed.

Agent 365 introduces a registry sync that pulls agents from these external platforms into a single inventory. In the demo, Microsoft shows Bedrock and Vertex already syncing, with Databricks and Salesforce available as additional connectors. The catch, and it is an important one, is that syncing only gives you visibility that an agent exists. It does not tell you what the agent can access. Bedrock agents pulled into the registry show up as unmanaged, with a creation date and publisher but little else.

The fix is the Entra Agent ID. Developers use the Agent 365 CLI and SDK to mint an Agent ID and bind it to their agent. Because the mechanism is built on standard OAuth, Microsoft argues it works across platforms rather than locking the agent to Azure. Once an agent carries an Agent ID, it becomes a directory object, subject to Conditional Access policies, access packages, sensitive data protections from Microsoft Purview, and full lifecycle governance.

How the pieces fit together

The architecture rests on a concept called Agent Blueprints. A blueprint is a template for a class of agents, and it holds the credentials those agents use to authenticate. Permissions granted on a blueprint are inherited by every Agent ID built from it, which is how Microsoft intends to make governance scale. Instead of configuring permissions agent by agent, an identity admin defines them once on the blueprint and lets the child identities inherit.

Those blueprint credentials can be managed inside Entra, federated from an external identity provider, or system-managed through something like an Azure Managed Identity. That flexibility matters for multi-cloud teams who do not want every credential rooted in one vendor.

In the walkthrough, the example agent's permissions are not set on the agent at all. They flow from the parent blueprint: an Agent365.Observability permission to capture telemetry, plus Microsoft Graph permissions to read groups, users, and mail. Each agent also gets an agent sponsor, a named human responsible for it, which closes a common accountability gap where nobody owns the AI that quietly accumulates access.

Conditional Access, applied to machines

The enforcement story is where this gets practical. Microsoft demonstrates a Conditional Access policy that targets all agent identities and blocks their access to Entra-managed resources by default. This is the deny-by-default posture security teams have wanted for non-human identities. A newly synced Bedrock agent trying to look up a user account in the tenant simply fails, and the failure is legible from both sides.

From the Bedrock console, the developer sees invalid grant errors with a description pointing at the Conditional Access block. From the Entra sign-in logs, the identity admin sees the same event, the policies that applied, and the failure reason. That two-way visibility is the kind of audit trail that compliance teams have struggled to assemble for AI activity, and having it span an external cloud is the differentiator here.

To unblock the agent, the admin adds it as an exclusion on the block policy, searches by name, saves, and the agent's next attempt succeeds with least-privilege access. It is the familiar Conditional Access workflow, now pointed at a software actor instead of a person.

Provider comparison and the strategic stakes

Every major cloud provider has a native answer for agent and workload identity. AWS leans on IAM roles, resource policies, and increasingly Bedrock-specific guardrails. Google Cloud offers IAM and Vertex AI controls. Databricks and Salesforce each govern their own agent frameworks. Those native controls are deep within their own boundaries but stop at the platform edge. None of them gives a security team a single registry spanning all four.

Microsoft's bet is that the identity layer, not the hosting layer, is where consolidation will happen. For an enterprise already standardized on Entra for human identity, extending the same Conditional Access policies, access reviews, and sign-in logs to agents is a far smaller lift than stitching together four vendors' native tooling. The migration consideration is real: adopting Agent 365 means developers add the CLI and SDK to their build process and accept Entra as the consent authority, but it does not require relocating the agents themselves. They keep running on Bedrock or Vertex.

The trade-off worth weighing is concentration. Centralizing agent governance in Entra deepens dependence on Microsoft as the identity broker for your entire AI footprint, including the parts hosted on competitors. Organizations with a deliberate multi-vendor identity strategy should price that in. For shops already all-in on Microsoft 365 and Entra, the calculus tilts strongly toward adoption, because the alternative is governing AI agents through spreadsheets and per-platform consoles.

Business impact

The near-term value is risk reduction that maps to existing audit and compliance frameworks. Treating agents as first-class identities means they appear in the same access reviews, the same sign-in telemetry, and the same least-privilege conversations as users and service principals. For regulated industries, the ability to answer "what AI is running, who owns it, and what can it touch" with a single query is a meaningful operational gain.

The longer-term implication is governance posture as agents proliferate. As teams stand up dozens or hundreds of agents across providers, the blueprint inheritance model is what keeps permission sprawl in check. Define the guardrails once, and every agent derived from that template starts inside them. The deny-by-default Conditional Access stance ensures new agents are inert until someone deliberately scopes their access, which inverts the usual shadow IT dynamic where things work first and get governed later.

Teams evaluating this should start by syncing their external platforms to get an honest inventory of unmanaged agents, then work with builders to assign Agent IDs to anything that touches sensitive data. The full series and setup guidance live at aka.ms/EntraforAgents, and the broader Microsoft Mechanics walkthroughs are on the Microsoft Mechanics blog. The practical question for most organizations is not whether to govern AI agents as identities, but whether they want that governance to live with their identity provider or scattered across every cloud they happen to use.