Microsoft Agent 365: How It Fits Into Your Operating Model

The views and opinions expressed here are my own and do not represent Microsoft. This content is not official Microsoft documentation and is not supported by Microsoft.

Microsoft Agent 365 is finally giving organizations a single place to govern the AI agents running across their environment, but the question I keep getting on customer calls is not really about features. It is about people. Who owns the agent once it is built? Who decides if it can run? Who watches it in production? Where does my SOC fit, where does my Compliance team fit, and what does my existing IT admin actually do differently? After many years of consulting, I noticed that the first thing customers need in these conversations is not more product detail. It is a simple place to start. A picture of who does what, where each team plugs in, and how Agent 365 connects to the operating model they already have. So I tried to build the simplest possible foundation framework I could and capture it in a single diagram. The way I found it works best in a meeting is to put that diagram on the screen first, then explain the why and the how. The operating model diagram in section 01 below is that picture. The walkthrough and the commentary that follow it are the explanation. It is not official Microsoft guidance, and it is not a one-size-fits-all blueprint. Adapt it to your organization.

A quick scope note before getting into the picture. Microsoft Agent 365 is the control plane Microsoft provides to observe, govern, and secure the AI agents running across your Microsoft estate (Microsoft 365 Copilot, Microsoft Foundry, Copilot Studio) and the third-party agent platforms you connect to it (AWS Bedrock, Google Vertex AI, and others). It is the layer that ties together the Microsoft 365 admin center, the Agent Registry, Microsoft Entra, Microsoft Defender, and Microsoft Purview into one coordinated experience for IT and security leaders. You have probably seen the three pillars by now in every Microsoft deck and blog since the launch, so I will not pretend they are mine. Observe, Govern, and Secure come straight from the product.

ObserveVisibility layer

The centralized registry, agent activity, health, and role-tailored insights so leaders can see what is running and catch risk early.

GovernGuardrails layer

Lifecycle management, permissions, policies, and the reviews that keep agents aligned with your business and audit obligations.

SecureProtection layer

Entra enforces identity and risk-based access for agents, Purview protects the data agents touch, and Defender provides continuous threat detection and response on agent behavior.

If you also need the deep dive on the identity primitive that powers the Secure pillar, I covered that separately in the Entra Agent ID article. Agent 365 is the control plane. Agent ID is one of the building blocks inside it.

With that product context in place, here is the framework I use in customer conversations. After the diagram I walk through why each piece is there, how it maps to teams you already have, and the one thing that is genuinely new.

The framework in one picture

Read it left to right as one agent's lifecycle, and top to bottom as the teams that touch it. The four horizontal lanes are the roles (Builder, AI / IT Administrator, Security Administrator, Compliance / Data Officer). The three vertical bands are the control pillars (Observe, Govern, Secure). The boxes are lifecycle moments, the arrows are handoffs, and the dashed arrow at the end is the feedback loop that keeps the cycle alive. The boxes are orientative, not a strict count, some of them (especially the ongoing lifecycle actions) expand into many real tasks once you adapt this to your own organization.

The reason I keep coming back to this framework in customer meetings is that it changes the conversation from "what do we have to build" to "who already does this work." The honest answer for most organizations is that the roles already exist in some form. There are people building. There is somebody running the tenant. There is an IAM team that owns Entra and Conditional Access. There is a SOC that triages incidents in Defender XDR. There is somebody owning Purview, audit, and eDiscovery. What Agent 365 does is hand each of those teams one more thing to look at inside the tools they already use, and connect those tools to each other through the registry. There is no new platform to stand up and no new team to staff.

That said, this framework is intentionally generic. Every organization is different. In some companies the AI / IT Admin and the IAM team are the same person. In others the SOC and the IAM team report into completely different parts of security, and the Compliance Officer reports up through Legal rather than IT, so the approval queue and the policy ownership have to route differently. In regulated environments there may be a separate risk function that wants a seat at the Govern step. The point of the diagram is not to dictate the structure. The point is to give you a baseline picture you can put in front of your own teams and then redraw together. Ask each lane "who in our org is this?" and "do we want it to be?" The answers will not always match the labels I used, and that is exactly the conversation worth having.

