Agent 365 Q&A: where the baseline stops, answered

Agent 365: The Good, the Bad, and the Ugly drew a lot of questions, some live and some through the Q&A panel. This is the full written record, with the context behind each answer.

We spent the session walking through Agent 365 on a live tenant, with an executive view of the risk and an architect's view of the operations. Our honest read is that Microsoft has moved quickly and in the right direction. For agents that are native to Microsoft and built new, Agent 365 is already a strong baseline, and it is worth saying that plainly, because the questions that followed were detailed and mostly about the edges rather than the core.

Those questions clustered around a handful of practical themes: which admin roles you actually need, how third-party and legacy agents are covered, how identity and licensing work, and how you clean up agents at scale. The through-line is straightforward. Agent 365 is strongest for native, newly built agents, and there is more to plan for where agents are older, built by everyday users, or running on other platforms. The answers below are here to help you get the most out of Agent 365 and plan for the parts it does not yet reach.

If you want the underlying argument first, read the deep insights recap, then use this page as the practical reference. You can also rewatch the full session on demand.

Admin roles and access

Which admin role do you actually need to use Agent 365? Is an AI admin role enough?

You do not need a new licence or a new role to start using Agent 365. It reuses the roles you already have.

To see what is in Agent 365, a global reader is enough. That is the level that gets you the registry and the inventory, so you can look at which agents exist, how they were built, and who they are shared with, without touching configuration. To configure something that actually applies a control, such as a conditional access policy for agents, you use the same Entra administrator role that already lets you create conditional access policies today. Anything Purview-related, such as data loss prevention behaviour, uses your existing Purview roles. In short, your basic Microsoft 365 admin permissions, read, write, and assign, cover the assignment of policies to agents.

The caveat is where that configuration happens. Everything beyond the basic view is still set up in the Defender, Entra, and Purview portals directly, not inside Agent 365 itself. That is the flip side of not needing new roles. Because Agent 365 is a front end over back-end services, the people who operate it still need real expertise across all three underlying products. If your Entra, Purview, and Defender knowledge sits with different people, or with no one in depth, that is a gap to close before you rely on Agent 365 for day-to-day governance.

The day-to-day reality of running Agent 365 is bound up with your existing identity and access processes. In a well-run tenant, roles are often granted just in time rather than held as standing permissions, so whoever operates Agent 365 needs the right activation in place before they can see or change anything. That is good hygiene. It is also a reminder to map who holds which roles across Entra, Purview, and Defender before you roll this out, so the single pane does not turn into a hunt for whoever can actually make a change.

There is a design choice underneath this worth naming. Agent 365 is described as a single control plane, but in practice it is four portals: Agent 365 itself, plus the three solution portals for Entra, Purview, and Defender. The role model follows that shape. Nothing new to assign is convenient, but the operating burden is spread across three products your team has to know well. When you plan ownership, plan it against all four surfaces, not just the Agent 365 front end, and be honest about where your depth of expertise actually sits today.

This was the most active thread in the Q&A, and it is worth being candid about what it surfaced. Several attendees pushed back that the AI Administrator role on its own was not enough. One reported that as an AI Admin they could not even see parts of the menu we were showing, specifically the Tools, Devices, and Marketplace areas. So while the principle holds that no new role is required, the practical reality is that the AI Admin role alone is insufficient for full visibility, and you are likely to need a broader tenant admin context to see and configure everything. Pinning down the exact minimum role for each part of the experience is something to test in your own tenant, because Microsoft has not yet documented it cleanly.

What Agent 365 covers across platforms

Are Foundry agents visible in Agent 365?

Yes, Foundry agents are visible, with one condition. They did not appear in our demo tenant because we are not currently participating in the Foundry program. If you are part of the preview, your Foundry agents show up in Agent 365, and you can manage them with the same Defender, Entra, and Purview capabilities that apply to other native agents.

This makes sense once you look at how Agent 365 draws its boundaries. Foundry sits alongside Microsoft 365 Copilot and Copilot Studio in the native tier, and that native tier is where Agent 365 is genuinely strong. Native agents get deep integration, real-time data loss prevention, native policy templates and blueprints, and they auto-sync into the Agent 365 registry without extra work. So a Foundry agent is a first-class citizen wherever the preview access is in place, rather than one you can only see from a distance.

The honest qualifier is the word preview. Foundry, still referred to under its older Azure AI Services naming in some places at the time of the session, is not yet in a settled, general-availability state for everyone, and visibility depends on your enrolment. If you are building on Foundry, or planning to, confirm your preview enrolment and then verify in your own tenant that the agents you expect to govern are actually appearing and receiving the controls you need. The native depth is real, but see it working on your own estate before you assume full coverage.

