The Security Model & Limitations table in the current README does something the original April blog post did not: it tells you exactly where the enforcement ceiling sits.
That is a meaningful act of transparency. Most runtime governance tools describe what they enforce. The AGT is now also explicit about what it does not enforce — and where the ceiling of its deterministic guarantees sits. Enterprise architects evaluating this toolkit deserve that honesty. The analysis that follows incorporates it.
The ceiling the toolkit drew for itself
The limitations table added to the README states the following about execution rings and identity:
The AGT provides logical privilege tiers with resource limits — not CPU ring-level enforcement. The policy engine and the agents it governs run in the same Python process. This is the same trust boundary used by every Python-based agent framework, including LangChain, CrewAI, and AutoGen. For OS-level isolation, the README recommends running each agent in a separate container.
Ed25519 cryptographic agent credentials and trust scoring provide cryptographic identity at the application layer — not OS-level process separation. The identity is deterministic within the agent communication channel. It does not provide the process-level isolation that container or VM boundaries provide.
The original analysis used the kernel metaphor as an analogy — execution rings borrow from CPU privilege level architecture. That framing remains accurate as an analogy. What the limitations table clarifies is the scope: the rings are deterministic at the application layer, not at the OS layer. The ceiling is one level up from where the kernel metaphor implied.
The README’s production recommendation follows logically from this: run each agent in a separate container. Container isolation provides OS-level process separation. Combined with the AGT’s application-layer policy enforcement, the two layers together are structurally closer to complete than either alone. The toolkit is explicit that it governs the application layer; the container governs the OS layer. The architecture is honest about requiring both.
What else changed since the original analysis
The original LinkedIn summary post circulating at the time of the original analysis cited 992 conformance tests. The current README shows 9,500+ tests. The Luminity original post did not cite this figure, so no correction is required there — but practitioners evaluating the toolkit’s maturity posture should use the current number. The ClusterFuzzLite coverage (7 fuzz targets: policy, injection, MCP, sandbox, trust) and OpenSSF Scorecard integration are also additions from the current README that reinforce the security engineering posture.
The original post mentioned four frameworks by name. The current README shows 20+ framework integrations, including Microsoft Agent Framework (native middleware), Semantic Kernel (native, .NET + Python), Dify (133K+ stars, plugin), LlamaIndex, OpenAI Agents SDK, Google ADK, Haystack, and Azure AI Foundry. The expansion materially changes the deployment surface analysis — the toolkit is no longer positioned as a Python-first tool but as a governance layer for the full production agent framework ecosystem.
The README now includes an explicit regulatory alignment table. EU AI Act high-risk AI (Annex III) deadline is August 2, 2026 — ten weeks from the original post date. Colorado AI Act (SB 24-205) deadline is June 30, 2026. The toolkit maps audit trails to Article 12, risk management to Article 9, and human oversight to Article 14. Enterprise architects evaluating the AGT for compliance posture have a concrete deadline context the original analysis did not carry.
A new documentation page maps the toolkit to the NIST AI Agent Security RFI (2026-00206). This is a material addition for enterprise architects operating in federal or federally-adjacent environments. It also signals the direction of the toolkit’s standards alignment: OWASP coverage plus NIST RFI mapping positions the AGT as a compliance reference architecture, not just a runtime security tool. The OWASP coverage analysis published alongside the original post remains the correct frame for evaluating that alignment.
What the ceiling means for the structural/probabilistic argument
The ceiling does not weaken the structural/probabilistic argument. It locates it precisely.
The execution rings are deterministic at the application layer. Within the scope the toolkit governs — Python middleware, same process as the agents — Ring 0 agents have capabilities Ring 2 agents do not. That boundary is structural. A Ring 2 agent cannot call Ring 0 tools. That is categorical enforcement within the application layer, and it holds regardless of adversarial pressure.
The limitation is not that the rings fail to enforce. It is that “structural at the application layer” is a lower ceiling than “structural at the OS layer.” An attacker with OS-level access to the container running the agent can bypass the application-layer rings. The solution is not to abandon the application-layer controls — it is to pair them with OS-layer isolation, which the README explicitly recommends. The deterministic tier argument holds; the ceiling is now explicit about what it requires as a complement.
The probabilistic tier argument is unchanged. The semantic intent classifier and behavioral trust scoring operate on inference and degrade under adversarial pressure. That characterization does not depend on where the application-layer ceiling sits. The two tiers fail differently regardless of whether the OS-layer isolation is in place.
The sequencing recommendation from the original post also holds: deploy the deterministic tier first (execution rings, Ed25519 signing, DID/SPIFFE identity, MCP Security Scanner), treat the probabilistic tier as defense-in-depth, pair the MCP Security Scanner with upstream retrieval controls. Add container-level isolation as the OS-layer complement to the application-layer deterministic controls. That is the structurally complete architecture.
A toolkit that draws its own enforcement boundary explicitly is more trustworthy than one that does not. The AGT’s Security Model & Limitations table is the kind of honest architectural documentation that enterprise architects require before deploying a governance layer in production. The ceiling is navigable. The architecture requires both layers — application-layer policy enforcement and OS-layer container isolation — and the toolkit says so directly.
The kernel analogy holds at the application layer. The OS kernel metaphor held at a higher level than the implementation warrants — and the README corrected that, which is the right thing to do.
The honest accounting
What holds from the original analysis: The structural/probabilistic tier split. The sequencing recommendation. The protocol ceiling — runtime enforcement without input channel controls addresses the second half of the attack surface. The MCP Security Scanner as the most targeted structural control for tool-layer attack surfaces. The OWASP coverage framing: a risk-surface map, not an enforcement tier map.
What the ceiling qualification adds: “Application-layer structural” rather than the kernel metaphor’s implied OS-layer structural. Container isolation as the required complement. The limitations table as a document enterprise architects should read before deployment decisions, not after.
What the other changes add: 9,500+ tests and 20+ framework integrations expand the deployment surface without changing the enforcement tier taxonomy. The regulatory timeline (EU AI Act August 2, Colorado June 30) gives the adoption sequencing a concrete compliance deadline. The NIST RFI mapping opens a federal alignment path that did not exist in the original analysis.
The toolkit is still the most architecturally serious runtime governance release the Luminity corpus has reviewed. The ceiling is explicit, honest, and navigable. A kernel that draws its own enforcement boundary — and tells practitioners what it requires as a complement — is more deployable than one that doesn’t.
This post represents Luminity Digital’s independent assessment of the Agent Governance Toolkit based on the public GitHub repository as of May 2026. It is an analytical readout intended to help enterprise architects frame adoption decisions — not an implementation guide, configuration reference, or substitute for official technical documentation. Package capabilities, API surface, and enforcement behaviors may evolve as the toolkit progresses toward general availability. For authoritative guidance, consult the official repository: github.com/microsoft/agent-governance-toolkit.
