AI-Blue-Teaming erklärt: Die drei Ebenen, auf denen eine Kontrollmaßnahme tatsächlich angesiedelt sein kann

Fragt man ein Security-Team, wo seine KI-Guardrails liegen, nennt die Antwort meist ein Richtliniendokument, einen System-Prompt oder eine Herstellerfunktion. Nichts davon ist eine Kontrolle. Eine Kontrolle ist etwas, das im Moment einer Aktion entscheidet, ob die Aktion stattfindet – und für einen KI-Agenten gibt es nur drei Stellen, die entscheiden können: das Modell, das vorgelagerte Gateway und die Umgebung darum herum. Alles, was ein Blue Team ehrlich versprechen kann, stammt aus der zweiten und dritten dieser Stellen. Das ist die Frage der Ebene, und sie steht vor jeder anderen Entscheidung des Blue Teams, einschließlich der Frage, was protokolliert wird und wen man anruft. Deshalb zählt auch die Evidenz aus der Praxis: Das KI-Vorfallarchiv enthält 400 Agenten-Vorfälle von 2024-12 bis 2026-10-17, und die meisten davon sind keine Geschichten über ein Modell, das sich schlecht verhält. Es sind Geschichten über ein Deployment, in dem keine Ebene Nein sagen konnte.

Blue Teaming im KI-Sinne ist die Arbeit, diese Schichten einzubauen, abzustimmen, worauf sie achten, und eine eingeübte Antwort für den Tag parat zu haben, an dem eine von ihnen auslöst. Es ist wenig glamourös, es bringt keinen Score hervor, und es ist die einzige Hälfte des Red-Team/Blue-Team-Paars, die die Risikozahl verändert.

Was ein Blue Team erbt – und was nicht

Traditionelles Blue Teaming beruht auf einer Reihe von Annahmen, die KI-Deployments stillschweigend aushebeln. Es wurde angenommen, dass Logs vollständig sind, weil das Netzwerk jedes Paket sah. Es wurde angenommen, dass Assets aufzählbar sind, weil jemand sie bereitstellen musste. Es wurde angenommen, dass Verhalten deterministisch ist, weil ein Programm bei gleicher Eingabe dasselbe tut. Keine der drei Annahmen übersteht den Kontakt mit einem Agenten.

Was ein Blue Team stattdessen erbt, ist ein System, in dem die folgenschwersten Entscheidungen innerhalb einer Anfrage stattfinden, die die Netzwerkschicht als gewöhnlichen HTTPS-Verkehr zu einem einzigen Hostnamen behandelt. Der Prompt, der abgerufene Kontext, die Tool-Aufrufe, die Completion – all das befindet sich in einem Request-Body, und wenn niemand diesen Body erfasst und parst, ist das Deployment funktional unüberwacht, egal wie gut der Perimeter ist. Die erste Aufgabe des Blue Teams ist daher nicht die Erkennung; sie besteht darin, einen Sensor einzurichten. Ohne Sichtbarkeit auf Anfrage- und Tool-Ebene gibt es nichts, worauf man erkennen könnte, und jede nachgelagerte Kontrolle ist reine Dekoration.

Wer kann die Kontrolle tatsächlich durchsetzen

Sobald es einen Sensor gibt, stellt sich die Frage, wo jedes Steuerelement angesiedelt sein darf. Sinnvollerweise stellt man dies eher nach Zuständigkeit als nach Technologie dar, denn die Zuständigkeit bestimmt, ob ein Steuerelement das nächste Release übersteht.

Die Modellschicht gehört demjenigen, der sie trainiert hat. Sie konfigurieren sie nicht, Sie können nicht hineinsehen, und ihr Verhalten ändert sich, wenn der Anbieter eine neue Version ausliefert – was an jedem beliebigen Dienstag passieren kann. Was Sie tun können, ist, eine Version zu pinnen und eine Versionsänderung als Änderung Ihrer Risikoposition zu behandeln, die eine erneute Prüfung erfordert. Was Sie nicht tun können, ist, hier eine Kontrollmaßnahme für sich zu beanspruchen. „Das Modell lehnt schädliche Anfragen ab“ ist eine Eigenschaft, auf die Sie sich verlassen, kein Mechanismus, den Sie betreiben.

