Microsoft's Agent Governance Toolkit: Deterministic Policy Enforcement for AI Agents

The gap AGT targets: scopes and IAM do not constrain what an agent does

An agent holding both send_email and query_database should not be able to drop_table. The README makes this the first of three questions the project exists to answer. OAuth scopes and IAM roles decide which services an agent can reach, not what it does once it is connected. The second question is attribution: when five agents share one API key, "an agent did it" is not an incident response. The third is evidentiary: auditors need a record of which policy was active, what was requested, and why the request was allowed or denied.

The intended audience is the team that has already shipped an agent and now has to defend it. The README argues that prompt-level safety is a polite request to a stochastic system, citing OWASP LLM01:2025 and an ICLR 2025 paper reporting a 100% attack success rate against several frontier models under adaptive attacks. Whatever you make of those figures, the design conclusion is the interesting part: AGT does not try to win inside the prompt. It intercepts in application code, before the model's intent reaches the wire.

How the AGT kernel turns a policy decision into a hard boundary

The mechanism is a wrapper. govern(my_tool, policy="policy.yaml") returns a callable that evaluates the YAML policy on every invocation, writes the decision to an audit trail, and raises GovernanceDenied when a rule blocks the action. The README's wording is that actions the kernel denies are "structurally impossible" rather than unlikely. That is the whole claim: the enforcement point sits in deterministic Python, not in a system prompt.

The policy file is versioned with its own apiVersion, here governance.toolkit/v1, and carries a default_action plus a list of named rules. Each rule pairs a condition string with an action such as deny or require_approval, and approval rules name approvers. Because conditions are evaluated in code, a denied call fails the same way every time, which is what makes the audit record useful.

A second entry point exists for programmatic control. AgentControl.from_path loads a manifest, evaluate takes an envelope with agent_id and an input body, and the result exposes a verdict. The repository ships a complete ACS email-tool example under examples/acs-email-tool. SDKs for TypeScript, .NET, Rust, and Go appear in the README and in sibling directories such as agent-governance-typescript and agent-governance-rust, so the policy concept is not Python-only even though the primary language is Python.

Installing AGT and governing your first tool function

The README requires Python 3.11 or newer. Install the full extra rather than the base wheel: the base agent-governance-toolkit wheel installs the compliance CLI only, while the governance modules live in the consolidated core distribution.

pip install "agent-governance-toolkit[full]"

After installation, the quick-start import comes from agentmesh. Importing agent_os instead emits a DeprecationWarning because the old agent-os-kernel distribution is deprecated; agent-governance-toolkit-core is the replacement distribution, and the [full] extra includes it.

from agentmesh.governance import govern

safe_tool = govern(my_tool, policy="policy.yaml")

Write the policy next to your code. The README's example allows by default and denies destructive verbs outright, while routing email sends to a human approver.

apiVersion: governance.toolkit/v1
name: production-policy
default_action: allow
rules:
  - name: block-destructive
    condition: "action.type in ['drop', 'delete', 'truncate']"
    action: deny
    description: "Destructive operations require human approval"

  - name: require-approval-for-send
    condition: "action.type == 'send_email'"
    action: require_approval
    approvers: ["security-team"]

Calling the wrapped function with a read returns the underlying result, and calling it with drop raises GovernanceDenied naming the rule. That error message is the thing to check first: if it does not appear, your policy file is not being loaded.

If your agents run inside Claude Code, the README documents a plugin route instead of a library route.

/plugin marketplace add microsoft/agent-governance-toolkit
/plugin install agt-governance@agent-governance-toolkit

The API surface is moving, and the README says so

The most concrete limitation is not a missing feature, it is churn. A block near the top of the README labels the project a public preview with production-quality releases that may have breaking changes before GA. The same block records that the pre-ACS agent_os.policies rule model is gone and that BREAKING_CHANGES.md lists its replacements. Policy-engine host code is told to use the ACS SDK, and agt-policies provides a one-way v4-to-v5 migration command. There is no documented rollback path in the README, so treat the migration as forward-only unless you verify otherwise in the repository.

There is also a packaging trap that will bite anyone copying an older tutorial. The distribution names have shifted: agent-os-kernel is deprecated, agent-governance-toolkit-core is the replacement, and the base agent-governance-toolkit wheel carries only the compliance CLI. Teams that pin the wrong name will find their governance imports missing rather than broken, which is a quieter failure.

Where AGT is the wrong tool: if your agent has no tool access, no delegation, and no data reach, a policy engine adds a dependency and a policy file to maintain for no reduction in blast radius. The same applies if you only need prompt hardening. AGT does not attempt to make the model refuse, and the README is explicit that it does not try to win that fight inside the prompt.

AGT compared with running OPA directly

The obvious alternative is Open Policy Agent on its own. OPA is a general-purpose policy engine with its own language and a decision API; the AGT Dockerfile installs the OPA CLI at a pinned version specifically because OPAEvaluator local mode shells out to opa eval. So AGT is not a replacement for OPA in every deployment, and the two can coexist.

The difference is where the agent-shaped work lives. With OPA alone you write Rego, wire the evaluation into your tool-dispatch layer, and build your own decision log and approval flow. AGT ships the wrapper, the YAML rule schema, the audit trail, and the require_approval action with named approvers as one package, and it publishes an OWASP Agentic Top 10 architecture document under docs/compliance. The trade-off is that you inherit AGT's release cadence and its breaking-change history. If your organisation already has a Rego policy estate and a decision-log pipeline, bolting AGT on top adds a second policy dialect rather than removing one.

Maintenance, licence, and what the repository tells you about cost

The repository is not archived. The last push was on 2026-06-09, which is more than three months before today, and the most recent release in the list is v4.1.0 on the same date, following v4.0.0 on 2026-06-01 and v3.7.0 on 2026-05-18. Three releases across roughly three weeks in May and June, then no recorded push since. Judge the cadence from that, not from the release names.

The licence is MIT, which permits commercial use and modification; the repository also carries NOTICE, TRADEMARKS.md, and ANTITRUST.md, and trademark rights are separate from the code licence. None of that is legal advice, and if you redistribute the toolkit inside a product you should read those files rather than the LICENSE alone.

Upgrade cost is the real line item. Because the project is in public preview and has already removed a rule model, budget for reading BREAKING_CHANGES.md and running the agt-policies migration command at each major bump. The Dockerfile pins Python 3.11 by digest and installs the OPA CLI at v1.4.2 with a sha256 check, which suggests the maintainers treat reproducibility as a first-class concern for the container path at least.

Editorial conclusion

Adopt AGT if you run autonomous agents that touch email, databases, or shell commands and you need a denial that does not depend on the model cooperating. Do not adopt it if you need a stable API surface today: the README labels this a public preview with possible breaking changes before GA, and the v4 line already removed the pre-ACS agent_os.policies rule model. Before you commit, run the two-line govern() example against a throwaway policy, confirm which distribution your imports resolve to ([full] versus agent-governance-toolkit-core), and read BREAKING_CHANGES.md for the replacements to agent_os.policies.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes