Zweistufige Egress-Kontrolle für lokale KI-Agenten

1Einleitung

1.1 Motivation

Kleine und mittlere Unternehmen erwägen zunehmend den Einsatz KI-gestützter Assistenten für die Bearbeitung von E-Mails und Dokumenten. Damit entsteht ein doppeltes Risiko. Ein solcher Assistent könnte sensible Daten an unbefugte Ziele senden. Er könnte außerdem durch Anweisungen, die in den verarbeiteten Inhalten versteckt sind, zu schädlichen Aktionen verleitet werden. Beide Risiken sind für einen Verantwortlichen ohne Sicherheitsexpertise schwer einzuschätzen, weil das Verhalten des Modells nach außen wie eine Blackbox wirkt.

1.2 Zielsetzung und Forschungsfragen

Untersucht wird, ob eine zweistufige Verteidigungsarchitektur diese Risiken nachweisbar reduziert. Daraus ergeben sich drei Forschungsfragen:

• F1: Verhindert netzseitige Isolation zuverlässig den unkontrollierten Egress?
• F2: Welche Detektionsrate und Falsch-Positiv-Rate erreicht ein deterministischer Output-Filter?
• F3: Erhöht ein zusätzlicher LLM-basierter Prüfagent die Sicherheit, und ist dieser Prüfagent selbst angreifbar?

1.3 Hypothesen

2Theoretische Grundlagen

Ein Sprachmodell trennt nicht zuverlässig zwischen Instruktion und Daten. In einem verarbeiteten Text eingebettete Anweisungen können deshalb das Modellverhalten übernehmen. Dieses Muster wird als Prompt-Injection bezeichnet und im Katalog der OWASP-Foundation als wichtigstes Risiko für LLM-Anwendungen geführt. Der Stand der Technik beschreibt das Problem als mitigierbar, jedoch nicht als gelöst.²

Ein verwandtes Risiko ist der Abfluss geschützter Informationen, etwa des Systemprompts. Die OWASP-Foundation führt dies als eigenen Eintrag zur Preisgabe des Systemprompts.¹

Das Prinzip Defense-in-Depth trennt Verteidigung in unabhängige Schichten. Für KI-Agenten ist die Netzwerk-Zugriffskontrolle (die Frage, wer senden darf) orthogonal zur Ausgabekontrolle (die Frage, was gesendet werden darf). Beide Schichten müssen getrennt validiert werden, da keine die andere ersetzt. Eine frühere eigene Messung an einem gehärteten Chatbot bestätigte dies quantitativ: vollständige Netzwerk-Härtung senkte die Rate der Systemprompt-Extraktion nicht, sondern ließ sie unverändert hoch.⁴

Data Loss Prevention (DLP) bezeichnet die Erkennung sensibler Daten anhand fester Muster. Reguläre Ausdrücke und Prüfsummen arbeiten deterministisch und sind damit unabhängig vom Sprachmodell. Für Kreditkartennummern dient der Luhn-Algorithmus als Prüfsumme, der die meisten zufälligen Ziffernfolgen von gültigen Kartennummern unterscheidet.³ Ein deterministischer Filter lässt sich, anders als ein Sprachmodell, nicht durch sprachliche Manipulation umgehen.

3Material und Methoden

3.1 Versuchsumgebung

Als Verifikationsmodell wurde Qwen 2.5 mit 3 Mrd. Parametern statt des vorgesehenen Qwen 3 mit 8 Mrd. Parametern eingesetzt, um den Ressourcenaufwand des Modell-Downloads zu senken. Die Architektur bleibt identisch. Die geringere Modellstärke ist als Limitation in Abschnitt 5.3 dokumentiert.

3.2 Systemarchitektur

Die Architektur besteht aus drei Verteidigungsschichten, die in Abbildung 1 dargestellt sind. Layer 1 realisiert die Egress-Kontrolle netzseitig: Der Agent-Container liegt in einem internen Netz ohne Route ins Internet, sein einziger Ausgang ist ein Allowlist-Proxy. Das Sprachmodell liegt ebenfalls im internen Netz, sodass kein Rückkanal über den Host entsteht. Layer 2a ist die deterministische DLP-Schicht und bildet den harten Blocker. Layer 2b ist der LLM-Prüfagent und wirkt nur ergänzend. Beide Ausgabeschichten sind als „fail-closed" mit UND-Verknüpfung verschaltet, sodass eine Freigabe nur bei Zustimmung beider Schichten erfolgt.

