Die meisten Ratschläge zur Absicherung eines Agenten bestehen darin, Anweisungen in einen System-Prompt einzubetten. Dieser Ansatz behandelt Sicherheit als eine Reihe von Verhaltensrichtlinien - im Grunde bittet er den Agenten, bestimmte Dinge nicht zu tun. Das ist grundlegend fehlerhaft, denn eine Anweisung ist eine Bitte, keine technische Grenze. Eine Bitte lässt sich überstimmen, ignorieren oder durch raffinierte Eingaben umgehen.
Ein Prompt ist eine Anweisung, keine Grenze. Das bedeutet: Sich darauf zu verlassen, dass sich der Agent an Regeln hält, macht das Design anfällig für feindliche Eingaben. Das Sicherheitsmodell muss sich daher von der Verwaltung von Anweisungen hin zur Durchsetzung überprüfbarer technischer Beschränkungen verschieben, was der Agent physisch erreichen oder ausführen kann.
Warum der Prompt keine Grenze ist
Die aktuelle Ausgabe der OWASP Top 10 für Anwendungen mit großen Sprachmodellen, veröffentlicht am 4. August 2026, hebt dieses grundlegende Problem hervor. Prompt Injection bleibt LLM01, der erste Eintrag der Liste. Gleichzeitig ist Excessive Agency deutlich gestiegen und erreicht in der Ausgabe 2026 LLM03, gegenüber Platz sechs in der Ausgabe 2025. Diese Kombination signalisiert eine kritische Verschiebung des Risikos: Der Eingabe kann nicht vertraut werden, und die dem Agenten gewährten Berechtigungen werden zum primären Gefahrenvektor.
Dieses Risiko wird durch die Natur der Daten selbst verstärkt. In einem Datensatz eingebetteter Text - sei es in einem Dokument, einer E-Mail, einer Ticketbeschreibung oder einer Webseite - ist Daten, niemals Autorisierung. Ein Agent, der Inhalte als Anweisung behandelt, kann von jedem gesteuert werden, der in irgendein System schreiben kann, das der Agent liest. Die technische Trennung zwischen Daten und Befehl muss auf architektonischer Ebene erzwungen werden, statt sich darauf zu verlassen, dass der Agent die Absicht korrekt interpretiert.
Drei Dinge, die das tatsächlich erzwingen
Erzwungene Isolation erfordert, drei unterschiedliche, überprüfbare technische Ebenen zu adressieren. Das sind Zugangsdaten, Zugriffsumfang und Laufzeitumgebung.
Zugangsdaten
Das Prinzip lautet: Der Agent muss über einen eigenen, dedizierten Satz Zugangsdaten verfügen, und diese dürfen niemals geteilt werden. Besitzt der Agent nicht das nötige Token oder den Schlüssel, kann er sich bei einem System nicht authentifizieren - unabhängig davon, was ihm gesagt wird. Ein architektonisches Muster ist ein Gateway, das die Zugangsdaten hält und bei jedem einzelnen Aufruf die erforderliche Identität einspeist. So besitzt der Agent nie selbst das rohe Token, was seine Fähigkeit einschränkt, Authentifizierungsmaterial zu missbrauchen oder zu exfiltrieren.
Um dies im eigenen System zu prüfen, versuchen Sie, den Agenten zu einer Authentifizierung mit Zugangsdaten zu zwingen, für die er nicht ausdrücklich vorgesehen ist. Schlägt die Authentifizierung fehl oder wird die Identität abgelehnt, hält die Zugangsdaten-Grenze.
Zugriffsumfang
Der Zugriffsumfang legt die genauen Grenzen der Berechtigung fest und stellt sicher, dass Berechtigungen gezielt und eng vergeben werden, statt breit gestreut. Entscheidend ist zu erkennen, dass die technische Fähigkeit, in ein System zu schreiben, nicht dasselbe ist wie die Berechtigung dazu. Pauschal vergebene Berechtigungen - an eine technische Gruppe oder über ein Feature-Flag, das jeder erhält - sind Konfigurationsschuld, kein Mandat.
Die Überprüfung besteht darin, den Agenten gegen eine Ressource zu testen, die er technisch sehen, aber nicht verändern können sollte. Verweigert das System die Aktion korrekt, ist der enge Umfang durchgesetzt.
Laufzeitumgebung
Die Laufzeitumgebung definiert die Umgebung, in der der Prozess ausgeführt wird, und was er von dort aus physisch erreichen kann. Ein Agent ist nur so eingegrenzt wie die Umgebung, in der er läuft. Diese Ebene stellt sicher, dass selbst wenn der Agent erfolgreich zur Ausführung eines Befehls verleitet wird, das Betriebssystem oder die Container-Umgebung den Umfang dieser Ausführung begrenzt.
Um dies zu prüfen, versuchen Sie, den Agenten mit einer Ressource oder einem Dienst interagieren zu lassen, der physisch außerhalb seiner vorgesehenen Laufzeitumgebung liegt. Das System muss die Anfrage aufgrund der Umgebungseingrenzung ablehnen, nicht aufgrund einer internen Regel oder Prompt-Anweisung.
Containment vor Fähigkeit
Über das Containment muss entschieden werden, bevor der Agent gebaut wird. Es lässt sich nicht nachträglich hinzufügen, weil um jede zuvor gewährte Fähigkeit herum bereits konstruiert wurde. Wer zuerst Funktionalität baut und sie dann in Sicherheitsebenen zu verpacken versucht, betreibt Nachrüstung, und die entstehende Architektur trägt inhärente Schwachstellen in sich.
Darüber hinaus muss das System so gestaltet sein, dass der Entzug von Zugriff durch eine einzige Änderung an einer einzigen Stelle erreicht wird, die auf einen Schlag alle Türen schließt. Dieser einzelne Kontrollpunkt stellt sicher, dass Änderungen der Sicherheitsrichtlinie sofort und umfassend wirken, statt manuelle Aktualisierungen über mehrere, getrennte Komponenten hinweg zu erfordern.
Was wir bewusst nicht behaupten
Dieser Designansatz ist eine technische Vorkehrung, kein Compliance-Zertifikat. Wir behaupten keine Konformität mit einem bestimmten Standard oder einer Prüfanforderung. Der Fokus liegt allein auf den technischen Prinzipien der Isolation und der überprüfbaren Verweigerung.
Entscheidend: Keine dieser drei Ebenen - Zugangsdaten, Zugriffsumfang oder Laufzeitumgebung - beantwortet die Frage, ob der Agent überhaupt existieren sollte. Die architektonische Entscheidung, einen Agenten einzusetzen, bleibt eine geschäftliche Risikoentscheidung, getrennt von den technischen Kontrollen. Mehr dazu in der Agent, den wir uns entschieden haben, nicht zu bauen.
Fragen und Antworten
Wie verhindern Sie, dass ein KI-Agent durch Prompt Injection ausgetrickst wird?
Allein durch Prompts lässt sich das nicht stoppen. Die Verteidigung muss architektonisch sein. Das erfordert die Durchsetzung technischer Grenzen mittels Zugangsdaten, Zugriffsumfang und Laufzeit-Isolation. Diese Ebenen stellen sicher, dass das zugrunde liegende System die Aktion verweigert, selbst wenn der Agent zur Annahme einer bösartigen Anweisung verleitet wird.
Reicht ein System-Prompt aus, um einen Agenten abzusichern?
Nein. Ein System-Prompt ist lediglich eine Reihe von Anweisungen, die beratend sind und umgangen werden können. Sicherheit muss durch überprüfbare, technische Kontrollen umgesetzt werden. Die Grenzen müssen physisch und rechnerisch sein, nicht sprachlich.
Welche Berechtigungen sollte ein KI-Agent haben?
Der Agent sollte nur Berechtigungen haben, die gezielt und eng für konkrete Aufgaben vergeben wurden. Vergeben Sie niemals pauschale Berechtigungen. Alle technischen Fähigkeiten müssen von der tatsächlichen Autorisierung getrennt sein.
Was passiert, wenn ein Agent kompromittiert wird?
Das Ziel des Designs ist, dass eine Kompromittierung lokal begrenzt bleibt. Durch strikte Zugangsdaten, engen Zugriffsumfang und eingegrenzte Laufzeitumgebung wird der Schaden, den ein Angreifer anrichten kann, auf den kleinstmöglichen operativen Bereich beschränkt.
Die zentrale Entwurfsfrage, die jeden Agenten-Einsatz leiten muss, lautet nicht: Was wird er können? Sie muss lauten: Welcher technische Mechanismus erzwingt seine Isolation, wenn ihn jemand gegen uns einsetzt? Der Fokus auf die Grenzen statt auf die Fähigkeiten ist es, was das Konstrukt hält.