Microsoft Foundry absichern: Netzwerk, Identität und Guardrails

KI-Agenten in der Produktion sind ein Sicherheitsthema, nicht nur ein KI-Thema. Ein Agent verfügt über eine Identität, Netzwerkpfade, ruhende Daten und ein Verhalten, das er kontrollieren muss. In diesem Blogbeitrag erkläre ich, wie ich Microsoft Foundry aus Sicht des IT-Administrators durchgängig absichere: Netzwerkisolation, Agentenidentitäten, RBAC, Verschlüsselung und Leitplanken. Dies ist die Checkliste, die ich jedem Team geben würde, das einen Foundry-Agenten vom Playground in die Produktion verlagern möchte.

Ich denke in vier Schichten darüber nach und werde sie in dieser Reihenfolge durchgehen.

Schicht 1: Wie isoliere ich das Netzwerk?

Microsoft Foundry verfügt über drei Netzwerkbereiche. Sie steuern separat: eingehenden Datenverkehr zur Foundry-Ressource, ausgehenden Datenverkehr zu abhängigen Diensten und das Netzwerk der Agentenlaufzeit selbst.

Eingehend ist klassisches Azure: ein privater Endpunkt auf dem Konto Foundry plus publicNetworkAccess: Disabled. Sie benötigen drei private DNS-Zonen: privatelink.cognitiveservices.azure.com, privatelink.openai.azure.com und privatelink.services.ai.azure.com.

Die Agentenlaufzeit ist der interessante Teil. Mit dem Standard-Agent-Setup injizieren Sie die Agent-Laufzeit in ein delegiertes Subnetz in Ihrem eigenen VNet (Delegation Microsoft.App/environments, mindestens /27, empfohlen /24). Microsofts Garantie für dieses Setup: kein öffentlicher Ausgang und der gesamte Agentenstatus bleibt in den Ressourcen, die Sie besitzen:

• Azure Storage – Dateien, mit denen der Agent arbeitet
• Azure AI Search – Vektorspeicher – Azure Cosmos DB – Threads und Nachrichten

Das bedeutet, dass der Gesprächsverlauf und die hochgeladenen Dateien gemäß Ihren Verschlüsselungs- und Aufenthaltsregeln in Ihrem Mandanten gespeichert sind. Seit März 2026 kann Tool-Verkehr (MCP, Azure AI Search, Fabric) auch über private Pfade fließen. Für das gesamte Setup gibt es vorgefertigte Bicep- und Terraform-Beispiele – verwenden Sie sie, die Abhängigkeitskette ist lang.

Hinweis: Für „Kein öffentlicher Ausgang“ gibt es Ausnahmen. Bing Grounding, Websuche und SharePoint Grounding laufen auch in einer isolierten Konfiguration immer noch über öffentliche Microsoft-Endpunkte. Wenn dies nicht akzeptabel ist, blockieren Sie diese Tools über Azure Policy. Und eine schwierige Frage: Die ausgehende VNet-Injektion kann nicht zu einer vorhandenen Ressource hinzugefügt werden – Sie müssen sie von Anfang an bereitstellen oder erneut bereitstellen.

Schicht 2: Welche Identität hat ein Agent?

Hier hat Microsoft etwas wirklich Neues getan. Mit Microsoft Entra Agent ID (GA seit April 2026) erhalten Agenten erstklassige Identitäten in Entra – sichtbar, steuerbar und widerrufbar wie Benutzer und Dienstprinzipale.

So funktioniert es in Foundry (Details): Wenn der erste Agent in einem Projekt erstellt wird, stellt Foundry einen Agentenidentitätsentwurf und eine gemeinsame Agentenidentität für das Projekt bereit. Alle Agenten in der Entwicklung teilen diese Identität. Wenn Sie einen Agent veröffentlichen, erhält dieser seine eigene dedizierte Identität. Zur Laufzeit gibt es keine Geheimnisse – der Blueprint verfügt über eine föderierte Anmeldeinformationsvertrauensstellung mit der verwalteten Identität des Projekts, und Entra stellt kurzlebige Token aus, die auf eine bestimmte Zielgruppe ausgerichtet sind, wie z. B. https://graph.microsoft.com.

