An AI agent that can only answer questions is low-risk. An agent that can send an email, move money, delete a record, or call an external system is a different animal entirely — because the moment it can take actions, a single bad decision has real-world consequences. On 2 April 2026, Microsoft released the open-source Agent Governance Toolkit, aimed squarely at that gap. Available for Python, TypeScript, Rust, Go and .NET, it provides what Microsoft calls an “Agent OS” — built around a stateless policy engine that intercepts every agent action before it executes.
What the toolkit actually does
The core idea is refreshingly simple. Rather than trusting an agent to behave well and hoping for the best, you put a checkpoint between the agent’s intention and the action itself. When the agent decides to do something — send that email, hit that API, write that record — the request is intercepted and checked against your policy first. If it passes, it proceeds. If it doesn’t, it’s blocked.
Two design choices make this practical:
- It’s stateless. The policy engine doesn’t have to remember a long history to make a decision; it evaluates each action on its own terms. That keeps it simple to reason about and easier to test.
- It intercepts every action. Coverage is the whole point. A guardrail with gaps is a guardrail an agent will eventually find its way around — usually at the worst possible moment.
- It’s broadly available. Shipping across Python, TypeScript, Rust, Go and .NET means most teams can adopt it without rewriting their stack.
The principle is old and sound: separate the thing that decides from the thing that acts, and check the decision before you let it become an action.
Why even a small team needs this
It’s tempting to assume governance is an enterprise concern — something for organisations with a compliance department and a risk register. That gets it backwards. A large company has layers of process that catch mistakes; a small team often has one person, one script, and no safety net. If your agent can take an action that touches a client, a payment, or a record you’re legally obliged to protect, the blast radius of a mistake is just as real at five people as at five thousand.
For a professional-services firm in particular — handling client money, sensitive files, regulated communications — an unguarded action-taking agent is a liability waiting to happen. A policy layer turns “we trust the model” into “the model can only do what we’ve explicitly allowed,” which is a far more defensible position if a client ever asks how their data is handled.
What to gate first — without over-engineering
The risk with any governance tool is the opposite failure: wrapping everything in so much policy that the agent can’t do anything useful and your team quietly routes around it. Don’t gate everything. Gate the actions where a mistake actually hurts, and leave the harmless ones alone.
A sensible starting order:
- Anything irreversible — sending external communications, deleting data, issuing payments. These are the actions you can’t take back.
- Anything that touches money or contracts — invoices, refunds, anything that creates a financial or legal obligation.
- Anything that leaves the building — calls to external systems or third parties, especially where client data is involved.
- Leave alone the read-only, internal, easily-reversed actions. Reading a document or drafting text for human review needs no gate.
Start with one rule that blocks the single action you’d least want an agent doing unsupervised, confirm it works, then add rules only as you find real gaps. A short, well-understood policy that the team actually trusts beats an exhaustive one nobody can read.
What this means for a small UK team
For a small UK firm experimenting with agents that do more than chat, the takeaway is to install the guardrail before you need it — not after the near-miss. Put a policy layer in front of any agent that can take real actions, and treat it as non-negotiable infrastructure rather than a nice-to-have. The toolkit’s broad language support means it’ll likely slot into whatever you’re already building with.
Keep the policy itself small and legible to start: one or two rules covering irreversible, money-touching, or data-leaving actions, with a human in the loop on anything sensitive while you build confidence. The goal isn’t to slow the agent down — it’s to make sure that when it acts, it can only act within lines you drew on purpose. That’s the difference between an agent you’ve deployed and an agent you’ve simply let loose.
