Sichere KI-Shells: Sollte der Browser direkt mit Foundry sprechen oder nur über einen Proxy?

Browser-Shells verleiten Teams dazu, der SPA zu sehr zu vertrauen. Die Chat-Oberfläche sieht aus wie das Produkt. Der Proxy vor dem Agent-Backend ist aber die Stelle, an der aus Authentifizierung Autorisierung wird, an der ausgehender Verkehr begrenzt wird und an der gefährliche Payloads per Allowlist zugelassen oder verworfen werden.

Behandle den Proxy als Sicherheitsgrenze. Entscheide dich bewusst für Front Door, Application Gateway oder ein gleichwertiges Muster. Schraube TLS und Autorisierung nicht später an. Laufzeitabweichungen zwischen lokalem und Live-Proxy erzeugen falsche Sicherheit. Reasoning- und Passthrough-Payloads brauchen ausdrückliche Allowlists. Security-Reviews sollten beim Proxy beginnen, nicht beim System-Prompt.

Abbildung 1. Der Proxy als Control Plane. Die SPA ist ein Frontend. Der benannte Proxy verantwortet Identität, Scopes, ausgehenden Verkehr und Payload-Form, bevor Foundry oder deine Agent-API die Anfrage sieht.

Kontext und Rahmenbedingung

Ein typischer Fehler ist ein lokaler Proxy, der Demos sicher wirken lässt, während die Live-Edge mehr durchreicht, als je jemand geprüft hat. Die Prompts des Modells können in Ordnung sein, während die Grenze es nicht ist. Behandle den Proxy als Control Plane für Autorisierung und ausgehenden Verkehr, dann werden Reviews kürzer.

Tokens im Browser erzählen nicht die ganze Geschichte. Der Proxy muss die Identität prüfen, Scopes erzwingen, ausgehenden Verkehr auf freigegebene Backends begrenzen und überraschende Payload-Formen ablehnen. Wenn dein Bedrohungsmodell mit Prompt Injection beginnt und die Edge überspringt, optimierst du zuerst die falsche Ebene.

Abbildung 2 zeigt die Einordnung aus Learn für Gateway-Komponenten vor APIs. Behandle diese Kontrollen als Teil des Produkts, nicht als optionalen Feinschliff.

Abbildung 2. Härte den Pfad vom Browser zu den Agent-APIs. Gateway-Kontrollen sind Teil des Produkts, kein optionaler Feinschliff. Quelle: Microsoft Learn: Grundbegriffe von API Management.

Design

1. Den Proxy als Produktkomponente benennen

Dokumentiere, welcher Dienst TLS terminiert, Tokens prüft und an Microsoft Foundry oder deine API weiterleitet. "Der Node-Server im App Service" oder "Front Door plus API" sollte ein ausdrücklicher Kasten sein. Unbenannte Edges werden zu Edges ohne Verantwortlichen. Abbildung 1 zeigt diesen benannten Kasten als mittlere Spur.

2. Verhalten von lokalem und Live-Proxy angleichen

Lokale Mocks, die die Autorisierung überspringen oder CORS lockern, bringen Entwicklern die falschen Standards bei. Parität heißt nicht, dass die Anbieter identisch sind. Sie heißt: dieselben Ablehnungsregeln für nicht authentifizierte Aufrufe, zu große Bodies und unbekannte Routen. Falsche Sicherheit ist ein Defekt. Abbildung 3 zeigt diese Parität als gemeinsame Ablehnungen, mit der Abweichung als Anti-Pattern.

Abbildung 3. Lokal und live gelten dieselben Ablehnungsregeln für Authentifizierung, Größe und Routen. Eine Wiki-Seite, die niemand öffnet, ist keine Parität. Eine fehlschlagende Prüfung, die die Beförderung blockiert, ist Parität.

3. Front Door oder Gateway-Muster bewusst wählen

Latenz, WAF, privater Origin und Zertifikatsverwaltung unterscheiden sich. Wähle passend zum Bedrohungsmodell und zum Netzwerkaufbau, den du schon betreibst. Wer eine CDN-ähnliche Edge an eine App schraubt, die von einem freundlichen Intranet ausging, macht TLS zum Theater.

4. Reasoning- und Passthrough-Payloads auf eine Allowlist setzen

Streaming-Chunks, Blobs von Tool-Aufrufen und "Debug"-Felder wandern durch Proxys. Ausdrückliche Allowlists schlagen "alles weiterleiten, was die SPA schickt". Überraschende Felder sind der Weg, auf dem sensible Inhalte den geprüften Pfad verlassen. Abbildung 4 zeigt die Allowlist-Schranke.

Abbildung 4. Lass per Allowlist zu, was durchgeht. Bekannte Felder gehen an das Agent-Backend. Unbekannte und Debug-Felder werden verworfen, damit sie nie zu einem im Browser sichtbaren Leck werden.

5. Autorisierung auf dem Weiterleitungspfad erzwingen

Lehne fehlende oder falsche Scopes ab, bevor das Agent-Backend die Anfrage sieht. Buttons in React zu verstecken ist keine Grenze. Proxy und API teilen eine einzige Geschichte zur Autorisierung.

