Foundry Egress Audit: Vier Tests für Transform und Rewrite

„Erst einmal auf Audit stellen“ klingt nach einem sicheren Weg, Verkehr unverändert zu beobachten. Bei Foundry-Egress-Regeln für Hosted Agents fehlt dann eine Frage: Welche Aktionen stehen in der Richtlinie?

Audit verändert das Verhalten von Deny. Transform und Rewrite werden dadurch nicht passiv. Eine vermeintliche Beobachtungsrichtlinie kann also weiterhin Header verändern oder Anfragen umleiten.

Ich habe dafür das aktuelle Foundry-Portal in meinem Modern-Device-Management-Tenant geöffnet und einen kleinen lokalen Prüfcode vorbereitet. Die Screenshots sind echt. Die Beispielregeln wurden nicht gespeichert oder einem Agenten zugewiesen.

Zuerst den Geltungsbereich prüfen

Der Weg in meinem Projekt war Build → Guardrails → Create → Network → Egress rules → Add rules.

Die Oberfläche sagt ausdrücklich: Die Netzwerkregeln gelten für Hosted Agents, nicht für Prompt-based Agents oder Model Deployments. Das muss geklärt sein, bevor wir über die Wirkung einer Regel sprechen.

Unter Operate → Compliance → Guardrails konnte ich außerdem die Modell-Guardrails ansehen. Diese Tabelle würde ich nicht als Nachweis für den ausgehenden Netzwerkverkehr eines Hosted Agents verwenden.

Modellfilter, Richtlinienzuweisung und ausgesendete Anfrage sind unterschiedliche Dinge. Ein brauchbarer Prüfbericht benennt, welches davon gerade betrachtet wird.

Audit ist kein allgemeiner Trockenlauf

Microsoft beschreibt: In Audit wird eine sonst abgelehnte Anfrage protokolliert, aber nicht blockiert. Transform und Rewrite werden dagegen in beiden Modi ausgeführt. Die Funktion ist in Preview. Hosted-Agent-Egress-Dokumentation.

Meine Schlussfolgerung ist nicht „Audit ist gefährlich“. Sondern: Beim Change Review die Aktion lesen, nicht nur den Modus. Eine Audit-Richtlinie mit Allow/Deny hat andere betriebliche Auswirkungen als eine mit umgeschriebenen Zielen.

„Ist ja nur Audit“ wäre für mich keine ausreichende Begründung zur Freigabe einer Routingänderung.

Was sich im echten Portal auswählen lässt

Für die Aufnahme habe ich Audit, anschließend Transform und harmlose Beispielwerte ausgewählt:

• Host match: api.demo.invalid
• Header: X-Demo-Route
• Operation: Set
• Statischer Wert: audit-check

Die .invalid-Namen sind absichtliche Platzhalter, keine aufgerufenen Endpunkte. Die Ansicht belegt die angebotene Kombination. Das Laufzeitverhalten stammt aus der Dokumentation; hier wurde kein Verkehr durch eine angewendete Richtlinie geschickt.

Danach habe ich Rewrite mit einem zweiten fiktiven Ziel gewählt:

Genau deshalb würde ich solche Änderungen wie andere Routingänderungen behandeln. Wenn die Anfrage bei einem anderen Empfänger ankommt, verrät eine plausible Agent-Antwort noch nicht, was im Hintergrund passiert ist.

Mein Beispiel: Ein eigener Dienst gibt den Testmarker zurück

Zum Validieren würde ich einen kleinen eigenen Echo-Dienst im Labor verwenden, keine Kunden-API. Er gibt einen nicht sensiblen Marker zurück und zeichnet auf, über welchen Testweg die Anfrage ankam. Authentifizierungsheader darf er weder zurückgeben noch protokollieren.

Das Experiment beantwortet zwei unabhängige Fragen:

1. Darf die Anfrage weiterlaufen oder wird sie gestoppt?
2. Kommen ursprüngliches Ziel und erwarteter Marker beim Dienst an?

