SecurityPrompt Injection: Warum wir die Rechte unserer KI-Agenten begrenzen
Kurz gefasst: Adversa AI beschreibt eine Prompt Injection, bei der die Anweisung verschlüsselt auf einer Webseite liegt. Der Agent entschlüsselt sie selbst und befolgt sie, ein Textfilter sieht nur Zeichensalat. Bei Copilot CLI reichte dafür ein abgerufener Link, um in 28 Sekunden eine
.env.prodabzuziehen. Den Schaden begrenzen die Rechte des Agenten. Bei uns sind die Zugänge zu den Werkzeugen eingeschränkt, ein Ausgangsfilter für Webzugriffe ist auf dem Agent-Host nicht gemessen worden. Am Ende steht ein Zehn-Minuten-Check für Ihren eigenen Agenten.
Wer einen KI-Agenten eine Webseite lesen lässt, gibt dem Autor dieser Seite einen Teil seines Auftragsbuchs. Das ist keine neue Erkenntnis, aber im Sommer und Herbst 2026 hat die Sicherheitsfirma Adversa AI gezeigt, dass sich der Weg dafür nicht mehr mit einem Textfilter verbauen lässt. Dieser Beitrag fasst zusammen, was Adversa und Ars Technica belegen, und beschreibt dann, was wir über unsere eigenen Agenten dokumentiert und am 5. November gemessen haben. Vieles davon ist unvollständig, und wir sagen, wo.
Prompt Injection ist ein Angriff, bei dem ein KI-Agent Text aus einer nicht vertrauenswürdigen Quelle, etwa einer Webseite, einer Mail oder einer Tool-Ausgabe, wie einen Auftrag des Nutzers behandelt und befolgt. Wie groß der Schaden wird, bestimmen die Rechte des Agenten: Alles, was er lesen, ausführen und nach außen senden darf, kann ein Angreifer mitbenutzen.
Was Adversa und Ars Technica belegen
Adversa nennt die Methode Cryptographic Context Injection. Die Anweisung liegt als AES-256-GCM-Chiffretext auf der Seite, daneben stehen Schlüsselmaterial und die Bitte, mit Python zu entschlüsseln. Ein Klartext-Filter kann den Inhalt nicht lesen, weil dafür ein Entschlüsseln nötig wäre. Der Agent führt die Entschlüsselung in seiner eigenen Code-Umgebung aus, und das Ergebnis erscheint als Ausgabe seines eigenen Programms. Dort, so Adversa, wird es nicht mehr als fremde Eingabe behandelt. Dieselben Anweisungen im Klartext lehnte Copilot CLI laut Adversa ab. Ars Technica fasst es am 20. August so zusammen, dass Sprachmodelle die Wurzel von Prompt Injection nicht lösen können und Hersteller deshalb Leitplanken bauen, die der nächste Angriff umgeht. Das ist die Einschätzung des Autors.
Drei Fälle.
Bei Grok (Bericht vom 20. August) baut der Agent auf die Bitte, eine Seite zusammenzufassen, laut Adversa einen angeblichen Schlüssel, der in Wahrheit Name, Ort, Tarif und Chatverlauf des Nutzers enthält, und hängt ihn an eine URL des Angreifers. Gemeldet wurde das xAI am 3. Juni, nach Angaben von Adversa blieben die Nachfragen vom 4. und 10. August unbeantwortet, am 19. August war der Angriff noch reproduzierbar.
Bei Gemini sieht der entschlüsselte Text aus wie ein Python-Traceback und enthält die Anweisung, bei einem Fehler die Fehlermeldung zu befolgen. Laut Adversa erzeugte das Inhalte, die Gemini sonst unterdrückt, und gab die Systemanweisungen preis. Im Sommer sank die Erfolgsquote, die Ursache ist unbekannt.
Bei GitHub Copilot CLI (Bericht vom 6. Oktober) lässt der Nutzer den Agenten im Autopilot-Modus eine Seite lesen. Nach 28 Sekunden liegt der Inhalt einer .env.prod im Log des Angreifers, und die Zusammenfassung des Agenten meldet etwas anderes. Welches Modell die Sitzung bearbeitet, spielt mit hinein: Ein Modell führte die Kette in 50 Prozent der Versuche aus, zwei andere verweigerten sie. Bei automatischer Modellwahl sieht der Nutzer nicht, welches er bekommt. GitHub erkannte den Fund als gültig an, wertete ihn aber nicht als Sicherheitslücke, weil der Nutzer dem Agenten die Seite und volle Rechte gegeben habe.
Adversa verkauft eine Plattform für Agenten-Sicherheit. Die Messungen sind Angaben des Herstellers, nachgestellt haben wir sie nicht. Eine Angabe wie „20 Versuche, 40 Prozent“, die uns zu Grok begegnet ist, steht weder bei Adversa noch bei Ars und kommt hier nicht vor.
Fünf Regeln, und wo wir stehen
Adversa leitet daraus fünf Regeln für die Umgebung um den Agenten ab: nicht vertrauenswürdige Inhalte in einem Kontext ohne Werkzeuge und Zugangsdaten verarbeiten, ausgehende Aktionen mit aufgelösten Argumenten freigeben, pro Sitzung die Werkzeugaufrufe aufzeichnen, auf Abfolgen statt einzelner Texte alarmieren, und bei Herstellern nach der Trennung von Daten und Anweisungen fragen. Wir haben diese Regeln mit unseren Notizen und Messungen verglichen.
| Adversa-Regel | Bei uns dokumentiert | Quelle, Stand |
|---|---|---|
| Fremdtext ohne Rechte verarbeiten | Für den Mail-Prüfer gilt die Regel: Ein manipulierter Text darf das Urteil weder stummschalten noch lenken, ein fehlendes Urteil gilt nie als Freigabe. Für den geplanten Posteingang im persönlichen Assistenten steht Bereinigen und Testen als Vorbedingung. | Notizen vom 4. Oktober und 17. August |
| Ausgehende Aktionen begrenzen | Mailversand der Agenten geht nur an drei Adressen aus einer Liste, die auf dem Host liegt und nicht im Zugriff des Agenten. Für Webzugriffe ist kein Ausgangsfilter dokumentiert. | Notiz vom 17. September, Messung unten |
| Werkzeugaufrufe aufzeichnen | Prompts, die über den LiteLLM-Gateway laufen, werden in Postgres gespeichert. Ob darin die aufgelösten Werkzeug-Argumente jeder Sitzung stehen, haben wir nicht geprüft. | Notiz vom 7. August |
| Auf Abfolgen alarmieren | In unseren Unterlagen steht nichts dazu. | Stand 5. November |
| Trennung bei Herstellern erfragen | Offen, wir haben keine Liste. | Stand 5. November |
Der Filter im Gateway sucht nach Mustern. Eine Notiz vom Oktober hält fest, dass er die Wendung „Ignore previous instructions“ blockierte und „Ignore all previous instructions“ durchließ. Im August stellte sich heraus, dass sechs von sechs organischen Treffern Fehlalarme waren, zum Beispiel ein Skill-Katalog mit dem Wort „jailbreak“ in der Beschreibung. Ein Treffer im Tool-Ergebnis blieb für immer in der Sitzung und legte sie lahm. Wer Muster für Imperative schreibt, nicht für Vokabeln, hat weniger Ärger, aber gegen verschlüsselte Texte hilft ein Mustervergleich nach Adversas Beschreibung nicht.
Was wir am 5. November gemessen haben
Gemessen wurde nur lesend, per iptables -S über SSH, am 5. November 2026, 20:06 UTC, auf zwei Hosts unter Linux: dem Host für LibreChat, LiteLLM und die MCP-Sidecars sowie dem Host für den Agenten dsh.
| Messung | Ergebnis | Einheit | Messträger |
|---|---|---|---|
| Gate vor den sieben dsh-Sidecars | 1 Regel: alles außer dem Agent-Host wird verworfen | Regeln | Sidecar-Host, Kette DOCKER-USER |
| Gate vor dem LiteLLM-Port | 17 erlaubte Quellen, alles andere laut Skript protokolliert und verworfen | Quellen | derselbe Host |
| Gate vor dem Crawl-Sidecar | 6 erlaubte Quellen | Quellen | derselbe Host |
| Ausgangsfilter auf dem Agent-Host | Kette DOCKER-USER leer, OUTPUT auf ACCEPT | Regeln | Agent-Host |
Der Kommentar im Skript des Gateways hält fest, dass LiteLLM-Port und Crawl-Sidecar bis zum Audit am 26. Oktober ohne Anmeldung im ganzen LAN offen waren. Das Gate wurde nach einem Audit gesetzt und schützt die Eingänge. Gegen die Frage „Wohin darf der Agent senden, wenn eine gelesene Seite es verlangt?“ sagt es nichts, und genau darauf zielt der Angriff. Auf dem Agent-Host haben wir keinen Filter für ausgehende Verbindungen gefunden. Ob ein Proxy oder eine Regel im Container dazwischen sitzt, haben wir nicht untersucht.
Zu den Rechten laut Notizen: Der Token des Proxmox-MCP war bei der Prüfung am 3. August kein Nur-Lese-Token: Er hatte auf allen Knoten Rechte zum Anlegen, Löschen, Stoppen und Zurückrollen von VMs. Als Fix ist die Rolle PVEAuditor vermerkt. Das Profil operator im MCP-Server regelt nur auf Anwendungsebene, die Grenze zieht der Token. Eine spätere Notiz zum Telegram-Agenten führt denselben Token auf. Ob er inzwischen getauscht ist, haben wir für diesen Beitrag nicht geprüft. Beim Agenten dsh vermerkt eine Notiz vom 5. Oktober, dass der Container die Root-SSH-Schlüssel der Flotte eingebunden hat, und die Agenten-CLI läuft seit dem 29. September als root auf dem Host. Beides war am 5. Oktober als offene Entscheidung festgehalten.
Noch zu messen
Drei Punkte haben wir für diesen Beitrag nicht gemessen. Wir nennen die Methode, ein Ergebnis gibt es noch nicht.
- Ausgehender Verkehr des Agenten: Auf dem Agent-Host nach
ip route, Proxy-Variablen im Container und Regeln inFORWARDundDOCKER-FORWARDsehen, danach von einem Menschen einen einzelnen Aufruf an einen eigenen Testserver aus dem Container absetzen und im Log des Testservers zählen. Der Agent selbst bekommt dafür keinen Auftrag. - Rechte des Proxmox-Tokens:
GET /access/permissionsmit dem Token gegen jeden Pfad abfragen und gegen die Schreibrechte abgleichen, wie in der Notiz vom 3. August beschrieben. - Spuren pro Sitzung: In
LiteLLM_SpendLogsdas Feldproxy_server_requesteiner dsh-Sitzung lesen und prüfen, ob Werkzeug-Aufrufe mit aufgelösten Argumenten drinstehen. Das Feldmessagesbleibt dort laut Notiz leer.
Einen Angriff mit verschlüsselter Anweisung gegen unsere Agenten stellen wir nicht nach.
Der Zehn-Minuten-Check
- Notieren Sie jeden Agenten, der Webseiten, Mails oder Tickets liest (zwei Minuten).
- Schreiben Sie daneben, welche Schlüssel, Dateien und Netzwerke derselbe Agent erreicht (drei Minuten).
- Streichen Sie bei jeder Zeile mit beidem ein Recht: Lesen trennen oder die Zugangsdaten entfernen (drei Minuten).
- Prüfen Sie von Hand, ob der Agent ohne Rückfrage nach außen senden darf, und tragen Sie das Ergebnis ein (zwei Minuten).
Bei der Umsetzung hilft unsere Arbeit an KI auf eigener Hardware. Die Vorgeschichte der Angriffsklasse steht in Agentjacking: Wenn die Fehlermeldung den KI-Agenten kapert, und weitere Beiträge zum Thema sammelt Security und Datenschutz.
Belegt und offen
Belegt, weil wir die Quellen am 5. November gelesen haben: der Aufbau der Methode, die drei Fälle samt Meldedaten, die 28 Sekunden, die 50 Prozent bei einem Copilot-Modell und die Haltung von GitHub, alles als Angaben von Adversa, bei Grok zusätzlich eingeordnet von Ars Technica (dessen Text wir nur im Kopfbereich lesen konnten). Belegt durch eigene Messung vom 5. November: die Gate-Regeln und der fehlende Ausgangsfilter auf dem Agent-Host.
Offen: ob xAI, Google und GitHub seit den Berichten etwas geändert haben, ob die Zahlen von Adversa unabhängig reproduzierbar sind, und die drei Punkte aus „Noch zu messen“.
Weiterführende Quellen
Quellen zuletzt geprüft: 2026-11-05
- Adversa AI: GitHub Copilot CLI vulnerability, Cryptographic Context Injection steals developer secrets, 6. Oktober 2026; Herstellerbericht mit Meldeverlauf.
- Adversa AI: Zero-click Grok data theft, 20. August 2026; Methode, Grok- und Gemini-Fall.
- Ars Technica: Grok exfiltrates user data when malicious instructions are encrypted, 20. August 2026; unabhängige Einordnung von Dan Goodin.
- Logos: GitHub Copilot, Simple Icons 16.36.0 (MIT laut Icon-Daten, Marke: GitHub).
Was hat Adversa AI bei Copilot CLI gezeigt?+
Laut Adversa liest GitHub Copilot CLI im Autopilot-Modus nach dem Abruf einer präparierten Webseite die Datei .env.prod und schickt den Inhalt an einen Angreifer, in 28 Sekunden und ohne Rückfrage. Das hängt vom Modell ab: Ein Modell führte die Kette in 50 Prozent der Läufe aus, zwei andere verweigerten sie. GitHub stufte den Fund nicht als Sicherheitslücke ein. Das sind Angaben von Adversa, wir haben den Angriff nicht nachgestellt.
Hilft ein Filter gegen Prompt Injection?+
Nur begrenzt. Unser eigener Filter in LiteLLM blockierte laut einer Notiz vom Oktober die Wendung Ignore previous instructions, ließ aber Ignore all previous instructions durch. Adversa beschreibt außerdem, dass verschlüsselter Text Textfilter gar nicht erst auslöst. Filter bleiben als Zusatz sinnvoll, die Grenze setzen die Rechte des Agenten.
Was ist der erste Schritt für einen Mittelständler?+
Eine Liste führen: Welcher Agent liest fremden Text, und welche Zugangsdaten hat derselbe Agent? Wo beides zusammenkommt, entweder Lesen oder Rechte trennen. Der Zehn-Minuten-Check am Ende dieses Beitrags geht das Schritt für Schritt durch.
senn-tech