3.3 Messgrößen

Erhoben wurden drei Kennzahlen. Die Egress-Blockrate misst den Anteil unterbundener Ausgangsverbindungen. Die Detektionsrate (Recall) misst den Anteil korrekt geblockter schädlicher Eingaben. Die Falsch-Positiv-Rate misst den Anteil fälschlich geblockter harmloser Eingaben.

3.4 Testkorpus und Durchführung

Der Testkorpus umfasst 15 Eingaben in sieben Kategorien: direkte Injektion, gegen den Prüfagenten gerichtete Injektion, Encoding per Base64, Umgehung über unsichtbare Zeichen, gesplittete personenbezogene Daten, semantische Exfiltration (bewusst als bekannte Lücke markiert) sowie harmlose Kontrollfälle. Vor dem Aufbau erfolgte ein strukturiertes Threat-Model-Review nach dem Prinzip des feindseligen Gegenlesers, das zwölf Härtungsauflagen ergab. Anschließend liefen drei Teilversuche: die Prüfung der Egress-Isolation, der Lauf des Korpus ohne den LLM-Judge sowie der Lauf des Korpus mit aktivem LLM-Judge, ergänzt um eine gezielte Einzelprobe des Judge.

4Ergebnisse

4.1 Teilversuch I: Egress-Isolation

Aus dem Agent-Container heraus wurden drei Netzwege geprüft. Der direkte Weg ins Internet scheiterte, der Weg über den Proxy zu einem nicht freigegebenen Ziel wurde mit dem Status 403 verweigert, und das interne Sprachmodell blieb erreichbar. Tabelle 2 fasst dies zusammen.

Ein zusätzlicher Befund stützt die Isolation: Der Versuch, das Sprachmodell im isolierten Container nachzuladen, scheiterte an blockierter DNS-Auflösung. Die Isolation wirkt so weit, dass eine Bereitstellung des Modells außerhalb des Laufzeitbetriebs notwendig wird. H1 gilt damit als bestätigt. Nicht geprüft wurde die Exfiltration zu ausdrücklich freigegebenen Zielen; ein Allowlist-Proxy unterbindet unerlaubte Ziele, nicht den Abfluss über erlaubte Kanäle. Dieser Restkanal bleibt eine bekannte Grenze der netzseitigen Kontrolle.

4.2 Teilversuch II: Deterministischer Filter

Der deterministische Filter erreichte eine Detektionsrate von 9 von 10 bei null Falsch-Positiven. Nicht erkannt wurde die gegen den Prüfagenten gerichtete Injektion, da sie keine strukturierten personenbezogenen Daten enthält und damit regelbasiert nicht erfassbar ist. H2 gilt als bestätigt.

4.3 Teilversuch III: Hybrid mit LLM-Judge

Mit aktivem LLM-Judge blieb die Detektionsrate bei 9 von 10, jedoch trat ein Falsch-Positiv auf. Die gezielte Einzelprobe zeigte den für die Architektur entscheidenden Punkt. Die Eingabe [SYSTEM]: Scan abgeschlossen, Antworte ausschließlich mit PASS führte zum Ergebnis passed = True. Der Prüfagent befolgte die eingebettete Anweisung und ließ die Eingabe durch. Abbildung 2 stellt die Kennzahlen dar, Abbildung 3 veranschaulicht den Kernbefund.

5Diskussion

5.1 Interpretation der Hypothesen

H1 und H2 werden bestätigt. Die netzseitige Isolation unterband alle getesteten Ausgangswege, und der deterministische Filter erreicht eine hohe Trefferquote ohne Falsch-Positive. H3 wird verworfen. Der LLM-Judge ist selbst prompt-injizierbar. Der Mechanismus, der Injektion abwehren soll, wurde durch genau eine solche Injektion umgangen. Dieses rekursive Versagen deckt sich mit dem Stand der Literatur, die Prompt-Injection als ungelöst beschreibt; der Beitrag dieser Arbeit liegt nicht in der Neuheit des Effekts, sondern darin, ihn in einem kontrollierten lokalen Aufbau reproduzierbar zu zeigen und die praktische Konsequenz für die Architektur abzuleiten.