If I had to point to the one thing that is genuinely new for most organizations, it would be the approval queue behavior in the Govern pillar. Whoever ends up owning that queue (call them the AI / IT Admin, call them whatever fits your structure) becomes the choke point that determines whether agents enter production with intent or by accident. Get that one decision right and the rest of the framework starts to take care of itself.

Walking the lifecycle

The diagram tells the story of one agent moving through the lifecycle. The clearest way to read it is to follow that story in three movements, one for each pillar. The first movement is about seeing the agent. The second is about deciding what happens to it. The third is about protecting it once it runs. Everything ends in a feedback loop that brings the story back to the beginning. The steps you see are orientative, not exhaustive. Some of them (lifecycle actions especially) expand into many real-world tasks once you take this into your own operating model. Treat the diagram as a map, not a checklist.

Observe: the agent appears and gets catalogued

Everything starts with the Builder. A developer publishes an agent from Microsoft Foundry, a business user puts something together in Copilot Studio, somebody uploads a packaged ZIP, or a sync brings in an agent from AWS Bedrock or Google Vertex AI. From the Builder's point of view nothing changes about how they work. They use the tool they already use, click publish, and they are done. What is new is what happens on the other side. The agent is immediately picked up by the Agent Registry inside the Microsoft 365 admin center, with its source, its owner, and its identity attached. This is the single pane of glass for every agent in the tenant, and it shows up without the Builder having to file a ticket or fill out a form. The AI / IT Administrator sees the new agent the moment it exists.

If you map this to your existing operating model, the Agent Registry slots next to your existing app inventory. The same person who today reviews new SaaS apps in your tenant is usually the right person to review new agents. The cadence is where agents diverge from apps. Manual approval per agent does not scale, so lean on Agent Management Rules to handle the long tail in bulk (ownerless, low-risk, policy-clean) and keep the AI / IT Admin's time for the exceptions.

Govern: someone has to say yes

An agent that has been discovered is not an agent that has been allowed. The next two steps live in the Govern pillar and they are where most of the policy conversation actually happens. The new agent lands in a Pending queue and cannot move data in production until somebody approves it. Only the AI / IT Administrator (or Global Administrator as the backstop) can act on that queue, which is the deliberate control point you want. From there the same admin decides to install (approve), block, or delete the agent, and assigns a named business owner. That owner is who you call when something goes wrong and who is accountable for the agent's behavior. The lifecycle actions never end. Retiring an agent later, transferring its ownership, changing its scope, all of that comes back through the same admin and the same surface.

If you already approve new SaaS apps or new Teams apps in your tenant, you already have the workflow. Reuse it. The first addition worth making to your SOP is the line that says "assign a named owner before approving." Without that line, agents drift, and a year from now nobody remembers which team owns what. The second addition only applies if the agent is third-party (synced from AWS Bedrock, Google Vertex AI, or another platform): confirm someone has provisioned an Entra Agent ID for it before approving. Native Microsoft agents have this provisioned automatically at publish time. Third-party agents do not, and an approved agent without an identity loses every downstream control. I cover the why and how of this in the Secure section below.

Secure: identity, threat protection, and data protection

Secure is the part of the picture where the Microsoft story actually separates from the rest of the industry. The Secure pillar is not three different vendors that you have to integrate yourself. Entra, Defender, and Purview are one platform: the identity signal from Entra feeds the threat detection in Defender, the data classification from Purview feeds both Conditional Access and DLP, and the agent registry from Agent 365 ties all of it back to a single principal that every tool already understands. If you tried to build the same picture with point products from different vendors (an identity provider over here, an XDR over there, a separate DLP and a separate AI posture tool), you would spend the next eighteen months stitching connectors and reconciling identifiers. With Agent 365 it is wired up out of the box, which is the part most customers ask me to confirm when they see the diagram for the first time.