There is a strategic point sitting behind this practical one. The places where Agent 365 is strongest, Microsoft 365 Copilot, Copilot Studio, and Foundry, are also the places that deepen your Microsoft-native footprint. That is fine if a Microsoft-only agent strategy is genuinely where you want to be. It is worth pausing on if you also expect to run agents on other platforms, because the governance you get for Foundry will not extend to them in the same way. Strong native coverage and single-vendor concentration are two sides of the same coin, so weigh the depth against the direction you want your estate to take.

Can custom agents built outside Microsoft, but part of our own infrastructure, be governed by Agent 365?

This is the question that matters most for multi-platform organisations, and the answer depends entirely on the platform the agent comes from.

Four third-party platforms are supported out of the box: Vertex, Bedrock, Databricks, and Salesforce. Agents from those platforms can be brought into Agent 365 through registry sync, so they are discoverable and can be managed to a degree. For every other vendor, control depends on a software development kit. The SDK is free and framework-agnostic, which is genuinely good, but the vendor has to opt in and publish it to Microsoft so that their agents can be attached to your control plane. If the vendor does that, you get control. If they do not, you fall back to network and endpoint discovery only. You can see that the agent exists, but you cannot secure it or apply runtime controls to it.

Here is what that means in practice. Most agents in the wild today are probably over-privileged, and a large share of them sit outside those four supported platforms. Popular options such as Gemini, Claude, and OpenAI-based agents fall into discovery-only territory unless and until their vendors publish an SDK. This is a structural consequence of how runtime control works, not a temporary bug. No vendor can enforce runtime governance on another vendor's infrastructure, so Microsoft cannot police what happens inside a Google or an Anthropic agent at runtime, and neither can anyone else from the outside.

There is also a vendor incentive to understand here. Because coverage of anything beyond the four supported platforms relies on the vendor choosing to publish an SDK, you depend on a competitor of Microsoft deciding it is in their interest to plug into Microsoft's control plane. Some will, some will not, and the timing is out of your hands. Several of those competitors are also folding agent governance into their own seat price rather than charging separately for it, so their commercial incentive is to keep governance inside their own platform, not to hand it to Microsoft. That dynamic is unlikely to resolve quickly, which is why discovery-only is a lasting condition to plan around rather than a gap that closes on its own.

The practical step here is an honest audit of your own agent landscape. Sort your platforms into three buckets: natively covered, coverable through a published SDK, and discovery-only. That single exercise tells you how much of your real estate Agent 365 can govern, and how much of it needs a different answer. For most enterprises the discovery-only bucket is larger than expected, and that is the gap a vendor-neutral governance layer is designed to fill.

How is governance of Agent Builder agents handled by Agent 365?

Agent Builder agents are discoverable, so they will appear in your inventory, but you will not be able to enforce controls from Entra, Defender, or Purview on them. Enforcing those controls requires an Entra Agent ID, and declarative agents, which includes both Agent Builder agents and SharePoint agents, do not get one.

There is a licensing angle here too, covered below. Agent Builder agents are exactly the case where, to govern them through Rencore, you need a single Agent 365 licence. They are also the agents most likely to be built by ordinary users rather than power users, which is precisely why they matter for oversharing and shadow-AI risk, and precisely where you will want cover beyond the native tier.

Identity and the Entra Agent ID

Would moving an agent from one environment to another satisfy the requirement to recreate it for an Agent ID?

To take control of an agent you need an Entra Agent ID, and existing agents do not carry one. That is the root of the recreation requirement, and this question was about whether an environment move counts as recreation.

For a straightforward Copilot Studio agent, recreating or republishing it should do the trick and bring it into scope with an identity. Moving an agent from one environment to another is less clear cut, because it depends on what the move actually carries over. The likely behaviour is that the agent gets depublished and then published again in the new environment, and that republishing step is what would give it a new identity. So a transition between environments may satisfy the requirement, but only to the extent that it triggers a genuine republish rather than a straight copy of the existing object.

One part we cannot confirm. Agent capabilities nested inside Power Platform solutions were not tested during the session, so whether an agent capability inherited through a solution picks up an Agent ID on transition is unconfirmed. Treat that specific case as something to verify yourself rather than assume.

This connects to one of the bigger coverage issues. The recreation requirement is a real migration cost, and it lands hardest on exactly the agents you already depend on. Custom-engine agents built before the Agent ID existed have to be recreated to come into scope at all. Declarative agents, including SharePoint agents, cannot get an Entra Agent ID even after recreation, so they stay visible but ungoverned. So inventory your existing agents first, separate the ones that can be recreated for an ID from the ones that never will, plan the recreation work for the former, and decide how you are going to govern the latter, because Agent 365 on its own will not.

