Vertrauen ist gut, Architektur ist besser: Warum AI-Agenten eine Sicherheitsstrategie brauchen 

Während Unternehmen sich auf die Entwicklung smarter Agenten konzentrieren, übersehen viele eine unbequeme Wahrheit, die im Fundament dieser Technologie liegt. Die aktuellen Large Language Models (LLMs), das Gehirn hinter jedem AI-Agenten, haben einen fundamentalen Designfehler: Sie können nicht zuverlässig zwischen Anweisungen und Daten unterscheiden, denn es gibt für alles nur einen einzigen Kanal. Für ein LLM ist am Ende alles nur ein einziger Strom von Wörtern (Tokens). Die Modellhersteller versuchen dann auf dieses fehlerhafte Fundament eine Struktur aufzusetzen, die Sicherheit gewährleisten soll: 

• Der Token-Strom wird mittels spezieller, reservierter Tokens in Messages verschiedener Rollen strukturiert: Die Anweisungen, die die Entwickler*innen dem Agenten mitgeben (System-Prompt), die Anweisungen, die die Enduser geben können (User-Prompt), sowie Tool-Aufrufe und Ergebnisse. 
• Die Modelle werden dann darauf trainiert, mehr Gewicht auf den System-Prompt zu legen, als auf den User-Prompt, sowie Ergebnisse von Tools eher wie Daten zu behandeln. 

Das ist kein Security by Design, sondern basiert auf dem Prinzip Hoffnung und kann die fundamentalen Probleme nur kaschieren. Der implizit eintrainierte Vorrang von Anweisungen kann vom Modell ignoriert werden – und Fälle, die von den System Instructions gar nicht explizit adressiert werden, können auch keinen Vorrang vor Anweisungen des Users haben. Innerhalb der System- und User-Prompts gibt es zudem weiterhin keinerlei Unterscheidung zwischen Daten und Anweisungen. Es ist genauso üblich (je nach Natur der Anwendung), dass der User Prompt ausschließlich Anweisungen enthält (z. B. in einem klassischen Chatbot), oder dass der User Prompt ausschließlich Daten enthält (z. B. eine Anwendung für KI-basierte Zusammenfassungen). Es obliegt der (zweifelhaften) Intelligenz und Intuition des Modells, korrekt zwischen Daten und Anweisungen zu unterscheiden. 

Das ist kein kleines Problem. Es bedeutet, dass (General-Purpose) Agenten, die auf der heutigen LLM-Architektur aufbauen, keine verlässlichen Sicherheitsgarantien geben können. Wenn wir also ernsthaft Agenten in unseren Unternehmen einsetzen wollen, müssen wir aufhören, auf das Beste zu hoffen, und anfangen, für das Schlimmste zu planen. Wir müssen Sicherheit durch durchdachtes Systemdesign um die fundamentalen Einschränkungen herum bauen, niemals ausschließlich darauf. 

Der Wolf im Schafspelz: Was ist eigentlich Prompt Injection? 

Stell dir vor, du gibst einem fähigen, aber auch sehr naiven Assistenten eine Aufgabe. Er will dir unbedingt helfen und folgt jeder Anweisung. Genau das ist ein LLM. Prompt Injection nutzt diese "Naivität" aus. Ein Angreifer schmuggelt bösartige Anweisungen in den Text (den einzelnen Token-Strom), den der Agent verarbeitet. 

• Direkte Prompt Injection: der Angriff durch die Vordertür 
  Das ist die offensichtlichste Variante. Ein User (oder Angreifer) interagiert direkt mit dem Agenten – über einen Chat, eine E-Mail oder ein anderes Eingabefeld – und bringt ihn dazu, Dinge zu tun, die er nicht tun sollte. Die Ergebnisse reichen von komisch bis katastrophal. Die Schlagzeilen dazu häufen sich: Ein Chatbot des Lieferdienstes DPD wurde dazu überredet, das eigene Unternehmen zu beschimpfen. Ein anderer von Chevrolet hat „rechtlich bindend“ ein Auto für einen Dollar angeboten. Diese „Screenshot Attacks“ sind mehr als nur peinlich; sie können echten finanziellen Schaden und massiven Reputationsverlust verursachen. 
