Agent 365 MCP Governance: Sechs Tests für APIM

Ein blockiertes Tool im Admin-Portal sieht beruhigend aus. Meine nächste Frage ist etwas unbequemer: Kann derselbe Agent den Dienst dahinter trotzdem direkt aufrufen?

Genau damit würde ich die neue Verbindung zwischen Agent 365 und Azure API Management prüfen. Nicht nur fragen, ob ein MCP-Server in einer Liste auftaucht. Sondern nachweisen, ob die gewünschte Aktion auf dem tatsächlich genutzten Weg verhindert wird.

Ich habe mir dafür den aktuellen Stand in meinem Modern-Device-Management-Tenant angesehen. Dabei sind drei Dinge zu trennen: ein sichtbares Tool, eine bearbeitbare Richtlinie und nachgewiesene Durchsetzung zur Laufzeit. Dieser Artikel zeigt die Unterschiede und einen konkreten Abnahmeplan für einen Pilotbetrieb.

Was im Tenant tatsächlich zu sehen war

Unter Microsoft 365 Admin Center → Agents → Tools sind MCP-Server und deren Tool-Details sichtbar. Beim Eintrag Work IQ konnte ich beispielsweise ask, fetch, create, update und delete ansehen.

Das ist schon eine deutlich bessere Gesprächsgrundlage als „der Agent darf auf Microsoft 365 zugreifen“. Lesen und Schreiben sind unterschiedliche Fähigkeiten. Eine Tool-Beschreibung ist aber noch keine Berechtigungsregel.

Aufnahme vom 12. Oktober 2026. Zu sehen ist das Work-IQ-Inventar, keine erfolgreich eingerichtete APIM-Verbindung. Die einzelnen Schalter waren in dieser Sitzung deaktiviert. Ich habe nichts umgestellt.

Unter Agents → Settings fehlte in diesem Tenant außerdem der Eintrag Gateways, den Microsoft in der Einrichtung beschreibt. Ob das am Rollout, einer Voraussetzung oder der konkreten Konfiguration liegt, lässt sich daraus allein nicht ableiten.

Das ist eine konkrete offene Voraussetzung in diesem Tenant. Es bedeutet nicht, dass die Funktion generell nicht verfügbar wäre.

Deshalb ist der folgende Ablauf eine Kombination aus dokumentierter Einrichtung und meinem vorgeschlagenen Prüfplan. Er ist kein Bericht über eine hier bereits aktivierte Gateway-Verbindung.

Was die APIM-Integration verändert

Microsoft verbindet mit der Ankündigung vom 9. Oktober die Governance-Entscheidungen in Agent 365 mit deren Durchsetzung am unterstützten APIM-Gateway. APIM v2 unterstützt Kontrollen auf Serverebene. Der AI-Gateway-Tier ergänzt unter anderem feinere Tool-Kontrollen, Aktivitätseinblicke und Threat Protection. Die Integration ist eine Public Preview, keine pauschale Eigenschaft jeder APIM-Variante. Microsoft-Ankündigung.

Meine technische Schlussfolgerung: Eine Kontrolle braucht einen Durchsetzungspunkt im tatsächlichen Anfrageweg. Ich würde deshalb zuerst zwei Wege aufzeichnen.

Der erste Weg ist beabsichtigt: Agent, Gateway, Backend. Der zweite wird gern vergessen: Agent, Backend. Eine Anfrage, die das Gateway nie erreicht, kann es auch nicht ablehnen. Ob dieser zweite Weg existiert, muss man in der eigenen Architektur prüfen.

Das ist kein Argument gegen die Integration. Es ist die Abnahmebedingung, die aus einer sichtbaren Einstellung eine brauchbare Kontrolle macht.

Mit einem Tool und einer Geschäftsaktion beginnen

Ich würde im ersten Pilot nicht das gesamte Tool-Inventar verbinden. Ein risikoarmer Testdienst reicht. Er bekommt zwei klar getrennte Operationen:

• get_ticket liest ein fiktives Ticket.
• close_ticket verändert ausschließlich dessen Teststatus.