Für Sie als Administrator bedeutet dies: Öffnen Sie das Entra Admin Center unter Agent ID > Alle Agentenidentitäten, und Sie sehen jeden Agenten im Mandanten – von Foundry, Copilot Studio und Plattformen von Drittanbietern. Von dort aus können Sie bedingten Zugriff auf Agenten anwenden, riskante Agenten im Identitätsschutz überwachen und ihnen eine Lebenszyklus-Governance (Eigentümer, Ablauf) auferlegen.

Das Gewähren des Zugriffs auf eine Ressource durch einen Agenten erfolgt auf die gleiche Weise wie für jeden anderen Dienstprinzipal:

az role assignment create \
  --assignee "<agentIdentityId>" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<sa>"

Hinweis: Der Veröffentlichungsschritt ist eine Falle. Da durch das Veröffentlichen eine neue Identität erstellt wird, werden die Rollenzuweisungen der Entwicklungsidentität nicht übernommen. Fügen Sie „RBAC der veröffentlichten Agentenidentität neu zuweisen“ in Ihre Release-Checkliste ein, andernfalls funktioniert der Agent in der Entwicklung und schlägt in der Produktion fehl.

Ebene 3: Wer darf was tun? Die Foundry RBAC-Rollen

Im Mai 2026 benannte Microsoft die integrierten Rollen um – „Azure AI User“ lautet jetzt Foundry User und so weiter. Die Rollen-IDs blieben gleich, sodass keine erneute Bereitstellung erforderlich war. Dies sind die fünf Rollen, mit denen ich tatsächlich arbeite:

Zwei Details, die leicht zu übersehen sind. Erstens funktionieren Rollenzuweisungen für drei Bereiche: Konto, Projekt und sogar einen einzelnen Agenten – der Agentenbereich wird für den Endpunktzugriff ausgewertet, sodass Sie genau einem Agenten eine App-Berechtigung erteilen können. Zweitens umfassen Azure-Besitzer oder Mitwirkende im Abonnement keine Datenaktionen: Ein Abonnementbesitzer kann keine Agenten anrufen. Das verwirrt die Leute in jedem Projekt, das ich gesehen habe.

Hinweis: Die schlüsselbasierte Authentifizierung umgeht RBAC vollständig – wer den Schlüssel hat, hat alles. Ich deaktiviere die lokale Authentifizierung für die Ressource Foundry und verwende, wo immer möglich, nur Entra.

Ebene 4: Wie kontrolliere ich das Agentenverhalten? Leitplanken

Die Inhaltssicherheit in Foundry wurde 2026 in Leitlinien und Kontrollen neu organisiert. Eine Leitplanke ist eine benannte Sammlung von Kontrollen, und jede Kontrolle ist ein Risiko plus einen Interventionspunkt plus eine Aktion. Neu für Agenten: Neben Benutzereingaben und Modellausgaben können Sie jetzt auch bei Tool Call und Tool-Antwort eingreifen (beide Vorschau). Genau dort lebt die indirekte Prompt-Injektion – ein vergiftetes Dokument, das von einem Retrieval-Tool zurückkommt.

Was ich für einen Produktionsagenten einschalte:

1. Die vier Schadenskategorien (Hass, Sexualität, Selbstverletzung, Gewalt) mit mittlerem Schweregrad – das ist sowieso die Standardeinstellung.
2. Prompt Shields für direkte Jailbreaks und indirekte Angriffe, die in Inhalte Dritter eingebettet sind.
3. Task Adherence (Vorschau) – wird markiert, wenn der Agent von seinen Anweisungen abweicht.
4. Eine Blockliste mit den internen Begriffen, die das Unternehmen niemals verlassen dürfen (bis zu 10.000 Begriffe, Regex unterstützt).

Hinweis: Eine Agentenleitplanke überschreibt die Modellleitplanke vollständig – sie verschmilzt nicht mit ihr. Wenn Sie dem Agenten eine schmale Leitplanke zuweisen, können Sie Filter, die der Model Deployment hatte, stillschweigend ausschalten. Überprüfen Sie den effektiven Satz, nicht den beabsichtigten.

