Copilot Agents · 5 min read
Microsoft's Agent Governance Toolkit: Three Questions to Ask of Any Agent
By James Wilkinson 8 August 2026
Microsoft's open-source Agent Governance Toolkit enforces agent rules in code, not prompts. Why that matters for firms that will never install it.
TL;DR
- Microsoft open-sourced the Agent Governance Toolkit in April 2026. It sits between an autonomous agent and its tools, checking every action against written policy in ordinary code, giving each agent its own identity and writing a tamper-evident audit log. Most firms will never install it, and it is still worth understanding.
- Its premise is the important part: an agent's instructions are a request, not a control. Rules that matter get enforced where the agent touches systems, so a denied action is impossible rather than discouraged.
- It gives every firm three questions to ask of any agent, managed or custom built: what exactly can it do in the systems it can reach, which agent did what, and where is the record that proves it.
Microsoft publishes a lot of developer tooling that businesses can safely ignore. The Agent Governance Toolkit, open-sourced in April 2026, is not quite in that category. Most firms reading this will never install it, and it is still worth ten minutes, because it says out loud what the industry has learned about agents doing real work: instructions are not enforcement.
What it is
The toolkit is a governance layer that sits between an autonomous agent and everything the agent can touch. Every tool call, message and delegation the agent attempts is intercepted in ordinary application code and checked against written policy before it happens. Each agent carries its own identity, so actions are attributable to a specific agent rather than a shared account. And every decision lands in a tamper-evident audit log: the request, the policy in force and any approval given.
It ships for Python, TypeScript, .NET, Go and Rust, plugs into the main agent frameworks including Microsoft’s own Agent Framework and Semantic Kernel, includes a security gateway for MCP tools and maps its controls to OWASP’s agentic AI risk list, NIST’s AI risk framework, the EU AI Act and SOC 2. It is MIT licensed, and Microsoft has said it intends to hand the project to a foundation.
None of that is aimed at a managing partner. The premise behind it is.
The idea that matters
The project’s documentation is blunt about why it exists. Telling an agent its rules in a prompt is, in Microsoft’s words, “a polite request to a stochastic system”. An agent will usually follow its instructions. Usually is not a control. Capable models can be argued, tricked or confused out of their instructions, which is why the toolkit refuses to rely on them: policy is enforced in deterministic code at the point where the agent touches a tool, so a denied action is not discouraged, it is impossible.
That distinction, between asking and enforcing, is the single most useful thing a non-technical leader can take from this project. The instructions you write for an agent shape its behaviour. The permissions and policies around it are what you can actually rely on. Good governance needs both, and it never confuses one for the other.
The three questions
The toolkit frames the problem as three questions, and they translate directly into plain English any firm can use.
1. What exactly can it do? Access to a system is not permission for every operation in it. An agent that reads matters in your practice management system should not be able to delete them, and standard access controls rarely draw the line that finely. The question to ask is not “what can it reach” but “what can it do once it has reached it, and what stops it doing more”.
2. Which agent did what? One agent using your systems is traceable. Several agents sharing a service account are not, and “the integration did it” is no answer during incident response or a client complaint. Every agent needs an identity of its own, so its actions can be separated from yours and from each other’s.
3. Where is the record? When an auditor, a regulator or an unhappy client asks what happened, the answer needs to be a record, not a recollection: what was requested, what policy applied, who approved it. If the honest answer is that no such record exists, the agent is not ready for work that matters.
If your agents live in Microsoft’s platforms
Most firms will meet agents through Microsoft 365 Copilot and Copilot Studio, not through a Python SDK, and on the managed platforms this class of machinery is part of what you are paying for. Agents inherit your existing Microsoft 365 permissions rather than acquiring their own, tasks run in a sandbox governed by the platform and activity lands in the compliance tooling your tenant already has. The governance discipline for client data still applies, because a control you have not configured protects nobody, but the enforcement layer itself comes with the platform.
The toolkit is Microsoft showing its working: the same discipline its own platforms apply, published in the open for everyone building outside them.
If you go custom
The custom-build route is where the three questions become procurement questions. If a partner builds you an agent outside the managed platforms, ask where policy is enforced other than in the instructions, how each agent is identified and where the audit trail lives. You do not need to name the toolkit. You need answers that sound like it. A builder whose full answer is “the prompt tells it not to” has written a request, not a control.
Where human review fits
Enforcement in code does not replace human review points. The two do different jobs. Code draws the hard lines, the things an agent may never do regardless of how convincingly it is asked. Review points cover judgement, the actions that are allowed but should be seen by a person before they stand. The toolkit treats an approval step as part of the policy itself, which matches how we think agents should run everywhere: assisting people, with agreed places where a person checks, never unattended by design.
What to do with this
For most firms there is nothing to install. There is something to write: the policy, in plain English, before any agent exists. What may this agent read. What may it write. What must a person approve. That one page is useful on every platform, managed or custom, and it turns the three questions from an audit surprise into a design input.
Governance is a stage of the agent journey, not an afterthought at the end of it. If agents are on your roadmap and the policy page does not exist yet, our AI governance planning service starts exactly there, or book a consultation and we will write the first draft of those three answers with you.
Sources checked
Last checked: 8 August 2026.
Related reading
More on copilot agents
Common questions