Microsoft Gives .NET MCP Servers a Governance Button

MCP’s best feature is also its sharpest edge: it makes tools easy to connect to agents. That is great when the tool is a harmless demo endpoint. It is less cute when “tools” means ticket systems, source repositories, customer records, deployment hooks, database helpers, browser automation, and whatever internal API someone wrapped on a Friday because the agent needed “just one more capability.”

Microsoft’s new Microsoft.AgentGovernance.Extensions.ModelContextProtocol package is not glamorous. Good. Glamour is how agent platforms end up with production-write access and no audit trail. The Public Preview package targets .NET 8+ and plugs into the official MCP C# SDK with a .WithGovernance(...) call on IMcpServerBuilder. In practice, that means policy enforcement, startup scanning, identity-aware execution, response sanitization, audit events, and metrics move into the place where MCP servers are already registering tools.

That placement is the whole story. Agent security has spent too much time living in diagrams, prompt templates, and “please be careful” system messages. The tool registry is where the risk becomes real. If governance does not sit there, close to tool exposure and tool invocation, it is mostly vibes with a compliance deck.

Fail before the model ever sees the poisoned tool

The extension’s governed flow has two phases: startup scanning before tools are exposed, and runtime governance on each tool call. Startup scanning can detect tool poisoning, typosquatting, hidden instructions, rug pulls, schema abuse, cross-server attacks, and description injection. Those categories may sound academic until you remember how MCP works: tool descriptions and schemas are fed to models so the model can decide what to call. A malicious instruction hidden in metadata is not “just text.” It is supply-chain input to the agent’s decision loop.

That is why the default posture matters. Microsoft lists defaults such as ScanToolsOnStartup = true, FailOnUnsafeTools = true, SanitizeResponses = true, GovernFallbackHandlers = true, EnableAudit = true, and EnableMetrics = true. The boring defaults are doing real work here. A poisoned tool should fail registration before it becomes context. A fallback handler should not become an ungoverned side door. A tool response should not become trusted instruction-shaped text just because it came back over a protocol with a nice logo.

The sample integration is deliberately small: builder.Services.AddMcpServer().WithGovernance(options => { options.PolicyPaths.Add("policies/mcp.yaml"); options.DefaultAgentId = "did:mcp:server"; options.ServerName = "contoso-support"; });. Installation is the usual dotnet add package Microsoft.AgentGovernance.Extensions.ModelContextProtocol. The NuGet page lists version 3.7.0, updated May 18, 2026, with dependencies on Microsoft.AgentGovernance >= 3.7.0 and ModelContextProtocol >= 1.3.0. None of that is flashy. That is exactly why teams might actually adopt it.

Deny-by-default is not pessimism. It is engineering.

The runtime policy model is YAML-backed, with actions such as allow, deny, and rate-limit. Microsoft’s example policy uses default_action: deny and explicitly allows only a tool named echo. That may look absurdly restrictive in a demo, but it is the correct mental model for production. Agents should earn permissions the same way services do: narrowly, reviewably, and with an audit trail.

The important design shift is identity-aware execution. The NuGet migration notes say RequireAuthenticatedAgentId now defaults to true, DefaultAgentId is only used when that is explicitly disabled, and context.Items["agent_id"] is not used for governance identity resolution. Prototype builders will grumble. Platform teams should applaud. If three agents call the same MCP server and the logs only say “AI called tool,” you do not have governance. You have fog with timestamps.

Identity is what lets policy express the rules that matter. A support agent can read ticket metadata but not export customer records. A coding agent can run tests but not deploy. A finance assistant can query balances but not initiate transfers. A docs agent can open issues but not close security advisories. Without authenticated agent identity, those distinctions collapse into one overpowered integration account, which is how many “AI incident” postmortems will start if teams do not fix it now.

Response sanitization is the other half of the loop. Microsoft says the extension scans tool output for prompt-injection tags, imperative override phrases like “ignore previous instructions,” credential leakage patterns, and exfiltration-oriented URLs. Pattern-based sanitizers are not magic; attackers adapt, and false positives will happen. But the architecture is right because tool output is untrusted input. A database row, issue comment, webpage scrape, or CRM note can contain hostile instructions just as easily as a user prompt can. If your agent treats tool output as clean because “the tool returned it,” the tool boundary is already broken.

The practitioner move is to make the breakage visible

The broader Agent Governance Toolkit repository claims runtime governance follows an “Agent Action → Policy Check → Allow/Deny → Audit Log” path in less than 0.1 ms. It also claims prompt-based safety had a 26.67% policy violation rate in red-team testing versus 0.00% for application-layer enforcement, and positions the toolkit as covering 10/10 OWASP Agentic Top 10 risks. Treat vendor numbers with the usual eyebrow raise, but the principle is sound: enforcement belongs below the prompt. The model should not be the only thing standing between a tool call and a bad day.

If you run .NET MCP servers, the next step is not to announce an “agent governance transformation.” Put the package in a staging branch. Turn on fail-closed scanning. Inventory which tools fail and why. Write a minimal policy with default_action: deny. Allow one agent to call one tool for one task. Enable audit and metrics. Send denial events somewhere searchable. Then test with poisoned descriptions, hidden Unicode, suspicious schemas, hostile webpage content, fake credential strings, and tool output that tries to override the agent’s instructions. If the model never sees the poison, that is a useful result. If the server refuses to start, that may be the most honest security signal you get all week.

This also belongs in code review. MCP policy files should be version-controlled and reviewed like infrastructure-as-code. Tool descriptions should be linted. Tool additions should require an owner, a purpose, a data-classification note, and a rollback path. Audit logs should identify the agent, tool, arguments class, decision, and sanitized output status. Nobody wants more paperwork. Nobody wants to explain why an enthusiastic coding agent had access to a deployment tool because “it helped during the demo” either.

The community signal is quiet so far — exact Hacker News searches around the package and Agent Governance Toolkit MCP extensions returned nothing meaningful during collection. That is normal for control-plane releases. Developers argue about models in public and discover missing audit logs in private. The repo signal is more useful: microsoft/agent-governance-toolkit showed 1,855 stars, 344 forks, 26 open issues, an MIT license, and recent activity. This is young infrastructure, but it is moving.

The editorial take: MCP is growing up from “connect anything” to “govern what you connected.” Microsoft’s .NET extension is not the final answer, and Public Preview means teams should test before trusting it. But policy, identity, scanning, sanitization, and audit belong in the MCP server path. If agents are going to call real tools, the runtime needs to become boringly strict. That is not anti-agent. That is how agents graduate from demo theater to software engineering.

Sources: Microsoft .NET Blog, Microsoft .NET Blog governance walkthrough, microsoft/agent-governance-toolkit, NuGet package, MCP C# SDK API docs