Die Gateway-Schicht ist der Ort, an dem jeder Prompt und jede Completion durch eine Komponente läuft, die Ihnen gehört. Hier sind Budget- und Ratenlimits angesiedelt, hier werden Allow-Lists und Tool-Berechtigungen durchgesetzt, hier ist das Logging von Anfragen und Antworten konstruktionsbedingt vollständig, und hier lässt sich eine Anfrage umschreiben, blockieren oder umleiten, bevor auch nur ein Token abgerechnet wird. Gateway-Kontrollen sind zudem die einzigen, die erhalten bleiben, wenn Sie das Modell wechseln – und das ist wichtiger, als es klingt: Teams, die ihre Kontrollen in Prompts unterbringen, verlieren sie vollständig an dem Tag, an dem sie migrieren.

Die Umgebungsebene ist diejenige, die ganz Ihnen gehört: Anmeldedaten und ihre Geltungsbereiche, Netzwerk-Egress, Dateizugriff, Sandbox-Limits für Wall-Clock-Zeit und Ausgaben. Sie ist auch der Ort, an dem ein kompromittierter Lauf seinen Schaden anrichtet. Ein Agent, der dazu gebracht wurde, böswillig zu handeln, ist genau proportional dazu gefährlich, was die Umgebung dieser Aktion zu erreichen erlaubte — und die Umgebung ist der eine Ort, an dem „least privilege“ eine Konfigurationsänderung statt eines Forschungsproblems ist.

Der Praxistest für jede vorgeschlagene KI-Kontrolle ist eine Frage: Welche dieser drei Schichten setzt sie durch? Wenn die Antwort die Modellschicht ist, ist die Kontrolle eine Hoffnung. Wenn die Antwort „der System-Prompt“ ist, ist sie ein Vorschlag innerhalb der Modellschicht, der schlimmer als eine Hoffnung ist, weil er mit Dokumentation einherkommt, die etwas anderes behauptet.

Erkennen: was ein Agent tatsächlich ausgibt

Die Erkennung für Agenten basiert auf einem anderen Signalsatz als die Erkennung für Menschen. Es gibt keine Login-Anomalie, die korreliert werden kann. Was es stattdessen gibt, ist ein Anfragestrom mit ungewöhnlich reicher Struktur und vier Signalfamilien, für die eine Alarmierung sinnvoll ist.

• Umfang und Form von Tool-Aufrufen. Ein Agent, der plötzlich in einer Aufgabe vierzig Mal ein Dateilese-Tool aufruft oder dessen Tool-Sequenz von drei auf dreißig Schritte wechselt, ist einen Blick wert – nicht weil er bösartig ist, sondern weil sich die Verteilung verschoben hat.

• Inhaltsherkunft an der Grenze. Welcher Text im Prompt vom Benutzer stammt, welcher aus dem Retrieval, welcher aus einem Tool-Ergebnis und welcher aus dem Speicher. Der Großteil der Prompt-Injection-Erkennung läuft darauf hinaus: „Anweisungstext ist in einem Kanal aufgetaucht, der nur Daten transportieren sollte“, und das lässt sich nicht berechnen, sofern das Gateway die Herkunft nicht beim Eingang kennzeichnet.

• Egress- und Scope-Grenzen. Anfragen an Ziele außerhalb der Allow-List, Lesezugriffe auf Pfade außerhalb des Geltungsbereichs, Versuche, Anmeldedaten außerhalb ihres vorgesehenen Dienstes zu verwenden. Das sind hochpräzise Signale, und sie sind günstig, weil die Umgebung bereits weiß, was erlaubt war.

