You've read the skill. Now govern it
When I say "AI skill governance," you probably picture a policy document. A risk register. A committee that meets fortnightly.
Forget that. The governance that actually keeps Copilot Studio agents safe is built from small, concrete decisions that look more like design than compliance.
Quick orientation if you didn't catch part one: the sort of skill we are talking about is a bundle of situational instructions — a runbook, a checklist, a way of doing one specific task — that an agent loads only when a request matches it.
1. The description is the most important control you have
It's tempting to treat the skill's name and description as a label, something you attach at the end without much thought, for humans skimming a list. They are not. The description is the routing signal: the text the agent's orchestrator reads to decide whether this skill fires. Nothing else selects the skill. The description does.
That makes it a control surface. A loose description like "HR help" invites the wrong skill to fire on the wrong request, or several skills to fight over the same one. A precise description is the enforcement. So you write it like a search query, not a tagline: name the domain ("HR leave eligibility triage"), say what it's for, and — the half almost everyone drops — say what it's not for.
The exclusion is what stops the skill reaching onto a neighbour's turf. You get 1,024 characters; the discipline is spending them on precision, not flavour.
Two checks turn this from vibes into something you can actually govern:
The two-maker test. Hand the description to a second maker. If the two of you would disagree on when the skill should fire, it isn't finished. Rewrite it. Disagreement between two reasonable people is the cleanest early signal that the orchestrator will be confused too.
The collision check. A description can be perfect on its own and still collide with another skill on the same agent. When two overlap, routing turns unpredictable: the agent picks one, not always the right one, and not always the same one twice. So before you add a skill, hold it against the agent's existing skills and confirm each task maps to exactly one. That only works if you keep a per-agent register of skills and their descriptions. Make sure to maintain one.
If you've done access governance, you'll recognise what this actually is. It's the "what is this allowed to be used for?" conversation.
2. The best control is the skill you never build
The second move never makes it into a governance framework, because it's about restraint: most of the time, the best control is not to create the skill at all.
Before you write one, ask these three questions:
Can the agent already work it out from the tools and knowledge it has? If a tool is well described, the model usually can — so don't write anything down.
Is it true in every conversation? Then it isn't a skill, it's an instruction; put it in the agent's always-on guidance.
Is it true only sometimes — a runbook, a regional rule, a report template? That, and only that, is a skill: kept out of the agent's default context and pulled in on demand when the task matches.
Most over-engineered agents fail the first question. They've written down things the model could have inferred, and each one is now a surface someone has to review, version, and watch. Restraint is a control. The skill you didn't create is the one you never have to govern.
The same instinct shows up a level up. A new task lands, and the reflex is to build a new agent. Usually it isn't three agents you need — it's one agent with three skills. Split off a separate agent only when the audience is different, the security boundary is distinct, or the agent has taken on so many tools that it's started picking the wrong one.
3. Govern by provenance, not by paranoia
Reading every skill with the same intensity doesn't scale, and it isn't even smart: a skill you wrote this morning doesn't need the scrutiny of one you pulled off the internet. So tier the review by where it came from.
Where the skill came from | How hard you look |
|---|---|
You authored it | Normal peer review. |
Reused from another environment | Full review and re-check it against the tools and data it can reach here. What was harmless over there may reach further in this agent. |
An AI generated it | Full review and a named person owns it and signs it off. "The model wrote it" is not an owner. |
Community or external | Approved sources only, full review and no bundled script reaches production without a human signing their name to it. |
But what exactly are you looking for?
Four specific things:
- instructions that try to override the agent's guardrails (injection),
- instructions that push a tool somewhere it shouldn't go (misuse),
- a gap between what the skill claims and what its code actually does (discrepancy),
- and secrets sitting in the files — there should be none, because skills point at connectors, they never carry credentials.
Scrutiny scaled to where a skill came from is how you say yes to community and AI-generated skills at all — not by trusting them, but by knowing exactly how hard to look before you do.
4. The controls live in the lifecycle — and every one is reversible
A skill rides inside its agent, and the agent rides the normal Power Platform lifecycle — built in a development environment, promoted through test to production inside a solution via a pipeline, with production locked down as a Managed Environment so only vetted deployments land there. The gate that matters sits just before production: an evaluation gate, which is nothing more than a set of representative prompts proving two things: the new skill fires when it should, and adding it didn't change which skill fires for everything else on the agent. That second half is the one people often forget. A new skill can break an old one's routing without anyone touching the old one.
And once it's live, you watch two behaviours: A skill that over-fires — jumps in on requests it shouldn't — almost always has a description that's too broad; tighten the "do not use for" half. A skill that under-fires — never gets picked — is too narrow, or worded in language nobody actually types.
You can see which skill the orchestrator chose, and why, in the agent's Chain of Thought. For the production record, agent activity is captured in Purview Audit, and the agents themselves are visible in the Agent 365 registry — so decide who reads that, and how often.
Two last reflexes. Set a saturation line: when an agent crosses an agreed number of skills and tools, stop and ask whether some of that work belongs in a separate agent, because accuracy slips as the load grows. And keep a kill switch: misbehaving skill, remove it; unsafe agent, disable it. Both take effect immediately.
None of this looked like governance
No risk register. No committee. The controls are a description written with care, a decision not to build, a tier based on where something came from, a gate of test prompts, a switch you can flip. Governance is the set of choices that make an agent behave predictably — and predictable is exactly what an auditor wants. The provenance review lines up with NIST AI RMF's Map and ISO 42001's supplier controls, the lifecycle gates with Govern, the monitoring with Manage, and the EU AI Act sits on top where it applies, assessed per agent.
But that's not why you build it. You build it so a maker with a good skill and a one-page standard doesn't have to wait for you.
So this week, take one agent and write that page: the three questions, the description rule and its two checks, the four provenance tiers, the evaluation gate, the kill switch. Keep it to a page someone will actually read.
0 comments