• Indirekte Prompt Injection: das Trojanische Pferd 
  Diese Methode ist weitaus heimtückischer. Hier platziert ein Angreifer die bösartigen Instruktionen in externen Daten, von denen er weiß, dass der Agent sie später lesen wird. Das kann eine Website sein, die der Agent zusammenfassen soll, ein PDF-Dokument in einer Wissensdatenbank oder sogar eine E-Mail in einem Postfach, das der Agent überwacht. Der Agent nimmt diese Daten auf, interpretiert die versteckten Befehle als legitime Anweisungen und führt sie aus – ohne dass der eigentliche User etwas davon mitbekommt. 

Der wahre Albtraum: Wenn dein Agent zum Datendieb wird

Lustige Chatbot-Screenshots sind eine Sache. Der unkontrollierte Abfluss von Unternehmensdaten eine ganz andere. Der Softwareentwickler und AI-Experte Simon Willison hat hierfür den Begriff der „tödlichen Drei“ (The Lethal Trifecta) geprägt. Ein Agent wird zur tickenden Zeitbombe, wenn er drei Fähigkeiten kombiniert: 

1. Zugriff auf private Daten: Zugriff auf deine E-Mails, interne Dokumente, Kundendatenbanken etc. 
2. Kontakt mit nicht vertrauenswürdigen Inhalten: Die Fähigkeit, Webseiten zu lesen, E-Mails zu verarbeiten oder Dokumente von externen Quellen zu öffnen. 
3. Möglichkeit zur externen Kommunikation: Die Fähigkeit, Daten nach außen zu senden, sei es durch das Senden einer E-Mail, einen API-Aufruf oder auch nur das Erzeugen eines Links. 

Hat ein Agent alle drei Fähigkeiten, kann ein Angreifer ihn kinderleicht dazu bringen, deine privaten Daten zu suchen und sie an ihn zu senden. Genau solche Szenarien wurden bereits in Systemen wie Microsoft 365 Copilot nachgewiesen, bei denen versteckte Befehle in Dokumenten sensible Daten abfließen ließen.

MCP: der unterschätzte Angriffsvektor

Als wäre das nicht schon komplex genug, kommt mit Konzepten wie dem "Model Context Protocol" (MCP) eine weitere Ebene hinzu. Die Idee dahinter ist eigentlich genial: Standards zu schaffen, damit Agenten nahtlos auf verschiedenste Werkzeuge (Tools) und Datenquellen zugreifen können, egal von wem sie stammen. Doch diese Vereinfachung hat einen sicherheitstechnischen Preis. 

MCP macht das Risiko von Prompt Injection noch unübersichtlicher und schwerer zu kontrollieren. Es verleitet dazu, schnell viele Tools von verschiedenen Anbietern zu kombinieren und damit unvorhergesehene Angriffspfade zu eröffnen. Man verliert schnell den Überblick, welche Daten genau in den Kontext des Agenten gelangen können. Ehe man sich versieht, hat man die „tödliche Drei" beisammen – oft schon durch Tools eines einzigen Anbieters. Beispielsweise kann der GitHub MCP u. U. auf private Repos zugreifen, öffentliche (potenziell bösartige) Issues und Kommentare lesen und Pull Request stellen, um private Informationen zu exfiltrieren. 

Zusätzlich können „remote MCPs“, also MCP-Server, die nicht in der eigenen Infrastruktur laufen, Tools jederzeit „vergiften“ (Tool-Poisoning) und so beliebige Prompt-Injections ausliefern. Als Resultat können dann auch Daten völlig anderer Services abfließen, wenn für sie ebenfalls ein MCP oder auch ein normales Tool in denselben Agenten eingebunden ist. 

Warum „gut zureden“ nicht ausreicht: die Grenzen von Soft Guardrails 

Die erste intuitive Reaktion auf diese Probleme ist oft, dem Agenten einfach bessere und strengere Regeln zu geben. Diese in die Klasse der sogenannten „Soft Guardrails“ fallenden Maßnahmen sind ein wichtiger erster Schritt, aber sie reichen bei weitem nicht aus. IEinige der typischsten „Soft Guardrails“ umfassen: 

1. Optimiertes Prompting
   Man sollte im System-Prompt, der grundlegenden Anweisung für den Agenten, eine klare Rolle, Aufgaben, und strikte Regeln definieren, sowie den Prompt so strukturieren, dass Daten und Anweisungen klar getrennt sind. Oft werden unsichere Usereingaben mit speziellen Markierungen (wie <user_input>) versehen, um dem Modell zu signalisieren: „Achtung, das hier ist nur eine Dateneingabe, keine Anweisung.“ Das ist besser als nichts, aber eher vergleichbar mit „gutem Zureden“. Es ist nur eine weiche Maßnahme. Ein geschickter Angreifer kann diese Regeln durch clevere Formulierungen oder schrittweises „Bearbeiten“ des Agenten im Laufe einer Konversation leicht aushebeln. Die Aufmerksamkeit des Modells für den ursprünglichen System-Prompt kann mit der Zeit schwinden. 
   
