Microsoft AGT Proved Deterministic Enforcement. Where the Next Problem Starts.
Microsoft’s .NET team published the cleanest benchmark in agent security this month. Their internal red-team evaluation, scenarios mapped to the OWASP Agentic Top 10: prompt-only safety instructions produced a 26.67% policy violation rate. The same scenarios under the Agent Governance Toolkit (AGT) produced 0%.
That number should end the argument about whether deterministic policy is worth the engineering cost. It also confirms what every team running production agents has been quietly converging on: the model cannot be the policy engine. Not because models are unreliable in general, but because policy requires determinism and language-model output is stochastic by design. You cannot write an SLA around a guardrail that “the model interprets inconsistently”, to use Microsoft’s own phrasing.
AGT itself is a clean architecture. McpGateway sits in front of every tool call, McpSecurityScanner inspects payloads before execution, McpResponseSanitizer cleans returned data, and a YAML-based GovernanceKernel wires it together. Per-call, deterministic, evidence-backed. It is necessary infrastructure.
It is not sufficient.
What AGT explicitly does not do
The post is honest about scope. AGT governs individual tool calls within a single .NET agent runtime. It does not yet:
- Correlate sequences across multiple calls in a session (“did this agent already exfiltrate three calls ago?”)
- Apply consistent policy across multiple client runtimes (Claude Code, Cursor, Windsurf, Codex, custom orchestrators)
- Enforce across multiple MCP servers your team did not build
The roadmap section explicitly notes that workflow-level policy is upcoming, and that AGT’s strongest policy story today assumes .NET and YAML configuration. These are honest scope statements, not weaknesses, but they describe the boundary of what one agent runtime’s governance can do.
Where production agents actually live
Most teams running production agents are not running one .NET agent against tools they wrote in-house. They are running:
- Claude Code or Cursor or Codex for engineering workflows
- A vendor-built orchestrator for customer-facing workflows
- Internal Python or Node agents for automated tasks
- A growing surface of community-built MCP servers (Stripe, GitHub, Postgres, Slack, Atlassian, dozens more)
Each of those runtimes ships its own governance story, or doesn’t. None of them recognises another runtime’s governance decisions. None ships a shared audit log. None can enforce a tool allowlist that fires consistently regardless of which client made the call.
That is the cross-runtime problem. AGT governs one agent’s calls inside one runtime. A multi-server, multi-client organisation needs the allowlist, approval gate, and audit log to fire at the call boundary itself, where every runtime ends up before reaching any MCP server.
What changes when you move enforcement to the protocol boundary
If governance lives in front of every MCP call, regardless of which runtime made it:
- A tool deny rule applies whether the call came from Claude Code, Cursor, or a custom orchestrator
- Approval gates can correlate across the session because every call flows through one gateway
- The audit log unifies runtime-agnostic evidence of what every agent did
- Scoped credentials get attached at the gateway, never wired into clients
- Sequence-aware policy becomes possible (rate-limit the same tool across five agents talking to the same server, even if they live in different runtimes)
This is not a replacement for AGT-style in-runtime enforcement. It is the next layer up. AGT operates inside the agent runtime. PolicyLayer operates at the protocol boundary every runtime crosses on the way out. Both layers will exist in mature deployments.
The category is forming
In thirty days, three credible vendors have shipped or argued for the same conclusion: deterministic enforcement at the tool-call layer, not prompt-level guardrails, not retrospective dashboards. Microsoft AGT shipped the benchmark. Cequence shipped Agent Personas. Oracle published runtime budget guardrails as a closed-loop control plane. Different deployment contexts, identical primitive set: tool allowlists, approval gates, scoped credentials, rate limits, audit logs, kill switches.
The category has a name now: runtime governance. The next argument is scope. Which calls, across which servers, enforced at which layer.
Microsoft just shipped the cleanest validation we have. We are building for what comes next.
Control what your agents can do through MCP.
Get early access →. We’re rolling out invites in batches.
Browse the policy library →. Pre-classified tools across thousands of MCP servers.
Read the MCP security reference →. What the boundary looks like.