Automate the boring decisions. Keep the hard ones human.

Manual review feels safe until every useful idea is waiting for the same meeting. It isn't that the organisation doesn't care — the process just treats every agent as a special case, so a tiny personal helper, a department assistant and a production agent with write access all queue behind the same form and the same people.

That queue has a cost. Makers wait weeks for a decision that was never going to be hard, and some of them stop asking.

Good governance is when the obvious decisions can run without a meeting.

Start before the build

The worst time to govern an agent is after it exists. By then the maker has done the work, someone may already be using it, the business problem feels urgent, and the admin gets to choose between blocking something useful and accepting something half-understood. That is how governance turns reactive.

The better starting point is the idea. Before anything is built, ask the handful of questions that make an agent scoreable:

• What problem does it solve?
• Who is the business owner? (This separates the maker from the person accountable for the outcome.)
• Who will use it? (Audience size is your first risk signal.)
• What data will it read?
• What tools or actions will it call? (This is the line between answering questions and changing things.)
• Which channels will expose it?
• What happens if it's wrong?
• How will we know it still matters in a year?

A list or a backlog item with mandatory fields will do. The request just has to carry enough information to route the agent without starting from zero every time.

It matters more for agents than for a normal feature request because an agent idea carries a request for access, action, audience and accountability all at once.

What to score

A risk score is a set of boring questions answered consistently. For agents, start with these signals:

An MCP server, in that tools row, hands an agent a whole set of tools from a separate server in one move — often one you don't operate, which is why it sits at the high-risk end.

The score doesn't replace judgement. It removes the easy cases from the judgement queue. A green idea shouldn't wait three weeks for someone to say yes, and a red one shouldn't slip through because the maker wrote a charming description.

What a green agent still needs

Rules, just not a committee.

A low-risk personal agent can be pre-approved when it meets a known shape: built in a personal sandbox, sharing limited, authenticated users only, approved knowledge sources, no external channels, no write actions, no unmanaged HTTP calls, no sensitive data beyond what the user can already reach, and a named owner with an expiry date.

Sharing limits only take effect on agents that require authentication, and only on new shares — they don't remove access someone already has. That's part of why the green shape insists on authentication rather than treating it as a nice-to-have.

The maker gets a fast yes because the organisation already decided, once and in advance, what "safe enough to try" means.

Yellow means review the delta

Yellow is the zone that fills up. The agent isn't just personal any more: it helps a team, touches shared data, maybe needs a connector that's allowed in one place and not another, maybe needs limited write access.

Don't review the whole agent from scratch. Review the delta. Usually it's one thing: the audience widened from one maker to a team, or the agent moved from reading a SharePoint site to calling a Dataverse table, or it now drafts a record update that a human still approves before anything saves.

Ask what new risk the change introduced, and which control absorbs it. The answer is usually small — an environment move, a sharing limit, a data policy, a named owner with a review date. Sometimes it's no, not in this zone.

Red means production gate

A red agent deserves a real gate, because it's now part of a system other people depend on. The question is not whether it can be built, but whether it can be operated.

For a red agent I want to see at least:

• a business sponsor;
• an owner who is still employed and reachable;
• a support model;
• a clear data boundary;
• approved tools and connectors;
• a release path from dev to test to production;
• test evidence;
• audit and monitoring;
• an incident path;
• a retirement rule.

Automated scoring stops here, because a score can tell you an agent is high risk but it can't decide whether the organisation accepts that risk.

Where the score attaches

The score's first attachment point is the zone you already have: green stays in the personal sandbox group, yellow moves to the team build path, red goes through the enterprise managed path.

Sharing rules are asymmetric at this level. Editor can only be granted to named individuals and not to a security group, while Viewer can reach a security group where the control allows it. Data policies also reach further than most people expect: as well as channels and unauthenticated use, they can block Power Platform connectors used as tools, HTTP requests, skills, and event triggers.

