Copilot agents: the governance questions to answer first

A Copilot agent is a small, purposeful thing: a Copilot pointed at a defined set of content, given instructions, and published to a specific audience. That focus is exactly what makes agents useful, and it is also what turns three governance questions from theoretical into unavoidable.

In short: Before publishing a Copilot agent, answer three things in writing. Whose permissions apply when the agent reads data, and does the audience you are publishing to have the right to see everything in its knowledge source? Who owns the agent when the person who built it changes role? And what happens when it is confidently wrong, meaning who checks, who is accountable for the output, and how does a user report it? Agents inherit the permission model rather than replacing it, so an agent published broadly over a narrow source is fine, while one published broadly over a source containing anything sensitive is a problem.

Agents change the shape of the risk

General Copilot is bounded by the individual asking. Each person sees what they already had access to, which is why the SharePoint oversharing work matters so much before enabling it.

An agent is different in one important way: somebody chooses the knowledge source, and somebody chooses the audience. Those two choices are made once, by a person who may be thinking about usefulness rather than exposure, and then they apply to everyone who uses it. A well meaning agent built over "the HR site, because that has all the policies" and shared with the whole company is a very efficient way to distribute whatever else lives on the HR site.

Question one: whose permissions, over what

Get specific. For each agent, write down the exact sources and the exact audience, then check the intersection.

• Name the knowledge source precisely. A named document library, not "the intranet". Scope creep in the source is the most common way an agent becomes a problem after launch.
• Check the source is clean before pointing at it. An agent makes its source highly discoverable. If the site has old permission problems, the agent will surface them efficiently.
• Match audience to source, not to enthusiasm. The right question is not who would find this useful, it is who is entitled to everything in here.
• Decide what happens when the source grows. Someone will add a folder. Whether that folder automatically becomes agent knowledge should be a decision, not a discovery.

Question two: who owns it

Agents are usually built by a capable, motivated person in a business team, which is a good thing and a fragile one. That person changes role, and the agent keeps running.

Treat every published agent as having an owner, a review date and a purpose recorded somewhere central. Without that you accumulate a population of agents nobody can explain, each holding a standing pointer at company data, which is a harder version of the same problem as unowned SharePoint sites. It belongs on the same register and the same review cycle as your quarterly tenant health check.

Question three: what happens when it is wrong

Not if. Agents summarise, and summarising loses nuance. An agent trained on policy documents will eventually give a confident answer that is subtly out of date because the source was.

• Say what the agent is for and what it is not, in the agent's own description, where people will actually see it.
• Name a human owner for the answers, not just for the configuration. The principle from your AI use policy applies here too: a person owns the output.
• Give users a route to flag a bad answer that takes ten seconds. If reporting is harder than ignoring, you will never hear about the problem until it has spread.
• Keep the source current. Most bad agent answers are not model failures, they are stale documents faithfully summarised.

Start narrow, on purpose

The agents that succeed tend to be unglamorous: one team, one well maintained source, one clearly defined job. They are easy to govern because the answers to all three questions are obvious.

The ones that cause trouble are the ambitious ones built early, pointed at everything, and shared with everyone, usually to demonstrate the technology rather than to solve a problem. Resisting that for the first few months is the highest value governance decision available, and it costs nothing.

If you want help setting the guardrails before agents proliferate, or working out which processes are genuinely worth one, that is part of our AI advisory and enablement work. If you are earlier in the journey, is Copilot worth it covers the return question first.