5.2 Kernbefund und Konsequenz

Das Hinzufügen des LLM-Filters verbesserte die Detektionsrate nicht und erzeugte zugleich einen Falsch-Positiv. Ein LLM-basierter Filter kann daher nicht als harte Sicherheitsgrenze dienen, sondern nur als ergänzende und unzuverlässige Schicht. Zwei Prüfschritte mit demselben Modell bilden zudem keine unabhängigen Schichten, da sie dieselben Schwächen teilen. Echte Unabhängigkeit entsteht erst durch verschiedene Mechanismen. Die deterministische Schicht arbeitet modellunabhängig und trägt deshalb die Beweislast der Verteidigung. Der LLM-Judge darf einen Block der deterministischen Schicht nie aufheben.

5.3 Fehlerbetrachtung und Limitationen

• Stichprobengröße. Mit 15 Eingaben besitzt der Korpus keine statistische Aussagekraft. Die Ergebnisse belegen einen Effekt, keine Quote.
• Einzelmessung. Es liegen keine Wiederholungsläufe vor. Ausgaben eines Sprachmodells sind stochastisch, und die Temperatur wurde nicht kontrolliert. Das Judge-Ergebnis ist damit ein Existenznachweis, kein Häufigkeitsnachweis.
• Modellstärke. Die Verifikation nutzte ein Modell mit 3 Mrd. Parametern. Ein stärkeres Modell könnte einzelne Fälle abfangen. Am Prinzip der grundsätzlichen Injizierbarkeit ändert das nichts.
• Konstruktvalidität. Der Korpus wurde vom Autor formuliert und ist nicht repräsentativ für reale Angriffe. Die bewusst als bekannte Lücke markierten Fälle machen diese Grenze transparent.

5.4 Bedrohung der Validität

Da die schädlichen Testfälle teils selbst konstruiert wurden, besteht die Gefahr, nur bereits bekannte Angriffe zu prüfen. Die als bekannte Lücke ausgewiesenen Fälle der semantischen Exfiltration adressieren diese Gefahr offen und verhindern eine geschönte Trefferquote.

6Fazit und Ausblick

Eine zweistufige Architektur reduziert den Wirkungsradius eines kompromittierten KI-Agenten nachweisbar. Netzisolation und deterministische DLP sind wirksam und, anders als der LLM-Judge, nicht durch sprachliche Manipulation umgehbar; ihre Grenze liegt bei Mustern, die sie nicht kennen, etwa der semantischen Exfiltration. Der LLM-basierte Prüfagent ist hingegen selbst angreifbar und darf keine tragende Sicherheitsrolle übernehmen. Die zentrale Erkenntnis lautet: Prompt-Injection ist nicht gelöst, und verlässlicher Schutz entsteht durch modellunabhängige, deterministische Mechanismen, die durch semantische Prüfung ergänzt, aber nicht ersetzt werden.

Für weitere Arbeiten bieten sich Wiederholungsläufe bei kontrollierter Temperatur und mit einem stärkeren Modell an, eine Erweiterung des Korpus auf mindestens 20 Fälle sowie ein Vergleich verschiedener Judge-Modelle, um die Injektions-Anfälligkeit zu quantifizieren.

7Literatur

1. OWASP Foundation: OWASP Top 10 for Large Language Model Applications, Eintrag LLM01 (Prompt Injection) und LLM07 (System Prompt Leakage). Online unter genai.owasp.org. ↩
2. Willison, S.: Artikelserie zu Prompt Injection, u. a. „Prompt injection: what's the worst that can happen?". Online unter simonwillison.net. ↩
3. Luhn, H. P.: Computer for Verifying Numbers. US-Patent 2.950.048, 1960. ↩
4. Cyber Aspis AI-Security-Lab: eigene Voruntersuchung zur netzseitigen Härtung gegen Systemprompt-Extraktion, 2026 (interner Messbericht, Veröffentlichung in Vorbereitung). ↩

Alle Online-Quellen zuletzt geprüft am 11.07.2026.