Zusätzlich zu den integrierten Filtern habe ich Microsoft Defender für Cloud AI Threat Protection eingefügt. Seit Februar 2026 deckt es Foundry-Agenten ab, derzeit ohne zusätzliche Token-Kosten. Es korreliert Prompt Shields-Signale mit Microsoft-Bedrohungsinformationen und löst Warnungen vor Jailbreaks, Datenlecks oder Anmeldedatendiebstahl in Defender XDR aus – wo sich das SOC bereits befindet. Über die Endpunktseite habe ich in KI-Agenten mit Microsoft Defender schützen geschrieben.

Was ist mit Verschlüsselung und Datenresidenz?

Standardmäßig verwaltet Microsoft die Schlüssel. Wenn die Compliance dies erfordert, können Sie vom Kunden verwaltete Schlüssel aus Key Vault oder Managed HSM mitbringen. Anforderungen: gleiche Region, vorläufiges Löschen plus Bereinigungsschutz und eine verwaltete Identität mit Unwrap-Berechtigungen. Beachten Sie, dass dies eine Einbahnstraße ist – Sie können von Microsoft-verwaltet zu CMK wechseln, aber nicht zurück.

Das Schöne an der Standard-Agent-Einrichtung: Da Threads, Dateien und Vektoren in Ihrer eigenen Cosmos DB leben, folgen Speicher und KI-Suche, Residenz und Verschlüsselung einfach diesen Ressourcen. Die Modelle Prompts werden je nach Bereitstellungstyp innerhalb der Bereitstellungsregion verarbeitet und nicht für Schulungen verwendet.

Der Ansatz, den ich tatsächlich verwende

Für einen Produktions-Rollout mache ich es in dieser Reihenfolge:

1. Stellen Sie die Ressource Foundry mit Netzwerkisolation vom ersten Tag an bereit (Bicep-Beispiel 15), da Sie die VNet-Injektion nicht nachrüsten können.
2. Nur-Eingangs-Authentifizierung, lokale Schlüssel deaktiviert.
3. RBAC minimal: Entwickler erhalten Foundry User für das Projekt, Apps erhalten Foundry Agent Consumer für genau einen Agenten.
4. Guardrail-Set pro Agent: Standardwerte plus Prompt Shields plus Blocklist; Task Adherence zuerst im Audit-Modus.
5. Defender für Cloud AI-Plan aktiviert, Warnungen mit dem SOC verbunden.
6. CMK nur, wenn Compliance dies ausdrücklich verlangt.

Fallstricke, die ich jetzt vermeide

• Netzwerkisolation nachrüsten. Für das Agent-Subnetz nicht möglich. Entscheiden Sie sich vor dem ersten Einsatz. – RBAC nach der Veröffentlichung vergessen. Neue Identität, leere Berechtigungen. Release-Checkliste.
• Vertrauenswürdig „privat“ für jeden Tool. Die Sperrung von Bing und SharePoint bleibt öffentlich – blockieren Sie sie bei Bedarf über Richtlinien.
• Zuweisung schlanker Agent-Leitplanken. Überschreiben, nicht zusammenführen. Überprüfen Sie die wirksamen Filter.
• API-Schlüssel aktiviert lassen „für den Schnelltest“. Sie umgehen alles, worum es in diesem Beitrag geht.

Wohin das führt

Die Agentensicherheit konvergiert mit der normalen Identitäts- und Netzwerksicherheit, und das ist eine gute Nachricht: Bedingter Zugriff, RBAC, private Endpunkte und SOC-Alarmierung sind Stärken, über die Ihr Unternehmen bereits verfügt. Die neue Foundry Control Plane (Vorschau) vereint die Steuerung der gesamten Agentenflotte an einem Ort, und die Purview-Integration bringt Prompts und Antworten in die Compliance-Welt. Mein Rat: Behandeln Sie jeden Agenten wie einen neuen Mitarbeiter – er erhält eine Identität, die geringsten Privilegien, eine Netzwerkrichtlinie und Aufsicht. Beginnen Sie mit den Dokumenten zur Netzwerkisolation und erstellen Sie von dort aus die Checkliste.

Ich hoffe, das erspart Ihnen ein oder zwei Sicherheitsüberprüfungsrunden.

Bleiben Sie gesund,

Prost Jannik