Once an agent is approved, it starts to look exactly like any other identity in the tenant. The Security Administrator lane in the diagram is intentionally one box, but in most real organizations that lane is two separate teams. The IAM / Identity team owns Microsoft Entra, which means they own the agent as an identity primitive: Entra Agent ID issues each agent a first-class principal, Conditional Access policies decide where and when the agent can authenticate, and Entra ID Governance handles access reviews and lifecycle. The same team that today owns Conditional Access for users owns it for agents tomorrow. In parallel, the SOC works the agent through Microsoft Defender XDR. Agent-related alerts and incidents land in the same queue the SOC already triages for users and devices, with the same severity, ownership, and response playbooks. There is no new console, no new on-call rotation, and no separate ticketing path. If you already have a Tier 1 / Tier 2 triage model in Defender, agents slot into it.

One important note for organizations bringing in third-party agents, and this is the deeper version of the SOP item I flagged under Govern. For native Microsoft agents (Microsoft 365 Copilot, Microsoft Foundry, Copilot Studio), the Entra Agent ID is provisioned for you as part of the publish flow. For third-party agents synced into the registry from platforms like AWS Bedrock or Google Vertex AI, that step is not automatic. Registry sync brings the agent into view inside the Agent Registry, but the agent does not get an Entra Agent ID until it is integrated through the Agent 365 SDK and configured against Entra (the sidecar pattern for Bedrock, federation patterns for others). The practical implication is the SOP control I mentioned earlier: before the AI / IT Admin approves a third-party agent, confirm that the Entra Agent ID has been provisioned. You want every approved agent to have a real identity before it starts authenticating and acting on data, otherwise everything downstream (Conditional Access, Defender signals, Purview audit) loses the principal it is supposed to enforce against.

In parallel, the Compliance or Data Officer takes over the data side of the agent through Microsoft Purview. A lot of what you already have keeps working. Agents run in the user's context, so the SharePoint, Exchange, and Teams DLP policies that already block a user from sharing sensitive content also apply when an agent acts on that user's behalf. Sensitivity labels with encryption are honored automatically, which means an agent cannot read content the user is not allowed to decrypt. The sensitive info types and trainable classifiers your team already maintains are the same primitives you reuse for agent-scoped policies. What is new is an additional layer on top of all of that. DLP for agents uses a dedicated Microsoft 365 Copilot location in Purview DLP so you can govern what an agent is allowed to process and what it can return in a response based on label, even when the user technically has access. DSPM for AI is its own surface in Purview that gives you the visibility into which agents are touching labeled content and how often. Insider Risk Management brings in a new Risky Agents policy template that watches for risky prompts, sensitive outputs, and risky data access by agents on Copilot Studio, Microsoft Foundry, and Agent 365. The honest framing for the Data Officer is this. Your existing controls do inherit, but the new agent-scoped surfaces (Copilot DLP location, DSPM for AI, Risky Agents IRM template) are where you tune the policies that are specific to AI. The good news is they live in the same Purview portal, the same audit log, and the same eDiscovery flow the team already uses for users. If your IRM program exists, agents are a new signal source inside it. If it does not exist, this is a good reason to start.

Back to Observe: closing the loop

The final step in the diagram is the Agent Map and Risk Insights view, which is the closing-the-loop dashboard. The AI / IT Administrator monitors it, the Security Admin and Compliance Officer act on what shows up there, and findings can move an agent right back into the Govern flow, into a tighter policy, or in the worst case into a Block or Delete action. The dashed arrow in the diagram that goes from step 8 back to step 2 is intentional. Discovery never stops. New agents keep landing in the registry while older approved agents keep generating new risk insights. The lifecycle is a loop, not a one-time onboarding checklist. The practical implication is small but worth being explicit about. The cadence I recommend is quarterly for high-risk agents, annual for the rest. Inventory itself should run on automated scanning, not a calendar review. Name the AI / IT Admin as the standing owner of that queue, and let the rules do the day-to-day work.