• Ausgaben und Latenz als Indikator. Eine außer Kontrolle geratene Schleife und eine Kompromittierung sehen beide wie eine Kostenkurve aus, deren Steigung sich ändert. Budgetwarnungen sind die am wenigsten glamouröse Erkennung im Stack und gehören zu den schnellsten, die sich selbst amortisieren.

Was in dieser Liste bewusst fehlt, ist ein Klassifikator, der beurteilen soll, ob eine Completion schädlich war. Es ist die Erkennungsidee, zu der Teams zuerst greifen und die am schlechtesten altert: Sie driftet mit dem Modell, sie hat eine Falsch-Positiv-Rate, die Ihre Analysten dazu erzieht, sie zu ignorieren, und sie liefert Ihnen nichts, das Sie in ein Runbook aufnehmen können.

Eindämmen: die drei Stellschrauben, die einen schlechten Lauf stoppen

Die Eindämmung eines Agenten ist einfacher, als es aussieht, denn drei Stellschrauben decken fast alles ab. Budget begrenzt, was ein Lauf kosten darf, was sowohl finanzielle Schäden als auch den Auswirkungsradius einer Schleife eingrenzt. Geltungsbereich begrenzt, worauf ein Lauf zugreifen kann – die für diese Aufgabe aktivierten Tools, die Pfade, die Mandanten. Sandbox begrenzt, wie lange er laufen kann und was er während des Laufs erreichen kann. Alle drei sind Gateway- oder Umgebungseinstellungen, was anders gesagt bedeutet, dass sie durchsetzbar sind.

Das entscheidende Designprinzip ist der Geltungsbereich pro Aufgabe statt pro Agent. Ein Agent mit einem dauerhaften Berechtigungsset ist ein Agent, dessen Berechtigungen sich anhäufen, bis jemand sie prüft; ein Agent, der für die Dauer einer Aufgabe eine aufgabengebundene Credential erhält, hat eine Grenze, die von selbst abläuft. Letzteres ist aufwendiger zu bauen und deutlich kostengünstiger zu verteidigen.

Es ist auch der Ort, an dem ein Gateway seinem Namen gerecht wird. Kontrollen, die vor jedem Modellaufruf greifen – Tool- und MCP-Aufrufe, die vor ihrer Ausführung bewertet werden, Inhaltsrichtlinien und die Maskierung personenbezogener Daten, die vor der Abrechnung der Anfrage angewendet werden – sind dieselben Kontrollen, egal ob das dahinterliegende Modell das ist, das Sie im letzten Quartal verwendet haben, oder das, das letzte Woche veröffentlicht wurde. Diese Kontinuität ist das eigentliche Produkt: kein besserer Filter, sondern ein Ort, an dem der Filter leben kann, der sich nicht mit dem Modell verschiebt.

Wiederherstellen: erneut abspielen, patchen, erneut testen

Die Wiederherstellung nach KI-Vorfällen hat einen Vorteil gegenüber der Wiederherstellung nach Netzwerkvorfällen: Der gesamte Lauf wird in der Regel aufgezeichnet. Prompt, Kontext, Tool-Aufrufe, completions, Zeitmessungen – wenn das Gateway sie protokolliert hat, kann der Vorfall nachgespielt werden, was ein stärkerer Ausgangspunkt ist, als die meisten Forensik-Untersuchungen ihn bekommen.

Replay erfüllt nacheinander drei Zwecke. Es stellt fest, was tatsächlich geschehen ist – und nicht, was das Transkript nahelegt, nachdem mehrere Personen es zusammengefasst haben. Es identifiziert die Kontrolle, die hätte greifen müssen, also den Unterschied zwischen der Behebung eines Symptoms und der Behebung einer Grenze. Und es erzeugt den Regressionsfall: eine aufgezeichnete Eingabe, die jetzt blockiert werden muss und gegen die neue Konfiguration ausgeführt wird, um zu beweisen, dass sie blockiert wird.