Advanced connector policies flip the model rather than refining it. Instead of sorting connectors into business and non-business, you allowlist them, and everything not on the list is blocked from the moment you save or publish. Certified connectors — the ones in Microsoft's published catalogue — can be allowed or blocked at connector level and at action level, and an MCP server can be blocked whole. Custom connectors and HTTP aren't covered yet, and Copilot Studio's own governance connectors, the ones covering channels, authentication and knowledge sources, still fall under the older data policies.

Some of this is still moving, so confirm where each piece stands before it goes into a standard. In Copilot Studio the policy is still runtime-only: design-time enforcement is reaching Power Automate first, and Microsoft treats a workload's design-time release as the point the policy becomes generally available there. The version of the rule you set across an environment group — one set of rules covering many environments at once — is still in preview.

Make the release gate enforceable

A production gate shouldn't depend on someone remembering to run a check. Managed environments — where the admin, not the maker, sets the rules for everything inside — can enforce Solution Checker, the static analysis that flags risky patterns, at the moment a solution is imported into an environment. Warn mode lets the import through and hands the admin the findings. Block mode cancels the import when the checker finds highly critical issues.

That's the kind of boring control I like. It doesn't replace architecture review, but it catches the class of issues humans shouldn't have to catch from memory.

The same split works at every gate:

Measure the friction your controls create

Friction is measurable, and the numbers show you where controls are being worked around. Most teams measure risk and never measure the cost of their own controls, which is dangerous, because friction doesn't disappear when you refuse to look at it. It moves. A maker who waits too long builds somewhere else, and a connector blocked without explanation just gets routed around. Then everyone is surprised by shadow AI.

Start simple:

• time from idea submitted to first answer;
• time from approved idea to usable sandbox;
• how many green ideas were auto-approved;
• how many yellow ideas are waiting for review;
• the most common rejection reasons;
• repeated exceptions for the same connector or action;
• agents created outside the expected path;
• policies that block one route but allow the same outcome another way.

That last one is my favourite, because it shows policy debt. If one path is blocked and an equivalent path is open, you haven't reduced risk. You've just moved where people go.

Once a quarter, look at the top blocked actions, the exceptions and the abandoned requests. Then ask whether each control is still justified, whether it's applied consistently, what people are trying to do that your zones don't support, and whether a low-risk version of it could simply be pre-approved. Do it on that rhythm and it stays routine.

Inventory and intake answer different questions

The agent registry in the Microsoft 365 admin center shows total agents, agents without owners and unmanaged agents, filters by publisher, channel and platform, and carries risk signals aggregated from the security stack. Two caveats on that risk column: it surfaces high-severity signals only, so a zero is not an all-clear, and whether you see the column at all depends on your licensing.

Inventory also can't tell you why an agent should exist, whether three teams built the same helper, or whether the business owner still cares. That part only lives in the intake record.

How to contain an agent that crosses a line

An agent violates a data policy, ownership turns out to be unclear, a review finds missing compliance documentation, or a risk signal needs investigating. The answer is containment rather than panic.

A Power Platform API operation quarantines a Copilot Studio agent. The agent stays visible in Copilot Studio and makers can still interact with it in testing, but nobody can use it in any other channel while you investigate. It doesn't work on classic chatbots, which reject the call outright.

There's a delete operation too: today it covers only Agent Builder agents — the lightweight agent-building tool inside Microsoft 365 — not the Copilot Studio agents your makers build in environments. Deleting a Copilot Studio agent the ordinary way, inside Copilot Studio, does take its Entra Agent ID with it, the identity the agent acts under, but that's a maker action.

The admin levers that do reach a Copilot Studio agent are in the agent registry: Block stops anyone in the organisation using it across the Microsoft 365 surfaces, and you can reassign ownership there when the problem is an absent owner rather than the agent itself. For an agent published to a website or a Direct Line channel, quarantine is the one that stops it everywhere.

Build that path before you need it, and test it somewhere that isn't production.

Try this on one agent idea

Start with one agent idea that's floating around your organisation, and fill in these five answers from what you already have on file:

1. Who owns the business outcome?
2. Who will use the agent?
3. What data will it read?
4. What tools or actions will it call?
5. What would move it from green to yellow or red?

Every answer you have to chase the maker for is a question your intake should have asked first.