Das sind Beispielnamen, keine vorhandenen Work-IQ-Operationen. Die Daten bleiben fiktiv. Die Testidentität erhält keine Rechte auf echte Kundentickets.

Im Prüfblatt stehen MCP-Endpunkt, Backend-Endpunkt, erwartete Token-Audience und erlaubte Operation. Zugangsdaten gehören nicht hinein.

Mein Ziel wäre: Lesen funktioniert. Schließen wird für die eingeschränkte Identität verhindert. Und ein gleichwertiger Direktaufruf darf die Sperre nicht umgehen.

Damit wird auch eine Schwäche im Tool-Design sichtbar. Ein einziges großzügiges execute-Tool mit beliebigen Befehlen ist schwerer sinnvoll zu begrenzen als getrennte fachliche Operationen. Der freundliche Tool-Name ersetzt keine Backend-Autorisierung.

So würde ich die Verbindung vorbereiten

1. Voraussetzungen vor der Zustimmung prüfen

Zuerst Gateway-Tier, registrierten MCP-Server, Verwaltungsrolle und den dokumentierten Gateways-Eintrag prüfen. Microsoft beschreibt eine tenantweite Zustimmung durch einen Global Administrator. Anschließend werden die im verbundenen Gateway registrierten Server entdeckt – nicht sämtliche MCP-Server irgendwo im Unternehmen oder Internet. Manage Tools Gateway.

In meinem Tenant war beim fehlenden Eintrag Schluss. Für ein schöneres Demo-Ergebnis würde ich weder andere Berechtigungen vergeben noch einen zusätzlichen Dienst aufsetzen.

Im echten Pilot gehört die Zustimmung ins Change-Protokoll: Wer hat sie für welchen Tenant, welche Anwendung und welchen Zweck freigegeben? „Im Demo einmal auf Accept geklickt“ reicht dafür nicht.

2. Den gefundenen Eintrag dem richtigen Endpunkt zuordnen

Nach freigegebener Einrichtung den Server unter Agents → Tools öffnen. Identität und Endpunkt müssen zu Gateway-Konfiguration und Agent-Verbindung passen.

Nur der Anzeigename genügt nicht. „Helpdesk MCP“ kann gleichzeitig in Entwicklung, Test und Produktion existieren. Das Prüfprotokoll muss diese Umgebungen eindeutig auseinanderhalten.

Auch die Herkunft des Eintrags ist wichtig. Mein Work-IQ-Screenshot zeigt die Tool-Ansicht. Er beweist nicht, dass ein eigener APIM-Server erfolgreich entdeckt wurde.

3. Die tatsächliche Granularität prüfen

Microsoft beschränkt einzelne Tool-Kontrollen auf unterstützte Servertypen und die verfügbare Rollout-Stufe. Ohne passende Tool-Discovery kann nur die Entscheidung für den gesamten Server bleiben. Einzelne MCP-Tools verwalten.

Kann ich die Schreibaktion nicht separat sperren, würde ich entweder den Tool-Vertrag aufteilen oder bewusst die gesamte Serverfunktion begrenzen. Beides hat Folgen für den lesenden Anwendungsfall. Diese Entscheidung gehört erklärt, nicht hinter „Least Privilege“ versteckt.

4. Genau eine Entscheidung im Pilot testen

Eine Änderung nach der anderen. Zeitpunkt, Tool- beziehungsweise Server-ID, handelnde Person und Richtlinienstand festhalten. Danach genau die vereinbarte Operation mit der Testidentität über den erwarteten Weg ausführen.

Ein Fehler im Client genügt nicht als Erfolg. Ein abgelaufenes Token verursacht ebenfalls einen Fehler. Ich möchte erkennen können, dass die gewünschte Kontrolle die Ablehnung ausgelöst hat.

Sechs Tests für die Abnahme

Das ist mein vorgeschlagener Testplan. Keine Zeile beschreibt ein bereits gemessenes Ergebnis aus dieser Sitzung.

