Letzten Monat saß ich beim Abschlussgespräch mit einem Maschinenbauer, 80 Mitarbeitende, Standort Niederbayern. Die hatten sich selbst einen kleinen KI-Assistenten gebaut — Python-basiert, kein .NET weit und breit — der intern Angebotsdaten aus dem ERP ziehen und zusammenfassen sollte. Technisch funktionierte das. Dann fragte ich: "Wer prüft eigentlich, was der Agent aus dem ERP zurückbekommt, bevor er das dem Nutzer zeigt?" Schweigen. Kurzes Nachdenken. "Das … macht er halt selbst." Das Thema Governance war bis zu diesem Gespräch buchstäblich nicht auf dem Radar.
Ich erzähle das, weil der Artikel, den ich heute kommentiere, genau dieses Problem adressiert — nur in einem anderen Stack, für eine andere Zielgruppe, mit einem anderen Reifegrad als Ausgangspunkt.
Was Microsoft hier vorstellt
Das .NET-Team hat Microsoft.AgentGovernance.Extensions.ModelContextProtocol veröffentlicht, ein Preview-Paket, das sich als Erweiterung in den bestehenden MCP-C#-SDK-Builder einhängt. Der Kern ist eine einzige Methode — WithGovernance(...) — die beim Startup alle registrierten Tools scannt (auf Prompt-Injection-Muster, Typosquatting, versteckte Unicode-Zeichen, Schema-Missbrauch), zur Laufzeit jede Tool-Ausführung gegen YAML-basierte Policies prüft und das Ergebnis vor Rückgabe ans Modell bereinigt. Alle gefährlichen Defaults sind auf "fail closed" gesetzt: unbekannte Tools werden blockiert, nicht durchgelassen. Das Logging und Metriken kommen automatisch mit. Der Post ist technisch präzise, die Abstraktionen sind sauber, und die Sicherheitsüberlegungen hinter dem Paket sind legitimate — kein Marketing-Bingo.
Wie das im Mittelstand wirklich landet
Lass mich direkt sein: Wenn du ein KMU mit 30 bis 300 Mitarbeitenden bist und du heute ernsthaft fragst "Brauchen wir dieses Paket?", ist die Antwort fast sicher nein — aber aus einem Grund, der nichts mit der Qualität des Pakets zu tun hat.
Das Paket löst ein reales Problem. Nur löst es das Problem für Teams, die bereits MCP-Server in .NET bauen und sich bereits die Frage stellen, wie sie Tool-Zugriff strukturieren. In meiner Beratungspraxis sind das im Mittelstand ungefähr fünf Prozent der Unternehmen, die KI-Projekte laufen haben. Der Rest nutzt SaaS-Wrappers, Python-Skripte, n8n-Workflows oder kauft fertige Lösungen ein.
Das heißt nicht, dass die Konzepte hinter dem Paket irrelevant wären. Im Gegenteil. Die vier Risikokategorien, die das Paket adressiert, existieren unabhängig vom Stack:
Tool Poisoning und Prompt Injection in Tool-Antworten sind kein .NET-Problem, das sind Architektur-Probleme. Wenn dein Agent externe Datenquellen abfragt — ERP, CRM, eine REST-API eines Lieferanten — und das Ergebnis ungefiltert zurück ins Modell fließt, hast du denselben Angriffsvektor, egal ob du C# oder Python oder einen No-Code-Builder verwendest.
Policy-basierte Zugriffssteuerung auf Tool-Ebene klingt nach Enterprise-Overhead, ist aber eigentlich nichts anderes als die Frage: "Welcher Agent darf welches Werkzeug aufrufen, und mit welchen Rechten?" Die meisten KMU-Projekte, die ich sehe, haben dafür keine Antwort. Nicht weil niemand darüber nachgedacht hätte, sondern weil es im ersten Sprint nie auf der Liste stand und danach nie mehr dazu kam.
Was mich an der .NET-zentrischen Perspektive des Artikels beschäftigt: Das eigentliche Problem im Mittelstand ist nicht die fehlende Governance-Library. Es ist, dass der Mittelstand meistens keinen klaren Überblick hat, welche Agents überhaupt welche Tools exponieren — und das ist ein Prozess- und Dokumentationsproblem, kein Paket-Problem.
Ich habe in den letzten 18 Monaten bei keinem Unternehmen unter 200 Mitarbeitenden eine vollständige Übersicht der laufenden KI-Workflows vorgefunden. Nicht eine. Wenn du nicht weißt, dass dein CRM-Connector auch Schreibrechte hat, nützt dir das schönste Governance-Framework nichts.
Was ich konkret empfehle
Wenn du .NET und MCP einsetzt: Lies den Original-Artikel vollständig, und evaluiere das Paket. Es ist pragmatisch gebaut, und "fail closed by default" ist genau die richtige Philosophie. Der Einstieg via WithGovernance(...) kostet dich weniger als eine Stunde, und du bekommst Audit-Logs und Response-Sanitization geschenkt. Das ist ein günstiger Deal.
Wenn du nicht in .NET unterwegs bist, aber KI-Agents im Einsatz hast: Nimm die Konzept-Liste aus dem Artikel und gehe sie manuell durch:
- Scannt irgendetwas deine Tool-Definitionen auf Injection-Muster, bevor sie dem Modell exponiert werden?
- Gibt es eine Policy — auch nur eine informelle Liste in Confluence — welcher Agent welche Systeme anfassen darf?
- Werden Tool-Antworten vor der Rückgabe ans Modell gefiltert, insbesondere wenn sie von externen Systemen kommen?
Wenn du bei einer dieser Fragen zögerst: Das ist dein nächstes Projekt. Nicht das Tool-Paket, das Design dahinter.
Der vollständige Original-Beitrag von .NET Blog (MS): Announcing Agent Governance Toolkit MCP Extensions for .NET
Du willst das für deinen spezifischen Stack und dein Team durchdenken — ohne dass ich dir vorher fünf Beratungsstunden verkaufe? Dann ist das hier der richtige nächste Schritt:
— Bernhard