Petri highlighted the pressure behind the feature: organizations are deploying agents through Microsoft tools, Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, and Databricks, often with separate owners, identity models, data access paths, and audit trails. Microsoft’s own Agent 365 documentation confirms the central premise and spells out the operational model more clearly than the initial report: the registry synchronizes agents and metadata from connected platforms into the Microsoft 365 admin center, where IT can view them alongside Microsoft-native agents.
The important correction is timing. Microsoft described Registry sync as generally available in its July 2026 Agent 365 update, rather than a newly announced September capability. Some Microsoft Learn pages still use preview language for adjacent Agent 365 integrations and transition guidance, so administrators should verify the status of the particular connector and management action they plan to use instead of assuming that “generally available” applies evenly across every function.
For Windows and Microsoft 365 administrators, Agent 365’s value is not that it makes a Bedrock or Vertex AI agent into a Microsoft agent. It creates a central record of the agent estate and links that inventory to the controls Microsoft already operates across Entra, Defender, and Purview. That can close a persistent management gap—but only for teams prepared to make agent registration, ownership, credential review, and periodic reconciliation part of normal IT operations.
Registry sync solves an inventory problem first
Agent sprawl is the agent-era version of shadow IT: business units can build or commission an agent quickly, but security, compliance, and central IT may learn about it only after it begins querying data, calling APIs, or taking actions in production. A chatbot with read-only access to a product catalog is a different operational object from an agent that can create support cases, reach into SharePoint, call a line-of-business application, or act through a delegated user context. A spreadsheet listing these projects becomes obsolete almost immediately.
Microsoft’s Registry sync addresses the inventory portion of that problem. Its Connected platforms documentation lists Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents, and Oracle Generative AI Agents among the supported sources. Microsoft said in July that Amazon Bedrock, Google’s Gemini Enterprise Agent Platform, Anthropic Claude, Databricks Genie, and Salesforce Agentforce were available at general availability, with Snowflake, Oracle OCI, and UiPath planned afterward.
That list is broader than the examples in Petri’s report, but it comes with a limitation that should shape deployment expectations: Agent 365 sees what an organization connects and synchronizes. It does not independently sweep every AWS account, Google Cloud project, Salesforce organization, or Databricks workspace tied to a company. An unconnected development tenant, a personal cloud account, or a platform that lacks a supported integration remains outside the registry.
Microsoft says administrators can configure synchronization on a daily or weekly cadence. Its more detailed Learn instructions say an administrator can trigger a sync after validating a connection and that scheduled synchronization is planned for a future release. Those statements are not necessarily incompatible—Microsoft may be describing different rollout states or connector behavior—but they are inconsistent enough that teams should test the actual cadence available in their tenant. A centrally displayed agent record is only as current as the last successful sync.
The connector credentials are part of the security boundary
The registry’s convenience depends on privileged connections into other vendors’ control planes. That makes connector setup a security design exercise, not a routine administrative checkbox.
For Amazon Bedrock, Microsoft’s setup documentation calls for an AWS access key ID and secret access key associated with permissions including the ability to list and retrieve agents, aliases, and versions. The same documented permission set includes bedrock:DeleteAgent, and the additional AgentCore permissions include deletion rights for harnesses, runtimes, gateways, targets, and memory. Microsoft also says Agent 365 can perform lifecycle actions, including deletion of synchronized agents, where a source platform’s APIs support them.
That means the actual authority of an Agent 365 connection is determined partly by the credentials the customer grants to it. An IT team that wants centralized visibility but is unwilling to permit cross-platform deletion should create a narrowly scoped integration identity and verify the exact role requirements with the platform owner. The safer default is to separate inventory and destructive-management permissions wherever a source platform allows it, rather than granting a broad administrative key because it is expedient.
The same principle applies elsewhere. Microsoft’s setup requirements call for Google Cloud credentials with access to Vertex AI resources, a Salesforce connected app using OAuth scopes and a user with API access, and a Databricks service principal with workspace administrative access. These are not passive telemetry feeds. Every connection establishes a managed trust relationship across vendors, identities, regions, secrets, and APIs.
A registry can therefore reduce blind spots while increasing the importance of access governance. The connection itself needs an accountable owner, documented purpose, secret-rotation process, review schedule, and a defined exit path if the project ends or the business unit moves its workloads. Otherwise, an enterprise can replace unknown agents with known agents attached to poorly understood credentials.
Microsoft’s common pane does not make policy common
Microsoft markets Agent 365 as a common management plane, which is a fair description of its administrative interface. It should not be mistaken for a universal policy engine that imposes identical enforcement on every external platform.
The company explicitly qualifies direct governance actions with “where supported by the underlying platform APIs.” In practical terms, that means an admin may be able to inventory, inspect metadata, assign ownership, review risk signals, or initiate a lifecycle action from Agent 365, but the source platform still determines what action is exposed and how it behaves. An agent’s runtime permissions, tool configuration, model settings, network path, logging retention, and data residency do not become uniform merely because the agent is listed in the Microsoft 365 admin center.
This distinction is where governance programs often fail. A central catalog makes it easier to ask the right questions, but it does not answer them automatically:
- Every production agent should have a named business sponsor and a technical owner who can explain its data sources, tools, intended users, and shutdown procedure.
- Every connected platform should have a documented mapping between its native roles and the permissions granted to its Agent 365 connector.
- Every agent should be classified by the highest-risk action it can take, rather than by its conversational interface or the department that created it.
- Every sync failure, orphaned agent record, and unexpected inventory change should enter an operational review process rather than disappear into an admin-center dashboard.
Microsoft’s own Entra Agent ID documentation supports this ownership-first approach. It describes each agent identity as a distinct Entra service principal, with sponsors responsible for the agent’s purpose and lifecycle. It also warns that a shared agent-identity blueprint shares credentials and inherited baseline permissions across the identities created from it. That is a concrete reason to treat an agent identity blueprint as a credential boundary, not a convenient template for unrelated workloads.
Licensing and role changes turn governance into a budget decision
Agent 365 is also not simply a free extension of whatever Microsoft security licenses an organization already owns. Microsoft’s Agent 365 overview says a tenant needs an eligible Microsoft 365, Microsoft 365 Copilot, or Microsoft Agent 365 subscription to manage agents in the Microsoft 365 admin center. The company’s licensing documentation says at least one user must hold a qualifying Agent 365 license to enable the service.
Microsoft has already made the commercial boundary more consequential. Its Defender transition documentation says that, effective July 1, 2026, several AI-agent security functions for Copilot Studio and Microsoft Foundry agents require Agent 365 eligibility. It says tenants without the required license lose access to listed discovery, posture, threat detection, real-time protection, and Advanced Hunting capabilities that had previously been associated with Defender products.
That change matters because Agent 365 does more than create a new console. It moves the registry toward being Microsoft’s stated source of truth for agent inventory and security observability. IT leaders planning a multicloud agent program should account for the license dependency before retiring existing discovery processes or promising a consolidated governance service to auditors.
Administrative responsibility is also deliberately restricted. Microsoft says critical actions such as approving agent requests and assigning ownership require the AI Administrator or Global Administrator role. That is sensible from a control standpoint, but it can create a bottleneck if an organization has hundreds of department-built agents and a small central admin team. The answer is not to hand out Global Administrator privileges to every AI project lead; it is to establish delegated workflows, ownership standards, and a triage model before the registry fills up.
Treat Agent 365 as the record, then verify the estate
The practical rollout sequence should begin with discovery rather than broad enforcement. Connect one nonproduction environment from each relevant platform, synchronize it, compare the registry against the platform’s own inventory, and document what metadata appears, what does not, and which lifecycle actions are actually enabled. Repeat the exercise after an agent is created, materially changed, disabled, or deleted to determine how long the registry takes to reflect reality.
Next, establish ownership and classify the agents that carry meaningful permissions. High-priority candidates include agents with access to Microsoft 365 data, customer records, financial systems, production APIs, source-code repositories, privileged cloud roles, or autonomous workflows. Those are the agents that should receive conditional-access review, logging expectations, incident contacts, and formal approval before the registry becomes a source of compliance reporting.
Microsoft has delivered a useful answer to a real enterprise problem: a way to put agents from competing and adjacent platforms into one governed inventory. The company has not eliminated the harder work of finding every environment, constraining connector credentials, reconciling different vendor controls, and holding a human owner accountable for every production agent. Organizations that do that work will gain a credible control plane; organizations that merely enable Registry sync will gain a better dashboard of an incomplete estate.