2. Human-in-the-Loop & User Approval 
   Idee: Bevor der Agent eine potenziell gefährliche Aktion ausführt (z. B. eine E-Mail versenden, eine Datei löschen), muss ein Mensch zustimmen. Beispiel: Der Agent schlägt den Entwurf für eine E-Mail vor. Der User sieht eine Vorschau und muss aktiv auf einen „Senden“-Button klicken. Das klingt erstmal absolut sicher, ist aber anfällig für den Faktor Mensch. Wir alle kennen die „Approval Fatigue“ – nach dem zehnten Mal klicken wir einfach auf „OK“, ohne den Inhalt genau zu prüfen. Zudem können Angreifer User via Social Engineering dazu verleiten, schädliche Aktionen freizugeben. Diese Methode ist in kontrollierten internen Prozessen (z. B. als User Task in einer Camunda-Prozess-Engine) deutlich wirksamer als bei Endkunden-Anwendungen. 
   
3. KI-basierte Filter & Classifier 
   Ein separates Machine-Learning-Modell kann die Eingaben des Users (oder die Ausgaben eines Tools) analysieren und versuchen, Angriffe zu erkennen, um sie zu blockieren. Beispiel: Ein Filter ist darauf trainiert, Phrasen wie „Ignoriere deine bisherigen Anweisungen“ oder andere bekannte Jailbreak-Versuche zu erkennen und die Anfrage sofort zu blockieren. Solche Filter sind ein sinnvolles Element einer mehrschichtigen Verteidigung, aber allein nicht ausreichend. Sie erkennen nur, was verdächtig aussieht, nicht unbedingt, was tatsächlich gefährlich ist. Viele Angriffe sind ohne den vollen Kontext gar nicht als solche zu erkennen. Es ist ein ständiger Wettlauf: Sobald ein Filter eine Angriffsmethode lernt, finden Angreifer eine neue. Zudem haben Classifier nicht nur false-negatives (entgangene Angriffe), sondern immer auch false-positives, d. h. sie blockieren gelegentlich eigentlich harmlose Eingaben und können User damit frustrieren. 
   
4. LLM-as-a-Judge 
   Hier nutzt man ein zweites, separates LLM als Schiedsrichter. Dieses „Judge-LLM“ bewertet die Anfrage des Users (und ggf. die geplante Aktion des Agent-LLMs) und gibt eine Freigabe – oder eben nicht. Beispiel: Das Judge-LLM erhält die Anfrage: „Der User will eine Zusammenfassung seiner letzten fünf E-Mails an eine externe Adresse senden. Ist diese Aktion gemäß unserer Sicherheitsrichtlinie XY erlaubt?“ Dieser Ansatz ist flexibler als statische Filter, da der Judge den Kontext besser verstehen und Richtlinien anwenden kann. Aber auch hier gilt: Der Judge ist selbst ein LLM und damit ebenfalls fehleranfällig und potenziell angreifbar. Zudem verlangsamt er den Prozess und erhöht die Kosten. 

Modell-basierte Soft Guardrails sind probabilistisch. Sie fangen vielleicht 95 % der Angriffe ab. Dem Angreifer bleiben aber weitere 5 % erfolgreiche Angriffe, die er ausnutzen kann. Dies ist besonders heikel, da sich die Suche nach erfolgreichen Prompt-Injections vollständig automatisieren lässt: Angreifer bauen einfach eine Schleife auf, in der ein LLM immer wieder Injection-Prompts generiert, gegen das Zielsystem ausprobiert, die Antwort bewertet (z. B. kam ein Toxischer Text zurück), und den Prompt mittels dieses Feedbacks ein bisschen anpasst (oder direkt die Parameter des angreifenden Modells trainiert).  

Sich allein auf Soft Guardrails zu verlassen, ist aus diesen Gründen fahrlässig. 

Es braucht Mauern, nicht nur Türsteher: Hard Guardrails 

