Policy checks still need deployment isolation
Agent Governance Toolkit puts policy decisions around agent actions, but its enforcement layer shares a process boundary with the agent. That distinction matters when deciding what the toolkit can protect and what the deployment must contain.
The README describes policy enforcement, identity, audit records, execution controls and SRE features. Its wrapped-tool example evaluates a policy, records the decision and raises an error when an action is denied. Those are project-described behaviors, not findings from our full-stack testing.
The README recommends a separate container for each production agent. A policy denying shell_exec does not independently restrict host access or make every tool invocation pass through that policy. Review the integration paths and provide OS-level isolation separately.
What our recorded run establishes
Our stored run occurred on September 27, 2026, at commit 6b644564d112b879e48183bc1655fcf73c86d23e, inside agent-governance-antigravity-cli/. The command output identifies that package as @microsoft/agent-governance-antigravity-cli@5.0.0. This package version is distinct from the repository's supplied v4.1.0 release reference.
The dependency-install step succeeded in 9,892 ms, rounded to 10 seconds, adding 7 packages. The recorded dependency footprint was 7 MB. Dependency installation does not establish that a working CLI was installed, and the record contains no separate installed-binary check.
The build command succeeded in 11,363 ms, rounded to 11 seconds. Its output runs npm run check, which invokes node --check on JavaScript files. This establishes successful syntax checking for that command's files, rather than a compiled build of the governance platform.
The test command succeeded in 23,317 ms, rounded to 23 seconds. Its runner summary reported 27 passed and 0 failed. The recorded output includes tests for installation helpers, hooks, policy handling and bundled MCP server interactions. These are runner-reported counts; no complete-log reconciliation established exhaustive unique test coverage. The runner's internal duration was about 14.8 seconds, distinct from the recorded command-step duration.
The npm audit record reported 0 advisories. Its coverage is unknown; neither the dependency count nor this result establishes how many packages were scanned or that the product is secure.
The recorded configuration was 3 CPUs, 8 GB of memory and image lab-node:22. A separate detection field records nodeMajor 20. Neither establishes the actual runtime version, so this review does not describe the run as verified Node 22 testing. The supplied record also does not establish the earlier claims about secrets or container privilege.
The checkout measurement was 4,935 files, approximately 741,814 source lines and 50.9 MB. Repository signals recorded 42 CI workflows, a tests directory and no detected Dockerfile or Compose file. Those observations describe this checkout and detector scope; they do not prove the availability or absence of every deployment option.
No Python installation, full SDK validation, cloud identity exercise or production workload measurement is established by this run. The MCP interactions in the CLI tests do not validate the toolkit's entire MCP security gateway.
Choose a package by workflow
The README quick start uses pip install "agent-governance-toolkit[full]" and specifies Python 3.11+. Its general prerequisite list says Python 3.10+, so check the selected package's requirements before installation. The base wheel installs only the compliance CLI; governance modules come through the consolidated core distribution or the full extra.
The README describes consolidated Python distributions under v4.1.0. Older package names remain as redirecting stubs, importing agent_os emits a deprecation warning, and the previous policy rule model has been removed. Existing integrations should review the documented replacements before changing dependencies.
Avoid assuming that the non-Python packages stop at policy, identity, trust and audit. The supplied Language Package Matrix, marked last reviewed August 18, 2026, describes broader capabilities across TypeScript, .NET, Rust and Go, including execution rings and SRE functions. These are documentation claims, not capabilities verified in our run.
The same matrix retains workflow differences: Python has the governance dashboard and complete unified CLI workflow, Rust has a partial operator CLI, and .NET identity parity has qualifications. It also describes TypeScript's generic framework adapter while listing framework-specific adapters as roadmap work. Match the exact workflow to the exact package rather than treating a capability checkmark as proof of identical behavior.
Other documented prerequisites are Node 18+ and npm 9+ for TypeScript, .NET 8+, Go 1.25+ and Rust 1.70+. Azure-integrated features optionally use client, tenant and secret values. Claude Code has a documented marketplace plugin, but that integration still needs its own policy and deployment checks.
Preview status and the reported exception path
The README calls the toolkit a production-quality Public Preview and warns that breaking changes may occur before GA. Production quality is the project's description; our limited CLI run does not independently establish it. The supplied release reference is v4.1.0. Release age alone does not establish maintenance quality.
Issue 4172, opened September 28, 2026, reports exception propagation in the Python agent-mesh policy provider and its ASGI /check route. The reporter explicitly says a confirmed authorization bypass was not demonstrated. The supplied issue page shows it closed as completed through #4181 on October 2, 2026. We have not inspected that change or verified which distributed versions include it.
Treat this report as a reason to test your chosen integration's error handling. Exercise policy-engine failures alongside ordinary allow and deny decisions, and check what the caller does when it receives no structured decision. The report is neither evidence of a demonstrated bypass nor proof that every current deployment has the reported defect.
How to use the scores
These are editorial evidence ratings, not measured adoption or security scores. The rubric is 1 for insufficient support, 2 for limited support, 3 for a useful but conditional assessment, 4 for strong support within the stated scope and 5 for broad verification. Missing evidence limits confidence; it does not establish poor product quality.
Setup receives 3/5 because the recorded CLI-directory commands succeeded while installation and operation of the wider stack remain unverified. Documentation receives 3/5 because the README and matrix explain package choices and boundaries, but contain a Python prerequisite discrepancy and workflow qualifications. Community receives 2/5 because contribution materials and a closed issue provide limited evidence of participation, without establishing adoption or support responsiveness. Maturity receives 3/5 because the preview warning, scoped command results and issue history support a conditional evaluation rather than a GA assurance.
A practical adoption decision
Evaluate AGT when policy and audit responsibilities span agents or teams and someone can own integration, isolation and failure testing. Begin with the package and workflow you actually need; the README says its layers are optional.
If the immediate need is a policy decision engine, Open Policy Agent documents a model where services query policies and enforce the returned answers. If the need is fine-grained application authorization, Cedar documents policies, an authorization engine and schema validation. These are component choices, not interchangeable deployment CLIs.
The useful next step is a trial of your selected integration with representative actions and deliberate policy failures. Keep that trial separate from our recorded Antigravity directory results.