Der Patch-Schritt ist der Punkt, an dem Blue Teams am häufigsten danebenliegen. Wenn der Befund ein Modellverhalten war, liegen alle verfügbaren Gegenmaßnahmen außerhalb des Modells — eine Reduzierung des Geltungsbereichs, ein Filter am Gateway, eine aus der Umgebung entfernte Berechtigung. Wenn der Befund ein Systemverhalten war, liegt die Behebung in der Konfiguration, und der Regressionstest kostet wenig. In jedem Fall ist erneutes Testen nicht optional, weil sich sowohl die Behebung als auch die Modellversion ändern und eine Kontrolle, die gegen den Build des letzten Monats verifiziert wurde, eine Aussage über den letzten Monat ist.

Den Tag proben, an dem es feuert

Ein Runbook, das noch nie unter Druck gelesen wurde, ist ein Dokument, keine Fähigkeit. Die Probe, die sich lohnt, ist eng und konkret: Nehmen Sie einen plausiblen Agent-Vorfall, gehen Sie ihn von Anfang bis Ende durch und messen Sie die Zeit für jeden Schritt. Wer bemerkt ihn? Wie lange dauert es, bis ein Mensch auf die richtige Logzeile schaut? Wer kann den Lauf stoppen – eine namentlich benannte Person oder ein Gremium? Wer kann die Zugangsdaten widerrufen, und wie lange dauert es, bis der Widerruf wirksam wird? Wer entscheidet, ob jemand außerhalb des Unternehmens benachrichtigt wird?

Zwei dieser Fragen erwischen Teams zuverlässig auf dem falschen Fuß. „Wer kann den Lauf stoppen“ scheitert, wenn das Stoppen jemanden erfordert, der schläft, also muss die Antwort ein Mechanismus statt einer Person sein – eine Budgetobergrenze oder ein Kill Switch, den ein Bereitschaftsingenieur allein auslösen kann. „Wie lange dauert es, bis ein Widerruf wirksam wird“ scheitert, weil Zugangsdaten häufig in Komponenten zwischengespeichert werden, die nicht im Diagramm enthalten waren.

Das Archiv zu lesen ist die günstigste verfügbare Form der Übung, denn es ermöglicht dir, die Incident-Struktur anderer zu übernehmen, statt deine eigene zu erfinden. Nimm ein paar Einträge, die deinem Deployment ähneln, und stelle bei jedem die drei oben genannten Fragen. Die Einträge, bei denen du sie nicht beantworten kannst, sind die Lücken in deinem Runbook – und du hast sie vor dem Incident gefunden, nicht danach.

Die Asymmetrie, die es wert ist, klar benannt zu werden

Red-Teaming und Blue-Teaming sind keine symmetrischen Aktivitäten und sollten nicht so budgetiert werden, als wären sie es. Ein Red-Team-Durchlauf ist an einen Zeitplan gebunden und liefert eine Reihe von Erkenntnissen, die mit der Veränderung des Ziels an Aussagekraft verlieren. Die Kontrollen eines Blue Teams bleiben bestehen, verstärken sich und sind das Einzige, was tatsächlich zwischen einer schlechten Eingabe und einem schlechten Ergebnis steht. Ein Engagement kann eine Grenze aufdecken; nur das andere kann sie halten.

Was den ehrlichen Standard für ein Blue Team unglamourös und überprüfbar macht. Für jede Kontrolle, die du beanspruchst, solltest du die Ebene nennen können, die sie durchsetzt, die Logzeile, die beweist, dass sie ausgelöst hat, die Warnung, die dir sagt, wenn sie es nicht getan hat, und die Person, die den Lauf abschalten kann. Vier Sätze. Wenn eines davon fehlt, ist die Kontrolle ein Richtliniendokument, und Richtliniendokumente lesen keine Request-Bodies.