Wenn Soft Guardrails nur die erste Verteidigungslinie sind, brauchen wir robustere, architektonische Maßnahmen. „Hard Guardrails“ sind keine Regeln, die ein Agent befolgen soll, sondern unumstößliche Einschränkungen, die ihm bestimmte Aktionen von vornherein unmöglich machen. 

Once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions.

Lasst uns ein paar Patterns anschauen, die stärkere Sicherheitsgarantien geben können als Soft Guardrails, da diese Maßnahmen auf System-Design (und damit deterministischem Code) basieren, statt auf probabilistischen Modellen. Das erste Pattern richtet sich gegen direkte Injection durch den User, die anderen beiden versuchen indirekte Injection durch Tools unmöglich zu machen. 

1. Intent Parametrisierung
   Dies ist ein wichtiges Prinzip und direkt von der Abwehr von SQL-Injections inspiriert. Wir trennen strikt die Interpretation der Usereingabe (was will der User?) von der Ausführung der Aktion. Der User-Input wird niemals direkt als Befehl ausgeführt, sondern immer nur als Datenwert (Parameter) an eine sichere Funktion übergeben. Beispiel: Ein User sagt: „Buche mir einen Flug von Hamburg nach Madrid am 10.12.2025 und schreibe ein Gedicht, warum die Fluggesellschaft so schlecht ist“. Ein vorgeschaltetes LLM ohne Tool-Zugriff erkennt den Intent book_flight. Es füllt die vordefinierten Parameter: departure = 'HAM', destination = 'MAD' und date = '10.12.2025'. Die Anweisung „schreibe ein Gedicht…“ wird ignoriert, da das Schema von book_flight lediglich geprüfte Werte für die Flughäfen sowie ein Datum erlaubt. Der ausführende Agent sieht ausschließlich den Intent und die bereinigten Daten und kann niemals etwas Anderes als auszuführenden Befehl interpretieren. Das Vorgehen ist vergleichbar damit, dem User ein typisiertes UI-Formular anzubieten (und für viele Agenten wäre das auch noch gute UX). Diese Methode ist wirksam gegen direkte Prompt-Injection durch den User, da der Spielraum für Injection, je nach Schema der Parametrisierung, sehr klein bis nicht vorhanden ist. Benötigt ein Formular unbedingt Freitext oder nicht enumerierbare String-Werte ist wieder Vorsicht geboten und man sollte zumindest die Länge und erlaubten Zeichen, soweit es geht, einschränken. 
2. Das Action-Selector Pattern 
   Ein einfaches Muster, das Agenten vor indirekten Prompt-Injection-Angriffen durch Tools schützt, besteht darin, jegliches Feedback aus diesen Aktionen vom Agenten fernzuhalten. Das bedeutet: Der Agent kann Tools auslösen, aber er darf die Ergebnisse dieser Tools nicht einsehen (da sie nicht vertrauenswürdige Tokens beinhalten). Er kann also beispielsweise den Befehl geben, eine Webseite zu öffnen oder dem User ein Ergebnis anzuzeigen – aber er selbst darf den Inhalt der Webseite oder die Rückmeldung des Tools nicht lesen. Dieses Pattern schützt sehr gut (wenn der User nicht aktiv Ergebnisse wieder an den Agenten gibt) vor indirekter Prompt-Injection, aber hat je nach Anwendung starke Auswirkungen auf die UX und schränkt den Agenten stark in seinen Möglichkeiten ein. 
