Over the last couple of months, I’ve had the pleasure of teaching several classes on Microsoft Agent 365. One thing that has become increasingly clear through those sessions is just how nuanced this capability is.
Understanding Agent 365 means understanding a wide range of agent types, platforms, identities, data collection methods, and security tools. An agent created inside Microsoft 365 Copilot works differently from one built in Copilot Studio. An agent created in Foundry introduces another set of considerations. Then there are agents on other platforms, agentic services purchased from third parties, and AI services employees use independently.
Each brings different opportunities for visibility, governance, and protection. The body of knowledge needed to understand how these pieces fit together is broad and rapidly evolving. That makes the subject challenging to wrap your head around, but it also makes it exciting to learn and teach.
My goal with this article is to organize those pieces into a practical overview: what Agent 365 is trying to accomplish, where you are likely to encounter agents, and how the surrounding Microsoft services contribute to managing them.
Why Agent 365 matters
Microsoft introduced Agent 365 at Ignite on November 18, 2025, and made it generally available for commercial customers on May 1, 2026. Its purpose is to provide a central control plane for discovering, managing, governing, and securing AI agents across an organization.
The underlying problem is familiar. Employees can create agents, departments can subscribe to agentic services, and developers can build applications that access data and take actions with varying degrees of independence. Organizations need to understand which agents exist, who is responsible for them, what they can access, and what they are doing.
For organizations already heavily invested in Microsoft, particularly those with substantial Microsoft 365 E5 and Copilot adoption, I expect Agent 365 to become an increasingly important part of that management and security strategy.
Even if those organizations choose a third-party agent governance platform, they are likely to accumulate a substantial number of Microsoft agents. Those agents will emerge through employee-created assistants, departmental workflows, custom applications, and capabilities embedded in products they already use. Agent 365 will be the natural place to manage and monitor much of that activity.
The question, then, is how broadly an organization chooses to use it. Will Agent 365 primarily manage its Microsoft agent estate, or will it serve as the central agent governance and security platform for the enterprise?
If most of your agents are built on Microsoft platforms, using Agent 365 for that broader role makes logical sense. If your agent estate spans several platforms and service providers, you might choose another service to provide the overarching enterprise view. I would still expect Agent 365, or its foundational capabilities, to remain part of the Microsoft side of that architecture.
That relationship is similar to how I think about multicloud security. An organization might use Defender for Cloud to centralize visibility and recommendations across Azure, AWS, and Google Cloud. Another organization might choose a third-party platform for that enterprise view while continuing to use native security capabilities within each cloud.
In either arrangement, the platform hosting the workload remains important. Central oversight helps establish organizational standards and identify risk, while many of the most detailed configuration and enforcement capabilities remain within the underlying platform.
The same principle applies to agents: central governance and platform-level security need to work together.
What do we mean by an agent?
For this article, think of an agent as an AI-powered software capability configured to perform a particular role. It combines instructions with access to knowledge and, potentially, tools that allow it to take action.
A relatively simple agent might answer questions using a collection of SharePoint documents. A more capable agent might retrieve information from several systems, update a customer record, or initiate a workflow. An autonomous agent might perform those tasks in response to an event or schedule without waiting for someone to begin a conversation.
These capabilities exist along a spectrum. Even an agent that only answers questions can expose sensitive information if its access or underlying knowledge sources are poorly configured.
It is also useful to distinguish the agent from the model supporting it. The model provides capabilities such as interpreting requests, generating responses, and selecting actions. The agent provides the purpose, instructions, context, and connections that put those capabilities to work.
From a governance perspective, the useful questions are practical ones. What is this agent intended to do? Who is responsible for it? What information can it access? Which tools can it invoke? Does it act using a person’s permissions, or does it have access of its own?
A note about “developing” an agent
The word development can imply technical expertise, deliberate architecture, and a structured process of planning, implementation, and testing. Sometimes that accurately describes how an agent was created. Sometimes it does not.
In a low-code environment, creating an agent can be as simple as providing a natural-language system prompt, a statement of purpose, or a goal. Someone can produce a working agent without writing application code or thinking of themselves as a software developer.
That is one reason we often refer to these creators as makers rather than developers. Throughout this article, creating or developing an agent should not be taken as evidence that a formal software engineering or security review occurred.
That accessibility is part of the opportunity, and part of the governance challenge.
Where will you encounter agents in the Microsoft ecosystem?
Microsoft provides several ways to build agents. For this overview, I find it useful to describe the three primary platforms by their typical audience and purpose, recognizing that their capabilities overlap.
Agent Builder
Agent Builder, available within Microsoft 365 Copilot, is the starting point for personal and team-level agents. Someone might create an agent to answer questions about a project or help with a recurring task. These agents can be shared more broadly, potentially reaching a department or the entire organization, but I generally think of them as individual or small-team solutions.
Agent Builder agents operate within the Copilot experience using the user’s access context. They currently do not use their own Entra Agent ID, but they still have native integration with Agent 365.
The cost of using these agents depends on your license and what the agent connects to. With Microsoft 365 Copilot, purchased separately or included in E7, eligible agent usage is covered without an additional consumption charge. With E5 alone, agents that use shared company information, such as SharePoint content, can generate consumption charges. Simpler agents that rely on instructions and public websites can be used without those additional charges.
Copilot Studio
Copilot Studio, part of Power Platform, is where I primarily think about building agents for the internal enterprise: company, department, or team-level services. These might support HR questions, guide employees through business processes, or connect to organizational systems to retrieve information and perform actions.
It provides a more extensive low-code environment, with connectors, workflows, and orchestration. New Copilot Studio agents receive Entra Agent IDs, and the platform provides native Agent 365 telemetry integration. You could create an external-facing Copilot Studio agent, but generally, I think of these as internal-facing solutions.
Building and publishing these agents requires the appropriate Copilot Studio access and billing configuration, or the included rights provided by Microsoft 365 Copilot, purchased separately or through E7. Those included rights support agents within Microsoft 365, while standalone Copilot Studio provides broader publishing options. A trial allows development and testing but does not allow publication.
Copilot Studio also offers a newer GitHub Copilot harness, the underlying engine that coordinates an agent’s reasoning and tool use. Despite its name, this operates within Copilot Studio and is separate from the GitHub Copilot subscription service. Agents using this harness consume Copilot Credits, including during billable development, testing, evaluation, and runtime activity. These costs are separate from the usage included with Microsoft 365 Copilot, so having E7 does not mean all Copilot Studio consumption is covered.
Microsoft Foundry
Microsoft Foundry is where I think about creating more advanced agent services for a department or organization, customer-facing applications, and backend processing. These agents might coordinate complex tasks, operate within a larger application, or perform work without a conversational interface.
Foundry is often described as a pro-code platform because it supports advanced development, including complex agents, custom application code, and model training or fine-tuning. But it also supports low-code development. You can easily build an agent entirely through the portal by choosing a model, providing instructions, and connecting tools, without writing custom code. Both approaches are available, depending on how much flexibility and control your solution needs.
Foundry is an Azure service, with resources and projects associated with an Azure subscription. Authorized administrators and developers can provision and manage those resources through the Azure and Foundry portals, development tools, or code. With appropriate permissions and modest consumption, it is possible to create and test Foundry agents at very little cost.
Rather than purchasing a per-user Foundry license, organizations pay for the Azure services they consume. For many agents, a major cost is the input and output tokens processed by their models. Other charges can include agent hosting, search, storage, tools, and supporting infrastructure. Some model deployments use provisioned capacity rather than per-token billing. These costs are billed through the associated Azure subscription.
Other Microsoft agent experiences
These three platforms are only part of the Microsoft agent ecosystem. You will also encounter agents in SharePoint, Fabric, Dynamics 365, Microsoft 365 Copilot, and Security Copilot, including security agents associated with Project Perception.
Some are ready-made capabilities, while others can be configured or extended by the organization. An agent estate can therefore grow through the products employees already use, even without a formal agent creation initiative.
How the Agent Store brings these together
Employees do not have to create their own agents. They can find agents made available to them in the Agent Store inside Microsoft 365 Copilot and add them to their own experience. Although this is sometimes described as installing an agent, it is helpful to think of it as bookmarking an existing service for convenient access.
The main categories are ready-made agents from Microsoft or third-party providers that administrators have allowed, and agents created internally using Copilot Studio or Foundry and published for organizational use. Custom-developed agents built with SDKs or other platforms can also be integrated into Copilot and distributed through the store.
Agent Builder agents can also be published to the store with administrative approval. Given their simpler capabilities and typical personal or team-level use, however, I would not expect most organizations to publish large numbers of them in the organizational store.
For internally created agents, deciding which ones should be advertised through the organizational store is part of agent governance. Broad organizational publication goes through an administrative approval process, and administrators control availability and can block access. Agents can also be shared with specific people through a link, subject to the applicable permissions and organizational policies.
The store makes available agents easier to discover and bookmark. Instead of remembering a URL or knowing whom to ask, employees can browse the available services and add the ones relevant to their work. This helps extend an agent’s usefulness beyond its original creator or immediate team.
Importantly, publication in the Agent Store is not a prerequisite for an agent to operate. Foundry agents, in particular, can provide backend processing or support applications without appearing in Copilot at all. These agents remain subject to the organization’s creation, deployment, and security requirements, but listing them in an employee-facing store would serve little purpose.
This is why the Agent Store and Agent Registry serve different purposes. The store presents agents employees can discover and use through Copilot. The registry supports administrative inventory and governance across the broader agent estate. In an organization with substantial backend and custom agent development, the store may represent only a small subset of the agents visible in the registry.
Beyond Microsoft’s cloud agent platforms
The broader picture includes agents running on employee devices, agents our organization operates on other platforms, and externally operated services that our people use. Each requires a different approach to visibility and control.
Locally installed agents
Locally installed agents are installed or device-resident software that uses AI on servers or client devices, such as desktops, laptops, tablets, and phones. Over time, we may need to extend that definition to AI-enabled network equipment, smart screens, IP phones, printers, and other connected devices.
Agent 365 uses Intune and Microsoft Defender for Endpoint to discover supported local agents. Global Secure Access and Defender for Cloud Apps can provide additional insights into their network connectivity and the AI services they access. The breadth of the local-agent concept should not be confused with current discovery coverage, which depends on the operating system, agent, and configured integration.
For this introduction, we can think about two overlapping groups: general AI-enabled software running locally, and more agentic tools that can build, develop, create, and execute tasks, such as OpenClaw, Claude Code, and GitHub Copilot. These agentic tools are a particular focus of the local-agent and Shadow AI management experiences.
Agents our organization creates on non-Microsoft platforms
These include agents created or deployed using services such as Amazon Bedrock, Google Vertex AI, or Databricks. Much like our Foundry agents, these are services for which the organization has responsibility for their creation, configuration, or operation.
These platforms can include AI hosting services comparable to Foundry, as well as low-code agent builders comparable to Copilot Studio or Agent Builder. Organizations might, for example, create agents within ServiceNow, Salesforce, or Google’s platforms.
Agent 365 supports connections to selected external platforms for registry visibility and, where supported, activity monitoring. The depth of integration varies. Bringing an agent into a central inventory does not replace the configuration and security controls available within its hosting platform.
Enterprise AI services
Enterprise AI services are services the organization has authorized and acquired the right to use, usually through a subscription or licensing agreement. Access might be assigned to employees and connected to organizational identities through federated sign-in. Examples could include an enterprise AI assistant or agentic capabilities embedded in a purchased business application.
In this arrangement, we generally do not create or operate the provider’s underlying agents. Our responsibility centers on who can use the service, what organizational information it can access, and which administrative and security controls the provider makes available. Enterprise authorization gives us a managed relationship with the service, but the available visibility still depends on its integrations and capabilities.
Public and personally acquired AI services
Employees might use a free AI website, sign up for a personal subscription, or encounter AI features embedded in a search engine, browser, or another public service. These services may be intentionally selected or simply part of an everyday experience.
Here, our primary concern is governing access and protecting organizational information. Defender for Cloud Apps helps discover AI application usage and assess service risk. Global Secure Access adds network visibility and controls over traffic routed through it. Its shadow AI discovery uses the Defender for Cloud Apps catalog to identify AI services being accessed.
Across these categories, our relationship with agents varies considerably. We create agents for personal productivity, organizational use, and external-facing purposes. We use agents we created ourselves, agents created for us, agents we own, and agents we have licensed access to use. We also rely on services whose creation and operation we have little or no influence over.
In that respect, agents are becoming much like websites. An organization might build its own, commission someone else to create one, subscribe to a business service, or simply use a public resource. All can become part of how work gets done, but ownership, visibility, and control differ. Our agent governance strategy needs to account for that entire spectrum.
The Microsoft security stack behind Agent 365
Agent 365 brings together capabilities from Microsoft Entra, Purview, Defender, and Intune, with its registry and central administrative experience in the Microsoft 365 admin center. Supporting services, including Defender for Cloud, Defender for Cloud Apps, and Global Secure Access, contribute to the broader agent security picture.
These services address different parts of the problem: identity, devices, data, applications, infrastructure, and incident response. Some provide capabilities directly within the Agent 365 experience. Others protect the resources agents use or help us understand AI activity outside the agents we manage.
Before looking more closely at the administrative experiences, it helps to briefly review those roles.
Microsoft Entra: identity and access
Entra is a critical foundation because identity is a primary security boundary for Microsoft 365 and Azure resources. Being able to reach a service over the network does not, by itself, grant access to the organization’s protected information. Users, applications, and agents need to authenticate and receive authorization.
This is why so much of Microsoft’s security approach centers on identity, including Conditional Access, multifactor authentication for people, and Privileged Identity Management. Public or anonymously accessible services exist, and some workloads use other authentication methods, but Entra governs access to the enterprise Microsoft environment.
For Agent 365, Entra introduces agent identity blueprints, individual Agent IDs, and optional agent users. It also contributes agent risk detection, identity governance, and Conditional Access policies. We will return to these concepts shortly because they are essential to understanding how agents obtain and retain access.
Global Secure Access: network access and visibility
Global Secure Access is part of Entra and extends identity-centered controls to network connectivity. It helps govern access to internet and private resources and provides visibility into supported agent traffic.
In the agent security story, it can help identify which services local agents communicate with and apply network controls to supported traffic, including configured Copilot Studio traffic. Its effectiveness depends on the traffic being routed through the service. It complements identity controls by addressing where an agent can connect.
You might think of Global Secure Access as an AI gateway for network requests from local agents and Copilot Studio.
Microsoft Intune: device management
Intune manages device configuration, applications, and compliance. Within Agent 365, it contributes to discovering and controlling supported locally installed agents.
For example, supported blocking actions in the Microsoft 365 agent management experience can create Intune policies that restrict how an agent runs on managed devices. This connects central agent governance with enforcement on the endpoint.
Microsoft Defender for Endpoint: endpoint protection
Defender for Endpoint provides endpoint detection and response, vulnerability management, and integration with Microsoft Defender Antivirus. It helps security teams understand what is running on devices and investigate suspicious activity.
Its role in agent security includes discovering supported local agents, assessing their exposure, and providing supported runtime protections. It also collects network activity that can be shared with Defender for Cloud Apps, connecting endpoint observations with an understanding of cloud application usage.
Microsoft Defender for Cloud Apps: application discovery and control
Defender for Cloud Apps helps organizations understand and govern their use of SaaS and web applications. Where Defender for Endpoint observes network connections, Defender for Cloud Apps helps translate those observations into recognizable application usage.
That distinction is useful for AI. Instead of seeing only a hostname or connection, we can identify the AI service being accessed, assess its risk, and understand its use across the organization. This is an important layer for discovering public, personally acquired, or otherwise unmanaged cloud AI services, including those employees access through a web browser.
Microsoft Defender for Office 365: collaboration security
Defender for Office 365 does not have a strong direct relationship with Agent 365, but it protects the Microsoft 365 communication services that people and agents use. An agent user might send and receive email or participate in Teams conversations, bringing its activity into the scope of the applicable collaboration security protections.
If an agent has an Exchange Online mailbox, that mailbox also needs protection against malicious attachments, harmful URLs, phishing, and other email-based threats. Defender for Office 365 Plan 2 includes detection of email-based prompt injection, helping prevent malicious instructions from reaching an AI assistant through inbound messages. This protects the communication channel before the agent processes the content.
Microsoft Defender for Identity: identity threat detection
Defender for Identity also has a limited direct relationship with Agent 365. It protects and monitors on-premises identity infrastructure, particularly Active Directory authentication, account administration, and suspicious activity involving domain controllers and other supported identity servers.
Although it is not primarily an AI security service, it remains a critical part of the Microsoft security stack. Agents and their users may depend on identities and systems connected to that infrastructure, making its protection relevant to the broader environment.
Microsoft Purview: data protection, compliance, and auditing
Purview focuses on the information agents access, process, generate, and share. Its capabilities include sensitivity labels, data loss prevention, data security posture management, insider risk management, retention, and eDiscovery.
Purview also provides an important auditing platform for supported agent activity. Agent-related records in the unified audit log help organizations investigate how agents interact with company data and assess whether those interactions meet organizational requirements. We will return to Purview when we discuss agent telemetry, data protection, and auditing in more detail.
Microsoft Defender for Cloud: cloud infrastructure and AI workloads
Defender for Cloud helps secure the cloud infrastructure and services supporting an AI solution. In Azure, that can include Foundry resources as well as supporting storage accounts, key vaults, compute, and other resources, depending on the protection plans enabled.
It also includes AI-specific security posture assessments and workload threat protections, including alerting for supported AI services. At a high level, Agent 365 focuses on governing and protecting the agent or agentic application, while Defender for Cloud helps secure its underlying cloud environment. Their capabilities complement each other and can overlap around AI workload protection.
This distinction matters because the infrastructure behind Agent Builder and Copilot Studio is operated and protected by Microsoft. Customers still manage their agents, access, connections, and policies, but they do not administer the underlying hosting infrastructure. In Azure, organizations have considerably more configuration flexibility and therefore more responsibility for securing the resources that make up their AI solutions.
Microsoft Sentinel: enterprise security analytics and retention
Sentinel is Microsoft’s security information and event management, or SIEM, platform. Agent 365 does not depend on Sentinel, but organizations can use it to extend their agent monitoring and investigation capabilities.
An Agent 365 connector brings supported agent telemetry into the Sentinel data lake for investigation of agent behavior, tool usage, and execution. Other connectors can bring in related Microsoft 365 audit and security data. With the appropriate collection and retention configuration, Sentinel can support longer-term retention, broader investigations, and custom detections where the data is available to analytics rules.
Purview remains an important source of agent audit activity through the unified audit log. Sentinel provides an additional place to retain and correlate selected data with information from other clouds, business applications, and security products.
Microsoft Defender XDR and the Defender portal: coordinated investigation and response
The Defender portal provides a centralized operational experience for investigating and responding to security incidents. Defender XDR correlates related alerts and activity, helping investigators connect events across identities, devices, applications, and other resources.
For Agent 365, an important capability is presenting supported agents from the broader inventory as identifiable security entities with their own profile pages. These pages bring together available configuration, identity, risk, recommendations, alerts, and related context. This makes an agent something an investigator can discover and examine during an incident, alongside the users, devices, and resources involved.
The Defender portal is also where security teams configure supported agent real-time protection policies and investigate related detections. These controls can audit risky activity or block supported actions before execution.
Together, these services explain why learning Agent 365 requires familiarity with several parts of the Microsoft stack. The registry brings agents into view, while the connected services contribute the controls and evidence needed to govern and protect them.
A brief licensing distinction
Before exploring the portals, it is worth separating foundational agent administration from premium Agent 365 capabilities.
Microsoft includes some foundational capabilities, such as Agent Identity, Agent Registry, basic usage insights, and supported administrative governance actions, with qualifying Microsoft cloud subscriptions. Premium Agent 365 capabilities require additional licensing, available through a standalone Agent 365 subscription or Microsoft 365 E7. Underlying service prerequisites also apply.
Agent 365 is licensed per user, rather than per agent. Microsoft’s guidance distinguishes required coverage for users delegating access and the owners, sponsors, or managers of agents operating with their own access from its recommendation for broader coverage. Interacting with an agent does not automatically mean every employee must have E7, because standalone Agent 365 is also an option.
Consider a retail employee who primarily checks email, benefits, and pay information. That employee might have little involvement with agents. As agentic services become embedded in everyday applications, however, the population needing coverage could become much larger.
My expectation is that many organizations will eventually consider broad coverage for operational simplicity. E7 should also be evaluated on its broader value, including Microsoft 365 Copilot and Entra Suite, rather than treating Agent 365 as the only reason to consider it.
A closer look at the four primary work areas
With that foundation, I want to revisit the four primary administrative experiences you will interact with when using Agent 365: the Microsoft 365 admin center, Microsoft Entra admin center, Microsoft Defender portal, and Microsoft Purview portal.
There are other important areas worth exploring. Defender for Cloud protects supported AI workloads and the Azure resources behind them. Defender for Cloud Apps helps monitor AI application usage. The Power Platform admin center governs Copilot Studio environments, connectors, and policies. Intune contributes device management and controls for supported local agents.
For the sake of this article, however, we will concentrate on the four core experiences, then discuss third-party agent integration before wrapping up.
Microsoft 365 admin center: the registry and organizational governance
The Microsoft 365 admin center is where the Agent Registry resides. It is also where administrators manage Copilot as a service, administer Microsoft 365 users, and assign licenses.
The users you see here are the same organizational identities you see in Entra. These are different administrative views of the same directory, rather than separate lists of Microsoft 365 and Entra accounts. You can create users and assign licenses from this portal, while Entra provides the deeper identity and access management capabilities.
For Agent 365, the main area to explore is the registry. If your environment contains them, open an Agent Builder agent, a Copilot Studio agent, and a Foundry agent record. Notice the common structure of their records, but also the differences in the information available.
Depending on the source and integration, you can review the agent’s creator, ownership, availability, instructions, knowledge sources, tools, permissions, and activity. More detailed records can expose the instructions or system prompt that help define its behavior. Some fields or tabs may be absent or unpopulated because that platform does not provide the information or it has not yet synchronized.
These records are primarily a governance resource. They help answer practical questions: Why does this agent exist? Who is accountable for it? Who can use it? What information and tools can it reach?
This is also where you review requests for organizational publication, manage supported lifecycle actions, and configure agent availability and sharing settings. The associated Tools area provides centralized management of supported tools, including MCP servers, and requests to make tools available. This complements the connector and environment controls maintained in Power Platform.
Blocking deserves particular attention because its effect depends on the agent. For Agent Builder and Copilot Studio agents, blocking affects availability and functionality in Copilot and supported Microsoft 365 host products. For Foundry and SharePoint agents, the documented block action affects availability in Copilot Chat.
Blocking access through Microsoft 365 should not be assumed to disable the underlying identity or stop every execution path. Disabling an identity or stopping a hosted service is a separate control.
It is also important to distinguish knowing an agent exists from having a connected, observable agent. A discovered or synchronized registry record may provide inventory information without detailed runtime activity or the full set of security controls. Deeper integration can provide identity, telemetry, and supported enforcement capabilities. We will return to this distinction when discussing external agents.
The registry provides a shared foundation for other experiences, including Defender and Purview. Those services present the agent estate through their own security and data protection perspectives, so their views and available details will not necessarily be identical.
Microsoft Entra admin center: the agent’s identity and access
Entra is where we examine the identities behind agents: agent identity blueprints, individual Agent IDs, and optional agent users. It is also where we review relevant sign-in and audit logs, identity risk, permissions, and Conditional Access policies. Global Secure Access is administered within the Entra experience as well.
The identity model deserves an article of its own, but three concepts are enough to establish the foundation here.
An agent identity blueprint provides the shared identity configuration and authentication foundation for a type of agent. An agent identity, commonly referred to as an Agent ID, represents an individual agent. An agent user is an optional associated user account for scenarios requiring capabilities such as a mailbox or participation in Microsoft 365 experiences. Not every agent requires an agent user.
These identity objects also provide lifecycle controls. Disabling an individual agent identity can prevent it from obtaining new tokens, while disabling a blueprint can affect the associated family of agents. Where an agent has its own user account, that account provides another point of control. These actions can restrict the agent’s ability to authenticate to Microsoft services, although they do not necessarily stop the application itself or immediately invalidate existing access tokens.
Agent identities and blueprints also have sponsors: accountable human contacts who help oversee the agent’s purpose and continued use. A sponsor can help authorize lifecycle decisions, such as whether an agent is still needed, should retain access, or should be disabled. This gives administrators a responsible person to consult rather than relying solely on the original creator or interpreting log data to decide whether to keep an agent.
At a simplified level, the application uses credentials configured through the blueprint to obtain tokens for an associated agent identity. Where supported and configured, it can also operate through the agent’s associated user account. This does not provide unrestricted access to arbitrary identities or users; the relationships, permissions, and consent still govern what it can do.
Those tokens can serve different purposes. One can authorize the agent to submit telemetry to Agent 365’s observability service. Another can authorize access to a business resource, such as Microsoft Graph or an Azure service. Authenticating an agent does not automatically mean its activity is being logged: the telemetry integration must also be configured and sending the required data.
For resource access, the agent might act on behalf of a signed-in person, operate with its own application permissions, or use its associated agent user account. That distinction affects whose permissions apply and how the resulting activity is attributed.
Conditional Access adds policy evaluation to supported authentication flows. Administrators can target agent identities or blueprints and apply controls based on supported conditions, including identity risk. Policies for an agent identity and policies for its associated agent user are not interchangeable. Likewise, an operation using an API key does not pass through Entra’s token issuance process and cannot be assumed to receive the same Conditional Access evaluation.
The practical purpose is to give agents identifiable, governable access rather than treating them as an indistinguishable extension of whoever created them.
Microsoft Defender portal: agents as entities in an investigation
The Microsoft Defender portal provides the security operations perspective. It brings together Defender XDR and other connected security capabilities, including Sentinel where integrated.
Supported agents appear in the agent inventory with profile pages containing available identity, configuration, tools, risk indicators, recommendations, and alerts. The information varies by platform and integration, but the important change is that an agent becomes an identifiable security asset that an investigator can examine.
I find a crime-scene analogy useful here. An alert is like a piece of evidence, such as a fingerprint or a report that a car was stolen. An incident is the case that brings the related evidence together. The entities are the people and things associated with that case: the stolen car, its owner, and the suspected thief.
In a cyber investigation, those entities might be users, devices, IP addresses, applications, or agents. Some may be suspected perpetrators, others victims, and others simply associated resources that help explain what happened.
Making agents visible in that model helps investigators move beyond an alert to examine the agent involved. Who is responsible for it? What identity does it use? Which tools can it invoke? What resources are associated with it? What other suspicious activity has been observed?
The Defender portal is also where administrators configure supported Agent 365 security integrations and real-time protection policies. These policies can audit risky activity or block supported actions before execution. Detection coverage and the relationship between behaviors, alerts, and blocking depend on the agent type and configured protection.
This makes Defender both an investigation environment and a place to administer agent-specific threat protection.
Microsoft Purview portal: understanding agent activity and data use
Purview provides the data security, compliance, and auditing perspective. When the question is what an agent did with organizational information, this is an important place to investigate.
Depending on the platform and available telemetry, that investigation can include prompts, responses, accessed resources, tool activity, and data-related actions. Identity and user context can help establish whether an operation occurred on behalf of a person or through the agent’s own access. The depth of the record depends on what the source captures and supplies.
Purview’s Data Security Posture Management, or DSPM, provides AI-focused inventory, assessments, recommendations, and activity exploration. It helps identify agents with sensitive interactions and examine the data security concerns associated with their use.
It is useful to distinguish the audit record from the interaction content. Purview Audit provides searchable records of supported activities, while other Purview experiences provide access to captured prompts, responses, and related content where supported and appropriately authorized. We should not assume that every unified audit log entry contains the full conversation.
If you are accustomed to investigating logs in Sentinel, this arrangement may initially seem unusual. Agent 365 uses Purview as a central auditing and compliance experience, while observability, identity, and security records also support other Microsoft services. Selected data can be collected into Sentinel for additional retention, correlation, and analytics, but Sentinel is not a prerequisite for reviewing supported agent activity in Purview.
In practical terms, Defender helps investigate the security event, while Purview helps examine the information and interactions involved. A thorough investigation may require both, along with Entra and source-platform logs.
A leadership view: Microsoft Security Dashboard for AI
There is also a higher-level experience for stakeholders who need to understand the organization’s AI estate and risk without performing day-to-day administration.
The Microsoft Security Dashboard for AI brings together inventory and risk information from connected Microsoft security services. It helps security leaders understand which AI assets are visible, their current posture, and where attention is needed.
Access still requires appropriate permissions, but leaders do not need broad administrative rights to change policies. Microsoft recommends the Security Reader role for leaders needing full dashboard visibility. The dashboard provides an overview and links into the specialist services for deeper investigation and remediation.
Bringing external agents into Agent 365
The last piece of this overview is how agents outside Microsoft’s platforms become part of the Agent 365 picture.
There are two main integration approaches to understand: connecting to the platform that hosts the agents, and integrating capabilities into the agents themselves. These approaches provide different levels of visibility and can be used together.
Connecting to the hosting platform
Agent 365 includes connections to supported platforms such as Amazon Bedrock, Google Vertex AI, and Databricks Genie. These connections let administrators discover agents and bring information about them into the registry without changing each agent’s code.
At a basic level, this provides inventory: we know that an agent exists and can collect the metadata exposed by its platform. Where supported, the connection can also retrieve activity telemetry. The available detail varies by platform, and some observability capabilities remain in preview.
This gives the organization a broader view of its agent estate. Available configuration and activity information can support governance reviews, help identify gaps, and inform recommendations. However, a registry entry alone does not establish that an agent meets organizational standards.
The hosting platform remains important. These connections are primarily designed for visibility rather than general administration of the source environment. Microsoft documents a limited optional deletion permission for supported scenarios, but connecting a platform does not give Agent 365 unrestricted control over its agents.
There is considerable value in expanding these integrations. The more information a platform exposes through its APIs and telemetry services, the more oversight an organization can achieve without modifying individual agents. I expect this to remain an important area of investment across the industry.
Integrating the agent itself
When the platform connection does not provide the capabilities we need, another option is to integrate the agent more directly.
Microsoft provides an Agent 365 SDK and CLI to support this process. The setup can establish an agent identity blueprint and Agent ID, configure permissions, and connect the agent to supported Microsoft services. Microsoft’s OpenTelemetry integration provides the runtime instrumentation needed to send detailed activity into the observability service.
The identity can authorize telemetry submission and, with separately granted permissions, access to Microsoft 365 or Azure resources. Permission to send logs does not automatically grant access to organizational data.
This approach can provide visibility into agent invocations, model calls, tool usage, errors, and other instrumented activity. It can also add capabilities such as governed Microsoft 365 tool access or notifications. The SDK extends an existing agent; it does not replace its framework, host it, or take over its execution.
For custom agents, this can mean changing code, configuring authentication, adding instrumentation, and validating the resulting telemetry. That is much easier to describe than to implement across a large collection of agents built by different teams.
It is therefore worth checking the platform’s existing integration first. If built-in support or a platform connection already provides what you need, adding an SDK merely to register the agent may be unnecessary.
A familiar monitoring analogy
I compare this to monitoring virtual machines through a hypervisor versus installing a monitoring agent inside each operating system.
The hypervisor can tell us which virtual machines exist, their configuration, and useful information about their operation. But if we need detailed application behavior inside a virtual machine, we may need instrumentation within the operating system or application.
Agent monitoring follows a similar pattern. A platform API can provide valuable inventory and activity information. If it does not expose the detail we need, we have to collect that information closer to the agent’s execution.
This code-level approach also supports agents without a supported platform connector. An agent might run in a container, on a server, on-premises, or within a service Microsoft does not yet support through a native connection. If we control its implementation, we can use the supported identity and telemetry integrations to bring it into the Agent 365 experience.
The same visibility challenges apply across the industry
These challenges are not unique to Microsoft. Any service attempting to provide centralized governance across multiple agent platforms needs a way to observe what those agents are doing.
Three common approaches are:
- Collect information through the hosting platform’s APIs and telemetry services.
- Instrument the agent or its runtime.
- Route relevant communications through a gateway that can observe and control those requests.
Each provides a different perspective. Platform APIs expose what the provider makes available. Instrumentation reveals the activity it has been configured to record. A gateway sees the traffic passing through it, which may not include everything the agent does locally or through other connections.
A central governance service may combine these approaches. Its usefulness depends on the breadth and depth of those integrations, rather than simply whether it can display an agent in an inventory.
Monitoring is not the same as management
Seeing an external agent does not mean we can remotely stop it.
Disabling its Entra identity can prevent it from obtaining new tokens for Microsoft resources, subject to the authentication flow and existing token lifetime. That can cut off an important part of its access, but the application may continue operating elsewhere.
Similarly, a gateway can block communications routed through it. That can contain particular activities without shutting down the agent itself.
To change the agent’s configuration or stop it at its source, we generally need the hosting platform’s controls, either directly or through an integration explicitly authorized to perform those actions. Central oversight and platform administration remain connected responsibilities.
Choosing your enterprise agent governance platform
This brings us back to the question at the beginning of the article.
For organizations adopting Copilot, Copilot Studio, and Foundry at scale, I expect Agent 365 to become a natural part of the management and security stack. Even when another vendor provides the enterprise-wide governance view, the organization will still have Microsoft agents and Microsoft-native controls to administer.
The larger decision is whether Agent 365 will also serve as the primary governance platform for the entire enterprise agent estate.
My recommendation is to start with the platform closest to the majority of your agents, then evaluate how well it covers the rest. Consider the depth of its integrations, the telemetry it can collect, the controls it can enforce, and the operational effort required to maintain that coverage.
If most of your agents are in Microsoft platforms, Agent 365 is a logical candidate for that central role. If thousands of agents operate in AWS or across several other platforms, you may favor controls native to those environments or a third-party service with particularly strong coverage of your estate.
Either choice still requires the underlying platforms to be secured and administered. A central registry cannot replace every platform’s configuration, permissions, and runtime controls.
For many Microsoft-invested organizations, I therefore see two decisions: how to use Agent 365 for their Microsoft agent estate, and whether to extend it into their enterprise-wide governance platform.
That is also why this subject is so broad. Agents can be created through a few natural-language instructions or implemented as complex applications. They can operate inside Microsoft 365, on employee devices, in another cloud, or as services we subscribe to. Our ownership and influence vary, but the need to understand their access, activity, and accountability remains.
Agent 365 brings those questions into a connected management and security framework. Understanding how that framework relates to identities, telemetry, hosting platforms, and security controls is the foundation for using it effectively.