Wer nur die abschließende Agent-Antwort prüft, kann die zweite Frage übersehen. Das Modell kann auch eine unerwartete Antwort überzeugend zusammenfassen.

Jeder Versuch erhält einen eigenen X-Test-Case und eine UTC-Zeit. Beim Empfänger reichen Testfall, sicherer Marker, Route und Status. Tokens und echte Benutzerinhalte werden dafür nicht gebraucht.

Vier Fälle für den Pilot

Das ist ein vorgeschlagener Abnahmeplan, keine gemessene Ergebnisliste. Voraussetzung sind ein unterstützter Hosted Agent und genehmigte Testendpunkte.

Anfrageinhalt und Identität zwischen den Fällen konstant halten. Sonst wird ein Authentifizierungsfehler oder eine Codeänderung schnell der falschen Richtlinie zugeschrieben.

Vor Fall C würde ich prüfen, dass beide Testempfänger hinsichtlich Authentifizierung zusammenpassen und keine echten Daten bekommen. Eine Umleitung verändert den Empfänger. Das ist mehr als ein weiterer Filterhaken.

Die Richtlinie vor dem Deployment lesen

Die RAI-Ressource enthält getrennte Einstellungen für Content Safety und Egress. Der Wert in properties.mode ist nicht automatisch der Egress-Modus. Dafür ist properties.egressPolicy mit eigener Betriebsart und geordneter Regelliste relevant. In den dokumentierten ARM-Beispielen heißt der durchsetzende Wert Enforced, die Oberfläche zeigt „Enforce“. RAI-Ressourcenreferenz.

Mit Azure CLI lässt sich eine vorhandene Richtlinie rein lesend exportieren. Vorher bewusst die richtige Test-Subscription auswählen. POLICY_ID ist die vollständige ARM-ID der vorhandenen Richtlinie:

az rest --method get \
  --url "https://management.azure.com${POLICY_ID}?api-version=2026-05-15-preview" \
  --output json > policy.json

Den Abfragezeitpunkt zum Export ablegen. Eine lokal bearbeitete Datei mit gleichem Namen ist kein Nachweis des aktuell bereitgestellten Zustands.

Für genau die Audit-Falle reicht als erster lokaler Check:

import json
from pathlib import Path

policy = json.loads(Path("policy.json").read_text())
egress = policy.get("properties", {}).get("egressPolicy")
if not isinstance(egress, dict):
    raise SystemExit("No egress policy found; do not infer one from content safety.")

if egress.get("mode") == "Audit":
    for rule in egress.get("rules", []):
        action = rule.get("action", {}).get("actionType")
        if action in {"Transform", "Rewrite"}:
            print(f"REVIEW: {rule.get('name')}: {action} still runs in Audit")

Der Code emuliert Azure nicht. Er validiert weder das gesamte Schema noch die Zuweisung zum Agenten. Er findet einen konkreten Review-Fehler vor dem Deployment.

Zusätzlich habe ich einen ausführlicheren lokalen Checker mit sechs Unit-Tests vorbereitet. Sie prüfen an einem synthetischen Beispiel Audit-Mutationen, Moduswechsel, einfache Reihenfolgekonflikte, fehlende Daten, pfadbegrenzte Regeln und unveränderte Eingabedaten. Alle sechs liefen erfolgreich. Das belegt die getesteten Eigenschaften des Checkers – keine Cloud-Durchsetzung.

First Match Wins: Die zweite leicht übersehene Falle

Die erste passende Regel entscheidet. Ein breites Allow vor einem spezifischen Deny kann die beabsichtigte Ausnahme unerreichbar machen. Genau diese Reihenfolge steht auch am Portal-Editor. Microsofts Egress-Walkthrough.

Ein bewusst unvollständiges Review-Beispiel, nicht als Deployment-Datei gedacht:

[
  {"name": "broad-allow", "host": "*.demo.invalid", "action": "Allow"},
  {"name": "specific-deny", "host": "api.demo.invalid", "action": "Deny"}
]

Für api.demo.invalid würde ich zuerst das frühere breite Allow prüfen, bevor ich dem späteren Deny vertraue. Eine Änderung der Reihenfolge verdient deshalb genauso ein Review wie eine neue Aktion.

Der lokale Checker erkennt bewusst nur einfache Überlappungen. Komplexe Wildcards, Pfade und Normalisierungsfälle werden nicht als angeblich vollständige Plattformlogik nachgebaut. Diese Fälle gehören mit der exakten Anfrage in den Laufzeittest.

Existiert die Richtlinie nur, oder gehört sie zu dieser Agent-Version?

Ich würde vier Angaben zusammenhalten: Foundry-Ressource, vollständige Policy-ID, Agent-Name und Agent-Version. Ein Bild des Editors beweist weder Zuweisung noch Wirkung.

Microsoft beschreibt dafür rai_config.rai_policy_name in der Hosted-Agent-Definition. Sinnvoll ist, die betreffende Agent-Version zurückzulesen und diesen Wert zu prüfen. Guardrail zuweisen und verifizieren.

Danach würde ich die serverseitig zurückgegebene Policy mit der geprüften Datei vergleichen. Passen sie nicht zusammen, ist zunächst die Abweichung zu klären.

Das wird besonders wichtig, wenn eine alte Agent-Version weiterläuft, während eine neue bearbeitet wird. Ein erfolgreicher Request kann schlicht über die alte Bereitstellung gegangen sein.

Rollback heißt: Einen bekannten Anfrageweg wiederherstellen

Vor der ersten Transform- oder Rewrite-Regel würde ich vorherige Richtlinie, Zuweisung und bekannte funktionierende Agent-Version sichern. Dazu einen kleinen Test definieren, der nach der Rücknahme die ursprüngliche Route bestätigt.

„Alles abschalten“ wäre nicht mein Standard-Rollback. Damit können andere Schutzfunktionen verloren gehen, die mit dem Fehler gar nichts zu tun haben. Eine gezielte Rückkehr zu einem geprüften Stand ist verständlicher als mehrere manuelle Schalter unter Zeitdruck.

Deshalb pro Versuch nur eine Dimension ändern: Modus, Host-Matching, Aktion oder Ziel. Ändert man alles gleichzeitig, ist ein fehlgeschlagener Aufruf kaum noch hilfreich.

Häufige Fragen zu Foundry Egress Audit

Lässt Audit jede Anfrage unverändert?

Nein. Bei den dokumentierten Netzwerk-Kontrollen für Hosted Agents beeinflusst Audit das Durchsetzen von Deny. Transform und Rewrite können passende Anfragen weiterhin ändern. Entscheidend ist die Aktion in der Regel, nicht nur der Modus.

Wie prüfe ich eine Foundry-Egress-Audit-Policy kontrolliert?

Prüfe zunächst die Regeln mit dem Offline-Checker. Vergleiche danach synthetische Markerdaten am freigegebenen Echo-Endpunkt. Die vier Testfälle oben trennen Ausgangszustand, Deny, Transform und Rewrite. Die lokalen Prüfungen ersetzen diesen Live-Test nicht.

Welche Kontrollen ergänzen die Egress-Policy?

Meine Einordnung zu Foundry-Netzwerk und Identität beschreibt die grössere Grenze. Tracing und Evaluation helfen beim Untersuchen eines Agent-Laufs. Beides ersetzt keine Prüfung auf Empfängerseite.

Meine Abnahmebedingungen

Mein Foundry-Python-Agent-Walkthrough behandelt den Schritt davor. Hier geht es um die Grenze für ausgehende Anfragen.

Die Kernbotschaft ist kurz: Audit verspricht keine unveränderte Anfrage. Lies die Aktion – und prüfe, was beim Empfänger ankommt.