3. Das Quarantäne-Prinzip 
   Die Idee: Man verwendet zwei LLMs mit unterschiedlichen Rechten. Ein „privilegiertes LLM“ interagiert mit dem User und darf auf sichere Tools (wie einen Taschenrechner) zugreifen, aber es darf die Ergebnisse von potenziell unsicheren Tools (wie dem Browsen einer Webseite) nicht selbst lesen. Ein zweites, isoliertes „Quarantäne-LLM“ liest den unsicheren Inhalt, extrahiert die benötigten Informationen in Variablen und gibt nur die Variablennamen (nicht die Inhalte!) an das privilegierte LLM weiter. 
   Beispiel: Der Agent soll den Preis für ein Produkt von einer Webseite abrufen. Das privilegierte LLM ruft das browse-Tool auf. Die Webseite enthält neben dem Preis auch einen Prompt-Injection-Angriff. Das Quarantäne-LLM liest den gesamten HTML-Code, ignoriert den Angriff, findet den Preis und gibt nur $price = 49.99 zurück, das privilegierte LLM bekommt lediglich $price übergeben. Im schlimmsten Fall wird das Quarantäne-LLM einen anderen Text in die Variable schreiben als den Preis, oder weitere Variablen mit bösartigem Inhalt füllen. Das privilegierte LLM wird dennoch nie bösartigen Inhalten ausgesetzt, da es nur die (eingeschränkten) Variablennamen sehen kann. Im Gegensatz zum Action-Selector-Pattern ist der eigentliche Agent aber weniger eingeschränkt, da er mit den Variablen weiterarbeiten kann, auch ohne sie zu lesen. So könnte er zum Beispiel den Preis als Parameter an ein weiteres Tool übergeben und so mehrere Aufrufe miteinander verketten. 
   Dies ist ein sehr starkes Konzept, um indirekte Prompt Injection zu verhindern. Die Schwachstelle ist, dass die extrahierten Daten selbst manipuliert sein könnten und Einfluss auf spätere Tool-Ausführungen haben (z. B. eine falsche E-Mail-Adresse als Empfänger; das privilegierte LLM hat keine Möglichkeit dies zu prüfen). Man kann als Verbesserung daher den Datenfluss nachverfolgen und sensible Aktionen, die auf potenziell „kontaminierten“ Daten basieren, eventuell einer zusätzlichen menschlichen Freigabe unterziehen. 

Defense-in-Depth: Baue eine Festung, kein Märchenschloss

Sich auf Soft Guardrails als einzige Verteidigungslinie zu verlassen, ist in etwa damit vergleichbar eine einzelne Wache vor das hübsch geschmückte Schloss zu stellen und ein Schild an das Tor zu nageln: „Zutritt verboten“. Damit lässt sich verhindern, dass der durchschnittliche Bürger direkt in die Schatzkammer marschiert. Eine sichere Festung braucht dagegen robuste Mauern, tiefe Gräben und ausgeklügelte Verteidigungsanlagen, damit sie auch für ganze Armeen unbezwingbar wird. 

Sicherheit ist kein einzelnes Produkt, sondern ein Prozess und eine Strategie aus mehreren Schichten. Ein Angreifer mag eine Schicht überwinden, aber er sollte an der nächsten scheitern. Eine robuste Verteidigungsstrategie kombiniert die besprochenen Soft und Hard Guardrails: 

• Schicht 1 (Soft): Ein starker System-Prompt und KI-basierte Input-Filter fangen die einfachsten Angriffe ab. 
• Schicht 2 (Hard): Eine strikte Trennung von Interpretation und Ausführung (Intent Parametrisierung) bildet das Fundament und verhindert die direkte Ausführung von Befehl
• Schicht 3 (Hard): Der Agent operiert in einer Sandbox. Er darf nur auf die absolut notwendigen Daten zugreifen. Das Quarantäne-Prinzip isoliert ihn von unsicheren Inhalten. 
• Schicht 4 (Prozess): Bei besonders kritischen Aktionen wird eine explizite Bestätigung durch einen Menschen über einen sicheren Kanal (z. B. einen User Task in einer Prozess-Engine) eingefordert. 

Ein gesundes Maß an Misstrauen 

AI Agents haben das Potenzial, unsere Arbeitsweise fundamental zu verändern. Aber wir müssen sie mit offenen Augen und einem gesunden Maß an Misstrauen implementieren. Die Hoffnung, dass ein LLM sich schon selbst schützen wird, ist keine Strategie. 

Die entscheidende Frage ist nicht, ob wir Agents bauen, sondern welche wir heute verantwortungsvoll bauen können – und wie. Indem wir uns auf eine durchdachte Sicherheitsarchitektur, eine Kombination aus weichen und harten Leitplanken und eine Defense-in-Depth-Strategie konzentrieren, können wir die enormen Chancen von AI Agents nutzen, ohne unsere Unternehmen einem inakzeptablen Risiko auszusetzen. 

Die Verantwortung hierfür liegt bei den Entwicklerinnen und Entwicklern von AI-Systemen - die Hersteller von Modellen, Plattformen und Tools (z. B. Camunda Agentic AI, OpenAI Agent Builder, n8n) bieten out-of-the-box in der Regel höchstens eine Auswahl von Soft Guildrails. Wir müssen diese Möglichkeiten aktiv nutzen und um eigene, systematische, an die jeweilige Anwendung angepasste Maßnahmen erweitern. Wenn wir das tun, sind sichere Agentic AI Use Cases auch heute schon umsetzbar.