This is also where the difference between the two approaches shows up most clearly. Agent 365 asks you to bring agents into its model, which for legacy and declarative agents means recreation, or in the case of SharePoint agents no full coverage at all. A governance layer above the platform starts the other way round and governs the estate you already have, as it is, without asking you to rebuild it first. If a large share of your agents predates the Agent ID or was built by ordinary users rather than power users, that difference in starting point is not academic. It decides how much unglamorous migration work lands on your team before you get any control at all.

If agents built in Gemini or Claude have Managed Identities from Entra ID, are they discoverable in the Microsoft Admin Center?

A Managed Identity is not the same thing as an Entra Agent ID, and that distinction is the whole answer. An agent that has a Managed Identity would most likely appear as an app in your Entra ID registry, but it would not show up inside Agent 365, only in Entra ID itself.

From current experience, the only ways to display and control an agent in Agent 365 are for it to carry an Entra Agent ID, or for its third-party platform to be connected through the SDK. Having some form of Entra identity attached to a Gemini or Claude agent does not, by itself, bring it into the Agent 365 control plane. This is the same third-party boundary seen from a different angle, and it is worth checking against your own environment if you are relying on managed identities to keep track of non-Microsoft agents.

Licensing and cost

Which Rencore functionality needs an Agent 365 licence, and what Purview licences does Rencore need?

This question pins down the cost position, so here it is precisely. Without Purview you will not have sensitivity labels inside Rencore, but apart from that everything is available with standard E3 licences. To govern Agent Builder agents specifically, you need a single Agent 365 licence. For Copilot Studio agents and Microsoft Foundry agents, Agent 365 is not required at all.

The practical meaning is significant. You do not have to license every user on Agent 365 to bring agent data into Rencore. A single Agent 365 licence covers the Agent Builder case, the more capable Copilot Studio and Foundry agents need none, and the rest of the platform runs on the E3 licences you already hold. That is the difference between a contained, predictable cost and the open-ended licensing creep that makes Agent 365 hard to budget for on its own. It is also why the two sit together well rather than competing.

Working with Rencore alongside Agent 365

Is the agent data Rencore shows real time, or is it from exported reports?

Rencore scans on a daily, weekly, or monthly basis using the Microsoft Graph API, and the results of each scan are published to the Rencore inventory. The data is not near-real-time, and that is a deliberate design choice rather than a limitation. A full real-time display would run into API bandwidth limits, so a scheduled scan is the sustainable way to keep a complete inventory current across a large estate.

For governance, this is the right trade-off. You are building a continuously maintained inventory and entity model you can report on and write policies against, not a live monitoring stream. If you need a specific view refreshed sooner, the scan cadence is configurable, so you can tune how often each service is collected to match how fast that part of your estate changes.

Can Rencore automate lifecycle cleanup of unused agents, including their app registrations, permissions, and identities?

The question noted, correctly, that bulk cleanup of agents in Agent 365 is currently very limited, and asked whether Rencore could provide automated lifecycle management that identifies and removes unused agents and their associated resources based on configurable governance criteria. This is exactly what the demo set out to show.

Rencore handles the full create-to-retire lifecycle, not just the insight. Any resource, an agent included, can be caught by a policy when it violates a setting you have defined, and that violation can trigger an automated workflow. For agents, the actions available include blocking or unblocking, depublishing, and reassigning or handing over ownership. Those workflows can run fully automatically, or route a human step such as an approval to the agent's owner through a Teams app that looks and feels like Teams. So configurable, policy-driven cleanup of unused or non-compliant agents is core to what Rencore adds on top of Agent 365, rather than a feature on a roadmap.

What we could not resolve on the day

Not everything got a clean resolution, and it is fair to name what stayed open. An attendee running only the AI Administrator role could not see parts of the Agent 365 experience we were demonstrating, including the Tools, Devices, and Marketplace menus, and understandably felt the walkthrough was hard to follow without the right security context. That is a legitimate challenge. The honest answer is that we could not confirm the exact role needed for full visibility on the spot, and Microsoft has not yet documented it clearly. We are following it up directly with the people who raised it and will share what we find.

How to use these answers

None of these answers is a reason to avoid Agent 365. It is a reasonable baseline, and for native and newly built agents a genuinely strong one. Read them instead as a map of where the baseline stops, so you can plan for the parts it does not cover before those parts become a problem. The organisations that will handle agent sprawl well are the ones that know, today, which of their agents are native, which are legacy, which are citizen-built, and which live on other platforms, and have a plan for each.

Every one of these answers points back to the same conclusion. Agent 365 is a strong baseline for native, newly built agents, and there is more to plan for with legacy, citizen-built, and multi-platform ones. For the full argument, read the deep insights recap.