Beim Direktaufruf keine zusätzlichen Rechte vergeben, nur damit der Test möglich wird. Existiert kein gleichwertiger Zugangsweg, diese Tatsache und den Grund dokumentieren. Einen künstlichen Bypass zu bauen wäre eine andere Aufgabe.

Pro Versuch würde ich Korrelationsmarker, UTC-Zeit, effektive Identität, Gateway-Ergebnis und Backend-Ergebnis erfassen. Keine Bearer Tokens, Subscription Keys oder vollständigen Geschäftsdaten.

Vor und nach dem Aufruf sind unterschiedliche Schutzpunkte

Die angekündigte Threat Protection kann Anfrage und Ergebnis eines Tools bewerten. Eine Prüfung vor dem Aufruf kann dessen Ausführung verhindern. Eine Prüfung danach kann eine unsichere Rückgabe vom Agenten fernhalten. Microsoft-Ankündigung.

Für mich folgt daraus: Bei einer nicht einfach rückgängig zu machenden Schreibaktion reicht ein Ergebnisfilter nicht. Eine bereits versendete E-Mail wird nicht zurückgeholt, nur weil anschließend der Antworttext gefiltert wird. Für Ticketschließungen oder Berechtigungsänderungen gilt dieselbe Logik.

Bei einem lesenden Tool ist eine Ausgabekontrolle dagegen ein anderer, sinnvoller Schutzpunkt. Autorisierung, gegebenenfalls menschliche Freigabe und Ergebnisprüfung ergänzen sich. Sie ersetzen einander nicht.

Ein kurzes Incident-Protokoll ist hilfreicher als ein großes Dashboard

Angenommen, das Helpdesk meldet: Der Agent hat ein Ticket geschlossen, das er nur zusammenfassen sollte. Ich würde zuerst fünf Fragen klären:

1. Welche Operation hat den Zustand verändert, mit welcher Identität?
2. Lief die Anfrage tatsächlich durch das verwaltete Gateway?
3. Welcher Richtlinienstand galt zu diesem Zeitpunkt?
4. War eine Prüfung vor dem Aufruf, nach dem Aufruf oder gar keine vorgesehen?
5. Erlaubte das Backend mehr als der Tool-Vertrag vermuten ließ?

Der heutige Status „Blocked“ beantwortet keine dieser historischen Fragen allein.

Die Governance-Entscheidung würde ich beim AI-Admin verorten, den Anfrageweg beim Plattformteam und die Backend-Rechte beim Service Owner. Für die Untersuchung braucht es alle drei. Sonst sieht jedes Team in seinem Ausschnitt einen korrekten Zustand, obwohl die unerwünschte Aktion stattgefunden hat.

Häufige Fragen zu Agent 365 MCP Governance

Erzwingt ein Eintrag im Agent-365-Register bereits die Zugriffsregeln?

Nein. Das Inventar zeigt ein Objekt. Die Kontrolle muss im tatsächlichen Anfragepfad greifen. Bei Agent 365 MCP Governance mit API Management prüfst du unterstützte Integration, Richtlinienentscheidung und Gateway-Verhalten getrennt.

Was unterscheidet Agent-Registrierung und Tool-Governance?

Die Registrierung mit Python und Entra macht Identität und Registereintrag sichtbar. Sie beweist nicht, dass jeder Tool-Aufruf durch das Gateway läuft. Genau dafür sind die sechs Abnahmetests oben gedacht.

Welche Rolle übernimmt API Management?

Mein MCP-Control-Plane-Guide für API Management erklärt die Gateway-Grenze. Prüfe zusätzlich den direkten Backend-Pfad: Eine Gateway-Sperre reicht nicht, wenn dieselbe Aktion andernorts erreichbar bleibt.

Mein Entscheidungsblatt

Für den Schritt davor ist mein Foundry-Python-Agent-Walkthrough ein Einstieg. Registrierung beschreibt, was der Agent ist. Diese Prüfung zeigt, was er tatsächlich darf.

An der neuen Integration finde ich spannend, dass Governance näher an die Ausführung rückt. Meine Messlatte bleibt einfach: Zeig mir die gestoppte Anfrage – und dass die Aktion im Backend nicht passiert ist.