There is a sentence buried in Microsoft’s own IT controls guidance that most administrators have never read, and it is the single most important fact about agent governance:
By default, all users in your Microsoft Entra tenant will have Copilot Studio authoring access.
Read that again. Not administrators. Not a maker group. All users. Authoring access to the tool that builds agents is on for everyone in the directory until somebody turns it off, and turning it off is a deliberate change in a console most nonprofit IT leads have never opened.
Licensing still gates what a given person can actually ship. The lite agent builder inside Copilot Chat needs a Microsoft 365 Copilot license; the full Copilot Studio needs its own. But in a tenant that has bought Copilot seats, and most of the organizations reading this have bought at least a few, the practical answer to “can our development director build an agent that reads the donor database and drafts thank-you letters” is yes, this afternoon, without telling anyone.
Microsoft has a name for what happens next. They call it agent sprawl. We have watched it arrive in three tenants now, and it does not look like a breach. It looks like eleven agents nobody can account for, four of them pointed at SharePoint sites with permissions that were never cleaned up, one of them quietly burning through the organization’s Copilot Credit pool because a staff member scheduled it to run nightly.
What follows are the nine controls that prevent that. Seven live in the Microsoft 365 admin center or the Power Platform admin center. Two are policy decisions no console will make for you. We set these in week two of every Agent Launchpad, and we set them in this order, because the order is load-bearing: close the door before you inventory the room.
Close Copilot Studio authoring to a named security group.
Power Platform admin center → Manage → Tenant settings → Copilot Studio authors
This is the door. Change the default permission from everyone to a security group you control, and put three to five named people in it. Not the IT team by title, the people who have actually been trained to build an agent and know what a data source is.
Do this first. Every other control on this list assumes you know who the makers are. If the answer is “anyone with a mailbox,” you are not governing agents, you are counting them after the fact.
Decide who can create agents inside Copilot.
Microsoft 365 admin center → Copilot → Settings
Separate from Copilot Studio authoring, there is a control governing who can create agents from within Copilot itself. Set it to all users, no users, or specific users and groups. For most organizations under 200 staff, the honest answer for the first six months is a small group, and then widen it once you have seen what people build.
Read the fine print here. This control does not govern SharePoint agents. That carve-out is the reason for control six, and it is where organizations that believe they have locked things down discover they have not.
Decide which agents are allowed to run at all.
Microsoft 365 admin center → Copilot → Agents & connectors
Agents arrive from three places: built by Microsoft, built by external publishers, and built by your own organization. You can enable or disable each category, deploy or block any individual agent, and review agents your users have requested rather than letting the Agent Store operate as an open marketplace.
The external-publisher category deserves a decision at the board level, not the help desk level. A third-party agent is a vendor with read access to whatever the requesting user can see. The procurement question that applies to any other vendor with that access applies here, and there is currently no purchase order to trigger it.
Scope who can use each agent, and pin the good ones.
Microsoft 365 admin center → Copilot → Agents
Per-agent access is assignable by user or group. You can also pin agents, either organization-wide for the ones everybody should be using, or to a specific group for the ones that only make sense in a function.
Pinning is the underrated half of this control. It is a governance setting that doubles as the cheapest adoption intervention available: most staff never open the agent menu, and an agent nobody opens is indistinguishable from an agent you never bought. Pin Researcher and Analyst for everyone with a Copilot seat. Pin the finance agents to finance. See the catalog of agents you already own for what is worth pinning.
Cap how broadly an agent can be shared.
Power Platform admin center → Environments → Edit Managed Environments → Manage sharing
In a Managed Environment, you can limit how widely a maker shares what they built. Without it, the distance between “I made a thing for myself” and “the whole organization is now depending on a thing one person made for themselves” is a single click, and there is no review in between.
This is the control that keeps a personal experiment from becoming an unsupported production service. In a small organization the failure mode is specific and predictable: the person who built it leaves, and the agent that four departments now rely on has no owner, no documentation, and a connection string pointing at their OneDrive.
An agent nobody opens is indistinguishable from an agent you never bought.
Govern SharePoint agents separately, because nothing else will.
SharePoint Online file permissions · SharePoint Advanced Management → Restricted access control
A SharePoint agent is grounded in a site, and it is controlled by the file permissions on the agent file itself. Not by the Copilot agent controls. Not by the Copilot Studio authoring group. If someone can write to the site, they can create an agent that reads the site, and the levers in control two do not reach it.
The mitigation is unglamorous and it is the same mitigation as always: permissions hygiene on the sites, and restricted access control through SharePoint Advanced Management on the sites that hold anything sensitive. If you have not run an oversharing report, you do not know what a SharePoint agent would surface, and neither does the person who is about to create one.
Put a ceiling on what agents can spend.
Microsoft 365 admin center → Billing → Pay-as-you-go · Power Platform admin center → Licensing → Copilot Studio
Agent work beyond the per-seat license draws Copilot Credits from a pool held at the tenant. Two levers control the spend. Pay-as-you-go billing policies scope consumption to defined users and groups against a named Azure subscription, which also gives you departmental cross-charging. Prepaid message capacity lets you allocate a fixed number of messages and set what happens on overage.
Set one of them before the first agent goes live. A tenant-wide pool with no policy is a shared credit card with no limit and no name on it, and the first surprise invoice is the one that ends the AI program in a nonprofit. We wrote about the broader shift to usage-based billing in the note on Copilot Cowork.
Turn on the reporting that tells you what exists.
Microsoft 365 admin center → Reports → Copilot · Agent usage report
Two reports matter. The agent inventory gives you metadata on every agent in the tenant: capabilities, data sources, custom actions, certification status. The agent usage report gives you line-level data on users, agents, and user-agent pairs, broken out by publisher type, across both licensed and unlicensed users.
That last clause is the one to notice. Unlicensed users appear in the report. If you want to know whether anyone is using agents you did not sanction, this is where it shows up, and it is the closest thing to a shadow-AI detector Microsoft ships. On the broader problem, see shadow AI is already in your organization.
Write down the lifecycle and the kill switch.
No console. A document, and a name.
Every production agent needs a named owner, a business owner rather than an IT owner, and a review date. Ours is quarterly: is this agent still doing the thing, is the thing still worth doing, and has the process underneath it changed. Agents fail silently. A retrieval agent pointed at a SharePoint library that was reorganized six months ago will keep answering confidently, from stale documents, forever.
And write down the kill switch. Blocking an agent is a click in the Microsoft 365 admin center. Knowing who is allowed to make that click, at 6pm on a Friday, without waiting for a meeting, is a policy decision. Make it before you need it. The board does not need to know how to flip the switch. The board does need to know it exists, that a named person can operate it on a defined timeline, and that the condition that triggers it is written down.
None of these nine controls are expensive. Most of them are toggles in consoles the organization already pays for. The cost is not the license, it is the eight or so hours of an administrator’s attention and, more to the point, the decisions the administrator cannot make alone: who are the makers, which external publishers do we trust, what happens on overage, who owns the kill switch.
Those are governance questions, and they belong to the people who own the organization’s risk. That is what makes agent enablement different from the software rollouts that preceded it. The technology is genuinely easy. The technology being easy is precisely the problem: it removed the procurement friction that used to force these conversations to happen, and it did not replace it with anything.
The organizations that will do this well are not the ones with the best AI strategy. They are the ones that closed the door in control one before somebody built something they cannot explain to a funder, a regulator, or a board.
Set the baseline in six weeks.
Agent Launchpad takes you from Copilot license to a first production agent. The governance baseline, all nine controls, is week two, not a cleanup project after the incident.
See Agent LaunchpadFind out where you stand.
A two-week Discovery Sprint tells you which of the nine are set, what agents already exist in your tenant, and what is safe to enable now. Fixed fee, and the deliverable lands on Day 14.
Start a Discovery Sprint