Microsoft 365 Copilot Agent Builder - Governance Data and Admin Controls

Most of the conversations I have about Microsoft 365 Copilot Agent Builder start with someone in the business getting excited about what they can build. The conversation that needs to happen first, though, is usually with IT. Who owns these agents? What data do they touch? How do we stop someone publishing an agent that quietly indexes a SharePoint site full of HR data and shares it with the whole organisation?

These are reasonable questions and the answers aren't always obvious from the marketing material. I want to walk through what the Agent Builder governance story actually looks like in practice, because we've been through this exercise with several Australian clients now and the patterns are pretty consistent.

What Agent Builder Is From a Platform Perspective

Agent Builder lives inside Microsoft 365 Copilot. You access it from microsoft365.com/chat, office.com/chat, or the Teams desktop and web client. It is not available on mobile and it is not available everywhere Copilot runs. That's the first thing worth knowing because users will ask.

The agents you build with it are declarative agents. Think of a declarative agent as a customised version of Copilot with its own instructions, knowledge sources, and conversation starters. It runs on the same Copilot infrastructure as the base product. There is no separate runtime. If your Copilot is working, your agents are working.

This matters for the licensing conversation. Agents built with Agent Builder are included in your Microsoft 365 Copilot licence. You don't pay extra per agent, you don't consume Dataverse storage, and you don't need a separate Copilot Studio licence to make basic ones. The catch is that "basic" actually means quite a lot. You can pull in SharePoint content, OneDrive files, Microsoft Graph data, and content from Copilot connectors. For the majority of internal use cases that is plenty.

If you want Actions that integrate external services, custom logic flows, or anything closer to real backend automation, you need Copilot Studio. The line between the two products is genuinely blurry and I've watched teams make the wrong choice in both directions. Build something in Agent Builder, hit a wall, and then have to recreate it in Copilot Studio anyway. Or jump straight to Copilot Studio for something that Agent Builder could have done in twenty minutes.

How Data Flows Through the System

This is the bit that matters for security and compliance teams. Copilot Studio processes Agent Builder capabilities under the hood. That means data flow happens between Microsoft 365 and Copilot Studio when agents run. The data can include Microsoft 365 content, prompts, instructions, configuration, and the output generated by the agent.

For Australian organisations, particularly those in regulated industries, the question is always: where does that data live and who can see it? The short answer is that Microsoft's product terms and compliance commitments cover the integrated services. Your existing data residency and sovereignty arrangements with Microsoft 365 still apply. Copilot Studio in this context is not a separate environment your data is being shipped off to. It is the engine that runs the agent inside the boundary you already have.

Agents do not consume your tenant's Dataverse storage entitlement, which is a nice touch. I've seen organisations get caught out by Power Platform storage limits before and it's a tedious thing to manage. With Agent Builder you don't have to think about it.

For compliance requests around personal data and the right to be forgotten, agents follow the Copilot Studio personal data handling rules. If you're already managing those requests for Copilot Studio, the same processes apply.

Admin Controls That Actually Matter

The most important thing for IT to know is that Agent Builder can be turned off. Tenant administrators control whether users can create agents at all. The management surface is Microsoft 365 Integrated Apps, which is where you control agent availability the same way you control any other Copilot extension.

When we work with clients through our Microsoft AI consulting practice, the typical approach is to enable Agent Builder for a small group first. Often this is the IT team plus a few business champions. You let them build the first wave of agents, document what works and what breaks, and then expand access in stages. This isn't because the platform is dangerous. It's because Agent Builder is genuinely easy to use, which means people will create a lot of agents very quickly if you let them, and you'll lose track of what exists.

The other admin lever worth knowing is the web search policy. If you've disabled web content for Copilot at the tenant level, that policy takes precedence over what users configure in Agent Builder. They can toggle the Web Content option on in their agent's knowledge pane and nothing will happen, because the tenant policy blocks it. This is documented as a known UI limitation. In practice, users get confused because the toggle looks like it's working. Worth flagging in your internal training.

Network Requirements

One endpoint to know about: *.api.powerplatform.com over HTTPS. This is on top of the standard Microsoft 365 URLs and IP ranges. It handles agent authoring, configuration, publishing, and sharing. If your network team runs a strict allow list, this needs to be on it. Otherwise users see weird failures when they try to save or share agents and nobody can work out why.

For most clients with reasonably modern Microsoft 365 deployments this isn't an issue. It's the older, more locked-down environments where I've seen it cause problems. Worth checking before you announce Agent Builder to the broader user base.

The Limitations Worth Knowing

A few things that have caught clients out:

Auto-sharing SharePoint content only works with specific security groups. If you try to share an agent with everyone in the organisation and the agent reads from a SharePoint site, you have to manually update the file and folder permissions. The agent won't auto-grant access. Users get confused when the agent works for them but returns no results for colleagues.

Customer Managed Keys aren't supported. If your organisation requires CMK for everything, Agent Builder is off the table for now. Same with Lockbox. For some financial services and healthcare clients this has been a blocker that pushed them towards a more controlled rollout pattern through Copilot Studio with proper environment isolation.

You can't use Agent Builder agents in Teams chat. This catches people out constantly. You build a brilliant agent, and then your users want to invoke it from a Teams chat the way they would a regular bot. It doesn't work. The agent is available in Copilot chat, but Teams chat is a separate surface. If Teams chat integration matters, you need Copilot Studio or a different architecture.

The web content toggle behaviour mentioned above. Worth repeating because it's the most common support ticket I've seen on this product.

What to Tell Leadership

When leaders ask whether to enable Agent Builder, the honest answer is usually yes, with structure. The platform is solid, the data handling matches what you already have for Copilot, and the licence cost is zero on top of what you're already paying. The risk isn't the technology. It's the operational mess that comes from letting two hundred people build agents with no oversight.

A reasonable governance pattern looks like this. Enable Agent Builder for a small pilot group. Create an internal naming convention and a lightweight register of what agents exist. Make sure your SharePoint sites have correct permissions before they become agent knowledge sources, because Copilot agents inherit and surface those permissions exactly. Train your champions on writing good agent instructions, because most "bad agent" complaints are actually bad prompt design rather than platform issues. Then expand.

We help clients design this rollout through our Business AI strategy work and through hands-on Copilot training for the teams who will actually be creating agents. The technology is the easy part. The change management around it is where most of the time goes.

Getting Support When Things Break

When you do run into issues, the support process needs a few specific bits of information. The agent ID, tenant ID, environment ID, and session ID are all findable inside Agent Builder in the Help dropdown under Get Support. If the issue is in the agent preview pane, typing /debug in the chat box gives you diagnostic information to attach to your ticket.

This sounds trivial but it isn't. I've watched teams spend weeks back and forth with Microsoft support because nobody captured the right IDs at the time the issue happened. Train your support team to grab these first, before anything else, when an Agent Builder issue gets raised.

The Bottom Line

Agent Builder is genuinely useful and the governance story is more mature than people expect. The platform inherits your existing Microsoft 365 controls. The limitations are mostly things you can work around or accept. The bigger risk is rolling it out faster than your organisation can absorb the change.

For Australian businesses already on Microsoft 365 Copilot E3 or E5, the question isn't whether to enable Agent Builder. It's how to do it in a way that doesn't create an unmanageable sprawl of half-finished agents six months from now. Get that right and you've added a genuinely valuable capability with no additional licence cost. Get it wrong and you'll be cleaning up for the next two years.

Reference: Agent Builder in Microsoft 365 Copilot