# Technical and strategic review: Microsoft Agent Governance Toolkit

**Assessment date:** 15 September 2026  
**Repository:** https://github.com/microsoft/agent-governance-toolkit  
**Source snapshot reviewed:** [`c63c51e881c442fbc060705f7e211f29993f2c1b`](https://github.com/microsoft/agent-governance-toolkit/commit/c63c51e881c442fbc060705f7e211f29993f2c1b)

## Executive verdict

Microsoft's Agent Governance Toolkit (AGT) is an unusually broad, open-source **runtime action-governance SDK and reference architecture** for AI agents. Its strongest, clearest center of gravity is a deterministic policy decision runtime (the Agent Control Specification, or ACS) plus host/framework enforcement hooks around the agent lifecycle. Around that core it supplies agent identity and delegation primitives, trust scoring, tamper-evident audit structures, MCP inspection/gateway components, cooperative execution controls, SRE primitives, compliance evidence tooling, framework adapters, and deployment examples.

The precise category is **embeddable agent policy decision/enforcement middleware**, not a complete enterprise governance platform. It is best placed between an agent framework and side-effecting tools/messages/model boundaries. It can also run beside an agent as a service, but the sidecar is explicitly a mediation API rather than a transparent network proxy: something trusted must route every relevant action through it. Its principal security boundary is therefore the host integration and process/container trust boundary, not the model and not the operating-system kernel.

AGT is strategically compelling for organizations that want a vendor-neutral policy layer across heterogeneous agent frameworks and languages, especially where policies need to be local/offline and expressed in YAML, Rego/OPA, Cedar, or code. It is not by itself model safety, DLP/data lineage, IAM/PAM, secrets lifecycle, sandbox isolation, a SIEM, a managed policy control plane, a compliance certification, or proof of real-world action outcomes. Those are its natural integration seams.

The project has strong velocity and engineering breadth, but it should still be treated as **public preview/beta**. The repository is only about six months old, changes quickly, has substantial API/package churn, uneven cross-language semantics, and current documentation/release-state inconsistencies. A production adopter should pin exact versions, validate the precise SDK path it uses, add independent containment and audit persistence, and build conformance tests around every enforcement hook.

## 1. What the system actually is

The architecture document defines AGT as “deterministic application-layer interception”: an action is evaluated before execution, with containers/VMs recommended as additional isolation ([architecture, lines 9–13](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md#L9-L13)). It explicitly says that the enforcement boundary is the Python interpreter and recommends a container per agent in high-security deployments ([lines 94–107](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md#L94-L107)).

The technical nucleus is ACS:

* The host is the **policy enforcement point (PEP)**; it constructs a complete JSON snapshot at an intervention point, calls ACS, then enforces the result.
* ACS is the **policy decision point (PDP)**: stateless, deterministic, and fail-closed on runtime errors.
* The native decision core is Rust, exposed through Rust directly and bindings for Python (PyO3/maturin), Node (napi-rs), .NET (P/Invoke), and Go ([policy-engine README, lines 1–7, 50–72, 203–240](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md#L1-L7)).

The eight lifecycle interception points are `agent_startup`, `input`, `pre_model_call`, `post_model_call`, `pre_tool_call`, `post_tool_call`, `output`, and `agent_shutdown` ([policy-engine README, lines 74–87](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md#L74-L87)). This is broader than a tool-only allowlist: policy can mediate ingress, model requests/responses, tool calls/results, and final output. However, interception coverage is only as complete as the host adapter.

### Components around the policy core

The repository groups a wide set of capabilities under the AGT name: Agent OS, ACS, AgentMesh, runtime/sandboxing, SRE, compliance, marketplace, training governance, and hypervisor/audit ([README package map, lines 234–256](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/README.md#L234-L256)). The architecture adds execution rings, trust, SLO/error budgets, replay, circuit breakers, Merkle logs, MCP security, and framework adapters ([architecture, lines 23–74](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md#L23-L74)).

That breadth should not be mistaken for one hardened monolithic runtime. It is a monorepo of independently usable packages, specifications, adapters, examples, and compatibility layers. Python is the primary implementation and has the complete CLI/dashboard and deepest workflow integrations; the feature matrix itself calls out Python-ahead areas ([package matrix, lines 62–73](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/PACKAGE-FEATURE-MATRIX.md#L62-L73)).

## 2. Policy model and enforcement semantics

### Policy artifact and engines

An ACS manifest binds named policies to lifecycle intervention points, declares tool metadata, optional annotators and approval configuration, and can inherit from other manifests. Supported policy definitions are Rego, Cedar, test, and custom dispatchers ([policy-engine README, lines 101–129](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md#L101-L129)). The cross-language matrix claims YAML rules, OPA/Rego, Cedar, and programmatic policies in all five language packages ([matrix, lines 182–202](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/PACKAGE-FEATURE-MATRIX.md#L182-L202)).

Verdicts carry decision, reason, message, optional transform, evidence, and result labels. The current source is in transition: the policy-engine README documents `allow`, `deny`, `warn`, `escalate`, and `transform`, while `BREAKING_CHANGES.md` says the extracted `agent-control-spec` engine closes the wire contract to `allow`, `deny`, and `transform`; warn is normalized to allow-with-warnings and escalation to a liftable deny with approval metadata. It also makes transform application, approval resolution, evaluation-only handling, and identity derivation **host obligations** ([breaking changes, lines 85–115](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/BREAKING_CHANGES.md#L85-L115)). This discrepancy is material: consumers must target a released version and test the concrete contract, not implement against prose alone.

### Enforcement points and bypass boundary

Framework adapters create session-scoped host state and mediate the host framework’s available intervention points. The documentation says attempted tool calls are charged before policy evaluation and adapter contract tests verify that public framework paths reach required native intervention points before side effects/disclosure ([framework tutorial, lines 35–63](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/tutorials/03-framework-integrations.md#L35-L63)). Transforms must replace—not accompany—the original data, and approval identity mismatch fails closed ([lines 65–93](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/tutorials/03-framework-integrations.md#L65-L93)).

The important caveat is explicit. Tier-0 sidecar mode is **not transparent interception**; the orchestration layer or service mesh must call it, and an agent that bypasses that path bypasses governance. Tier 0 also lacks identity/trust, hash-chain audit, behavior monitoring, and output redaction ([integration tiers, lines 39–73](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/integration-tiers.md#L39-L73)). Deeper controls require SDK hooks or framework middleware. Therefore “structurally impossible,” as claimed in the README, is true only inside a correctly mediated, non-bypassable host boundary.

Another important default is documented in the threat model and limitations: with no policies loaded, default action is allow; permissive mode also allows by default. Runtime evaluation failures fail closed, but absent/misinitialized governance may fail open ([limitations, lines 233–264](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L233-L264)). Production use should enforce startup/preflight attestation, strict deny-by-default mode, policy checksums/versioning, and negative tests that bypass every public tool path.

### Information-flow and probabilistic extensions

ACS has a stateless information-flow-control model: the **host** supplies source labels and tracks provenance; the manifest supplies sink clearance/security labels ([policy-engine README, lines 166–176](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md#L166-L176)). Classifier, LLM-judge, and endpoint annotators are host-dispatched extensions. This permits content-aware decisions but moves those paths away from the pure deterministic core: determinism is conditional on identical dispatcher outputs.

## 3. Identity, trust, delegation, and authorization

The Python implementation creates random `did:mesh:<128-bit-hex>` identifiers and an Ed25519 keypair. Identity records include a human sponsor, organization, capabilities, status/expiry, parent DID, delegation depth, and an optional lineage-bound initial trust cap ([`agent_id.py`, lines 26–114](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/identity/agent_id.py#L26-L114)). Delegation must narrow capabilities, refuses wildcard delegation, and caps depth at ten ([lines 234–302](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/identity/agent_id.py#L234-L302)). Registry revocation recursively revokes delegates, but the default registry is in-memory; the source comment says a production implementation would use a database and AgentMesh CA ([lines 538–599](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/identity/agent_id.py#L538-L599)).

Trust is a behavioral score (0–1000, default 500) rather than an external identity assurance level; policy compliance, task completion, violations, decay, and revocation affect it ([architecture, lines 109–121](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md#L109-L121)). It is useful as a risk signal, not a replacement for enterprise authentication/authorization.

The identity model is best understood as an agent-specific overlay on enterprise IAM:

* DIDs and keys establish agent possession/attribution.
* sponsor and delegation fields encode accountability/lineage.
* capability scopes and trust scores become policy inputs.
* external PKI/OIDC, workload identity, key storage/rotation, revocation distribution, and authoritative authorization remain integration responsibilities.

The repository’s own security advisory demonstrates why this boundary matters. Through 5.0.0, HTTP trust middleware accepted caller-controlled identity/capabilities or signatures insufficiently bound to the request. The 5.0.1 fix binds a signed request envelope to audience, time, nonce, method, raw target, headers, and body digest, resolving keys/capabilities from a trusted registry ([SECURITY.md, lines 112–143](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/SECURITY.md#L112-L143)).

Cross-SDK identity is not fully normalized: Python/.NET use `did:mesh:*`; TypeScript/Rust/Go use `did:agentmesh:*`. Prefix-sensitive policies can miss one family ([limitations, lines 327–355](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L327-L355)).

## 4. Audit, telemetry, and compliance evidence

Python’s `AuditEntry` contains event/agent/action, resource, outcome, policy decision and rule, trace/session identifiers, hashes, environment context, and optional policy version, approver DID, argument hash, and issued/completed timestamps. Several newer fields explicitly are **not included in the v1.0 canonical hash** and are deferred to v1.1 ([audit source, lines 57–159](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/governance/audit.py#L57-L159)). The implementation hash-chains entries and builds Merkle inclusion proofs ([lines 268–458](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/governance/audit.py#L268-L458)).

The default `AuditLog`, however, stores entries in an in-memory list. Persistence is optional through an external `AuditSink` ([lines 465–531](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/governance/audit.py#L465-L531)). Hash/Merkle structures make later mutation detectable relative to a trusted root; they do not by themselves prevent deletion, truncation, rollback, or an attacker recomputing an unanchored chain. The project correctly recommends an external append-only sink to which agents lack write access ([SECURITY.md, lines 51–60](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/SECURITY.md#L51-L60)).

ACS telemetry is content-redacted by default and has OpenTelemetry sinks in Rust/Python/Node/.NET. It omits raw targets, arguments, model outputs, transforms, secrets, and personal data ([policy-engine README, lines 178–201](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md#L178-L201)). This is a sensible operational seam for SIEM/observability, but it may be insufficient for forensic reconstruction unless separately governed evidence pointers or argument hashes are retained.

“Compliance” here means mappings, policy linting, evidence export, and verification tooling—not automatic legal compliance or an external certification. AGT logs attempts and governance decisions, not verified external-world outcomes ([limitations, lines 54–72](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L54-L72)).

## 5. Runtime, framework, language, and dependency coverage

### Languages/runtimes

The published matrix claims core governance primitives in Python, TypeScript, .NET, Rust, and Go, with Python as primary ([matrix, lines 11–34](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/PACKAGE-FEATURE-MATRIX.md#L11-L34)). Concrete runtime requirements in source include:

* Python core 5.0.0: Python >=3.11; classifier says Beta. Required libraries include `agt-policies`, Pydantic, PyYAML, cryptography, PyNaCl, HTTPX/aiohttp, structlog, Click, JSON Schema, and `agentrust-trace`; server/storage/OTel/MCP/Redis/Postgres support is optional ([core `pyproject.toml`, lines 5–55 and 57–106](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-governance-toolkit-core/pyproject.toml#L5-L55)).
* TypeScript SDK 5.0.0: Node >=18, labelled Public Preview; runtime dependencies are Noble crypto packages and `js-yaml` ([`package.json`, lines 1–52](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-typescript/package.json#L1-L52)).
* Rust `agentmesh`: labelled Public Preview, using ACS, `agentmesh-mcp`, Cedar, Regorus, Ed25519, AES-GCM, HMAC, regex, serde, and SHA-2; CLI and OpenTelemetry are feature-gated ([Cargo manifest, lines 1–49](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-rust/agentmesh/Cargo.toml#L1-L49)).
* Go module declares Go 1.25 and only `gopkg.in/yaml.v3` directly ([`go.mod`](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-golang/go.mod)).
* .NET is distributed as `Microsoft.AgentGovernance`; its identity parity is explicitly partial, with ECDSA P-256 rather than uniform Ed25519 behavior ([matrix, lines 96–116](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/PACKAGE-FEATURE-MATRIX.md#L96-L116)).

The monorepo is large: at the reviewed snapshot it contained 4,781 tracked files, 55 `pyproject.toml`, 28 `package.json`, 15 `Cargo.toml`, two `go.mod`, and 24 `.csproj` manifests. Presence and matrix checkmarks do not establish equivalent hardening or semantics. Python has substantially more implementation, tests, adapters, CLI, and operational tooling.

### Frameworks

The core Agent OS adapter documentation lists A2A, AgentShield, Anthropic, AutoGen, Bedrock, CrewAI, Gemini, Google ADK, Guardrails AI, LangChain, LangGraph, LlamaIndex, Microsoft Agent Framework, Mistral, OpenAI, OpenAI Agents SDK, Pydantic AI, Semantic Kernel, and Smolagents ([framework tutorial, lines 95–103](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/tutorials/03-framework-integrations.md#L95-L103)). A consolidated integrations wheel makes each third-party framework an optional extra and force-includes many adapter packages ([integrations manifest, lines 35–55 and 69–94](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-governance-toolkit-integrations/pyproject.toml#L35-L55)).

Adapter depth varies. “Supported” can mean a generic wrapper, middleware hook, audit exporter, trust bridge, or a framework-specific lifecycle adapter. Adoption due diligence must map each framework’s actual public execution paths to ACS intervention points and test direct/native tool calls that might evade wrappers.

## 6. Deployment assumptions and examples

The project supports in-process middleware, sidecar/init-container patterns, Kubernetes, serverless containers, and managed-agent-framework integration on Azure, AWS, GCP, and on-premises ([deployment guide, lines 1–8, 12–43, 46–91](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/deployment/README.md#L1-L8)). Core operation is local/offline and has no required Azure dependency; cloud IAM, secret stores, telemetry, Redis/Postgres, and managed services are optional integrations ([limitations, lines 116–131](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L116-L131)).

Two examples expose the real integration contract well:

* In the ACS email example, the host evaluates `send_email`, enforces allow/transform/deny, and owns the side effect; ACS never executes the tool itself ([example README](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/examples/acs-email-tool/README.md)).
* The Kubernetes agent-sandbox example governs commands before they claim a sandbox pod, but says explicitly that AGT is defense-in-depth before isolation, not a substitute for it. Its regex command classifier is illustrative and bypassable ([example lines 15–32 and 124–134](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/examples/k8s-agent-sandbox-governed/README.md#L15-L32)).

A sound production topology is: trusted framework/host adapter → ACS PDP → platform PEP/tool proxy → actual resource, with agent workload isolation, workload identity, secrets broker, network policy, and append-only telemetry outside the agent’s write boundary.

## 7. Explicit limitations and security consequences

The project is unusually candid about boundaries:

1. **Actions, not reasoning or truth.** It cannot establish that permitted content is non-hallucinatory or that a sequence of individually allowed actions is benign ([limitations, lines 12–52](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L12-L52)).
2. **Attempts, not outcomes.** World-state success and data freshness require application validation ([lines 54–72](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L54-L72)).
3. **Policy-engine benchmark is not system overhead.** The claimed <0.1 ms is policy evaluation only; documented distributed interactions are 5–50 ms ([lines 74–93](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L74-L93)).
4. **No native knowledge governance.** Provenance, freshness, classification, and end-to-end RAG data flow are outside its current boundary ([lines 170–199](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L170-L199)).
5. **No credential lifecycle.** It does not observe/revoke credentials across task boundaries ([lines 201–231](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L201-L231)).
6. **Not physical/real-time safety or continuous stream inspection** ([lines 268–318](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L268-L318)).
7. **Kill switches are cooperative/inconsistent.** Python/TS depend on registered handlers; Go is an allow/deny registry, and none proves a non-cooperating external process stopped ([lines 357–398](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md#L357-L398)).
8. **Remote manifest loading has current hardening gaps.** The breaking-change note says hostname resolution and redirect hops are not rechecked; zero redirects are advised when the guard must hold ([breaking changes, lines 46–81](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/BREAKING_CHANGES.md#L46-L81)).

## 8. Maturity and recent activity

Snapshot evidence as of 15 September 2026:

* Repository created 2 March 2026; 6,267 stars, 1,116 forks, 91 watchers; 146 unique contributor logins returned by GitHub’s contributors API; 2,617 commits in the local full clone. Metadata: [GitHub repository](https://github.com/microsoft/agent-governance-toolkit), [contributors](https://github.com/microsoft/agent-governance-toolkit/graphs/contributors).
* Activity is extremely high: 185 commits in the prior 30 days and 154 in the prior seven days at the reviewed HEAD. The latest commits on 15 September included AgentMesh security hardening, policy DSL changes, a Kubernetes agent-sandbox example, dependency upgrades, and regulatory policy packs ([commit history](https://github.com/microsoft/agent-governance-toolkit/commits/main/)).
* The tree has 43 GitHub Actions workflow files and about 910 tracked source test files by filename. The examined main-branch run exposed 28 successful jobs and two skipped among the first 30 jobs, including Python 3.11–3.13 matrices across core packages ([CI workflow](https://github.com/microsoft/agent-governance-toolkit/actions/workflows/ci.yml)).
* There were 95 open issues and 74 open PRs (169 open GitHub “issues” including PRs). Current issues include policy-engine binding/feature regressions, URL-manifest security questions, compliance false-positive semantics, and cross-binding identity fields ([issues](https://github.com/microsoft/agent-governance-toolkit/issues), [PRs](https://github.com/microsoft/agent-governance-toolkit/pulls)).
* The project is MIT-licensed ([LICENSE](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/LICENSE)). It has Microsoft security reporting, a threat model, maintainers/governance files, OpenSSF badges, and disclosed/fixed advisories.
* Published release metadata lags the source/tag state: GitHub’s latest formal release was v4.1.0 on 9 June, while a v5.0.0 Git tag exists from 27 July and source manifests are 5.0.0; SECURITY.md refers to a 5.0.1 fix. Meanwhile its supported-version table still lists only 3.4.x/3.3.x/3.2.x ([SECURITY.md, lines 91–99](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/SECURITY.md#L91-L99)). This is a release-governance/documentation consistency risk.
* The README labels releases “Public Preview” with possible breaking changes; Python/TS/Rust manifests say Beta/Public Preview ([README, lines 36–39](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/README.md#L36-L39)). `BREAKING_CHANGES.md` is 800+ lines and contains TBD-dated changes, evidence of active redesign rather than stabilized contracts.
* The self-reported adopter file lists three production rows—two Microsoft-internal and one Dayos—and several pilots/evaluations. It is PR-submitted, so it is directional rather than independently verified evidence ([ADOPTERS.md, lines 7–40](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ADOPTERS.md#L7-L40)).

Overall maturity: **credible, fast-moving public preview with broad implementation and strong community interest; not yet a stable enterprise platform contract**.

## 9. Industry capability map

| Industry layer | AGT position | Assessment |
|---|---|---|
| Governance frameworks / regulatory mapping / model inventory | Adjacent | Supplies mappings, policy packs, evidence and verification tools; not an enterprise system of record, risk workflow, model registry, or legal attestation service. |
| Runtime agent policy PDP | Core | Strongest capability: stateless deterministic ACS, lifecycle intervention points, YAML/Rego/Cedar/custom policy, transforms/approval metadata, cross-language bindings. |
| Runtime PEP / framework guardrails | Core but integration-dependent | Adapters, decorators, middleware, MCP gateway, sidecar API. Enforcement is not transparent and is bypassable if host paths are incomplete or agent/process is trusted equally. |
| Agent identity / trust / delegation | Substantial overlay | DIDs, Ed25519/ECDSA, signed requests, sponsor/lineage, scoped delegation, trust scores. Needs authoritative enterprise IdP/workload identity, KMS, revocation, and policy integration. |
| IAM/PAM/secrets | Not a replacement | Does not issue cloud permissions, broker secrets, enforce credential TTL, or replace OAuth/IAM. Use identities/trust as policy context around those systems. |
| Audit / observability / compliance evidence | Strong SDK primitives | Structured decisions, hash chain/Merkle proofs, CloudEvents/OTel, compliance mappings. Requires external immutable storage, root anchoring, retention, SIEM, and outcome attestations. |
| MCP/tool security | Strong complementary module | Tool metadata scanning, policy gate, response sanitization/redaction, session/rate controls. It does not make a malicious tool safe once broad behavior is allowed. |
| Model/input/output safety | Adjacent/partial | Intervention hooks and optional classifiers/LLM annotators; not a foundation model guardrail, factuality engine, or full content-safety service. |
| Data/RAG governance and DLP | Gap/integration seam | IFC labels exist but host supplies provenance; no native data catalog, lineage, entitlement-aware retrieval, or sequence-aware exfiltration control. |
| Sandboxing / workload isolation | Orchestration helpers, not primary boundary | Execution rings and adapters exist, but application-layer controls and cooperative kill switches do not replace containers, microVMs, seccomp, network isolation, or hardware safety. |
| Agent reliability/SRE | Useful primitives | SLOs, error budgets, circuit breakers, replay/chaos and kill hooks. Not a full observability backend, incident platform, or proven process supervisor. |
| Managed governance control plane | Not present | No turnkey multi-tenant hosted service providing global policy distribution, HA decision service, fleet inventory, approvals UI, SLA, and long-term evidence store. Deployment guides compose user-operated components. |

## 10. Likely integration seams

1. **Agent frameworks and tool dispatch:** wrap framework middleware and native tool execution; require adapter conformance and bypass tests.
2. **MCP:** place AGT at client/server gateway boundaries for pre-call policy, schema/tool drift scanning, trust, redaction, rate limiting, and audit.
3. **Enterprise IAM/workload identity:** map Entra/OIDC/SPIFFE/Kubernetes identities and group/role claims into agent identity, sponsor, capability, and ACS snapshot fields; keep KMS and revocation authoritative externally.
4. **Policy administration:** use GitOps/CI to review/sign/version ACS manifests and Rego/Cedar bundles; integrate an existing OPA/Cedar policy estate. Avoid live remote manifests unless fetch/redirect/DNS controls are independently hardened.
5. **Audit/SIEM/GRC:** export CloudEvents/OTel and hashes to immutable object/WORM storage, a transparency log, SIEM, and evidence workflows; anchor Merkle roots outside the agent boundary and attach outcome attestations.
6. **Secrets/PAM:** broker just-in-time credentials after an allow decision; revoke at task/session boundaries independently of AGT.
7. **Data/RAG security:** enrich ACS snapshots with catalog classification, document entitlement, provenance, freshness and egress labels; add sequence/session correlation outside the stateless PDP.
8. **Isolation:** enforce allowed actions again at a sandbox/tool proxy, Kubernetes admission/network layer, microVM, or service account boundary so a compromised in-process agent cannot skip the SDK.
9. **Managed AI platforms:** attach as in-process middleware where Foundry/Bedrock/Vertex hooks are available; where hooks are incomplete, mediate tool endpoints rather than trusting application-only coverage.

## Adoption recommendation

Use AGT now for a bounded pilot when the desired outcome is portable, code-level pre-action policy enforcement and auditable agent identity across multiple frameworks. Prefer ACS plus one well-tested adapter and external audit export before adopting the whole stack. For production:

* pin a fixed commit/package set and record the exact ACS/spec version;
* use strict/default-deny manifests and fail deployment if no policies are loaded;
* run policy evaluation outside the agent process for higher-risk workloads;
* ensure all side effects flow through a PEP the agent cannot bypass;
* use external IAM/KMS/secrets, container/network isolation, and immutable audit storage;
* normalize DID formats and test cross-language parity;
* verify transforms, approval identity binding, post-tool paths, exception/fallback paths, timeouts, and telemetry failure behavior;
* treat trust scores and compliance mappings as signals/evidence—not authorization truth or certification;
* track release notes, advisories, and breaking changes closely until GA and release/support metadata converge.

**Bottom line:** AGT is one of the broadest open-source attempts to standardize the runtime control plane inside agent applications. Its best strategic role is the **agent-aware PDP/PEP and evidence layer between stochastic agent logic and deterministic enterprise controls**. It becomes materially stronger when paired with the systems it does not try to replace: IAM/PAM, data governance, content safety, workload isolation, durable observability, and GRC.