6. Security-Reviews an der Edge beginnen

System-Prompts zählen. RBAC für den Korpus zählt. Trotzdem beginnt das Review mit der Frage, wer den Proxy erreichen kann, was er aufrufen kann und wohin Antworten gehen können. Prompt-Härtung an einer offenen Edge ist Dekoration.

Fehlerbilder bei Front Door, die man benennen sollte

Falsch konfigurierte Origins, Health Probes, die Shells als gesund melden, während die Backends falsch sind, und Caching-Verhalten, das Streaming-Chats überrascht, kommen häufig vor. Dokumentiere, welches Fehlerverhalten du akzeptierst: bei der Authentifizierung geschlossen scheitern, bei der Gesundheit des Origins sichtbar scheitern, bei Scope-Prüfungen niemals offen scheitern. Der Betrieb braucht ein Runbook, das nicht "SPA neu starten" lautet.

Checkliste für Laufzeitabweichungen

Bevor du eine Shell produktionsreif nennst, vergleiche: Authentifizierung lokal und live erforderlich, maximale Body-Größe, erlaubte Routen, Weiterleitung von Headern, Einstellungen für Websocket oder SSE und Ziele des ausgehenden Verkehrs. Lege den Vergleich in CI oder in eine Release-Checkliste. Eine Wiki-Seite, die niemand öffnet, ist keine Parität. Eine fehlschlagende Prüfung, die die Beförderung blockiert, ist Parität.

Was in das Gespräch über die Allowlist gehört

Liste Anfragepfade, Methoden, Content-Types und Streaming-Modi der Antworten auf. Liste, welche Header zum Backend fließen dürfen. Liste, welche Formen von Tool-Ergebnissen an den Browser zurückgehen dürfen. Wenn ein Feld nur für internes Tracing gedacht ist, sollte es standardmäßig nicht im Browser sichtbar sein. Allowlists wirken pedantisch, bis zum ersten versehentlichen Leck einer internen Kennung.

Häufige Fehler

Vertrauen in die SPA. "Die Nutzer sind angemeldet" ersetzt die Prüfung der Anfrage.

Abweichung zwischen lokal und live. Dev funktioniert, Prod leitet zu viel weiter. Abbildung 3 macht genau diesen Defekt sichtbar.

TLS später. Zertifikate und HTTP-Einstellungen werden zur Hektik.

Maximales Durchreichen. Unbekannte JSON-Felder fahren mit. Abbildung 4 zeigt die Allowlist, die das stoppt.

Reviews, die mit dem Prompt beginnen. Fragen zur Edge kommen erst nach dem Release.

Ein einziger Engineer verantwortet die Edge. Abwesenheiten werden zu Risikofenstern.

So übernehmen oder anpassen

So übernehmen

• Der Pfad vom Browser zum Agent enthält eine ausdrückliche Proxy- beziehungsweise Sicherheitsgrenze mit benanntem Verantwortlichen.
• Lokaler und Live-Proxy teilen die Ablehnungsregeln für Authentifizierung, Routen und Payloads.
• Die Wahl von Front Door oder Gateway (oder einem Gegenstück) ist mit einer Begründung aus dem Bedrohungsmodell dokumentiert.
• Reasoning- und Passthrough-Felder stehen auf einer Allowlist, unbekannte Felder werden verworfen.
• Die Autorisierung wird auf dem Weiterleitungspfad erzwungen, nicht nur durch Filtern in der UI.
• Security-Reviews beginnen beim Proxy und gehen dann zu Prompts und Kontrollen für den Korpus über.

Vor dem Einsatz anpassen

Ein ernsthafter Proxy bringt Konfiguration und eine weitere Komponente mit Verantwortlichem mit. Wer ihn weglässt, hält Demos schnell und macht Angreifern den Einbruch leichter. Strenge Allowlists bremsen spontane Experimente, lockeres Durchreichen bremst die Aufarbeitung von Incidents. Lokal und live anzugleichen kostet Arbeit an Fixtures, die Abweichung kostet Überraschungen in Produktion. Security-Reviews, die an der Edge beginnen, kosten Kalenderzeit und sparen Zeit für Entschuldigungen.

Wichtigste Quellen: die Sicherheitshinweise zu Azure Front Door und Application Gateway auf Microsoft Learn sowie dein ADR zur API-Autorisierung. Verbinde Netzwerkdiagramme mit Payload-Allowlists, damit Reviews etwas Greifbares haben.

Fazit

Benenne die Grenze. Gleiche lokal an live an. Wähle die Edge bewusst. Lass per Allowlist zu, was durchgeht. Erzwinge die Autorisierung auf dem Weg hinein. Beginne Reviews beim Proxy. Der System-Prompt kann warten, bis er dran ist.

Verwandte Notizen

• Azure Custom Vision: Wie trainierst und betreibst du Bildklassifikation in einer Azure Function? (dieselbe Regel im Kleinen: Prediction Keys bleiben hinter der App-API)