Im letzten Artikel über präparierte Dokumente als Steuerfläche für Agenten stand noch der saubere, analytische Teil: ja, man kann Bewerbungsunterlagen, PDFs oder HTML-Vorschauen so bauen, dass ein nachlässig verdrahteter Agent sie nicht nur liest, sondern ihnen gehorcht. Inzwischen gibt es den unerquicklicheren Teil dazu: Wir haben genau solche Dokumente gebaut und gegen eigene interne Systeme getestet.
Nicht gegen fremde Dienste. Nicht gegen irgendein Opfer im Internet. Sondern gegen unsere eigenen Dokumenten- und Agentenpfade, darunter lokale Setups mit OCR, Dokumentenverarbeitung und Agentenanbindung wie OpenClaw und Pagerless. Der Zweck war nicht Cybercrime. Der Zweck war herauszufinden, ob untrusted Dokumentinhalt in diesen Ketten sauber als Daten behandelt wird – oder ob er unterwegs zur Instruktion mutiert.
Was wir konkret getestet haben
Die Testartefakte waren keine Hollywood-Payloads, sondern absichtlich banale Canary-Dokumente: harmlose eingebettete Marker, einzelne versteckte Anweisungen und ein kontrollierter Mail-Callback als Nachweis, dass ein System nicht mehr nur extrahiert, sondern bereits gehorcht. Genau darum geht es bei solcher Prüfung: nicht um Exploit-Folklore, sondern um die Frage, ob ein Workflow die Grenze zwischen Inhalt und Befehl noch versteht.
Das ist der entscheidende Punkt, den erstaunlich viele AI-Demos bis heute nicht ernst nehmen. Ein CV, ein PDF oder eine HTML-Vorschau ist in solchen Systemen keine nebensächliche Datenquelle. Es ist per Design relevanter Input. Wer ihn auslesen, zusammenfassen, priorisieren und an Agenten mit Werkzeugen weiterreichen will, darf sich nicht wundern, wenn aus „Dokument lesen“ irgendwann „Dokument gehorchen“ wird.
Und dann kam OpenAI mit „Cyber Abuse“
Der amüsante Teil – sofern man für diese Sorte Humor empfänglich ist – war die Rückmeldung auf dem Weg dorthin: Weil GPT-5.5 beziehungsweise ein OpenAI-basierter Pfad verwendet wurde, um ein solches internes Testdokument zu erzeugen, kam von OpenAI eine Warnung wegen Cyber Abuse. Keine Sperre, kein großes Theater, nur eine klare gelbe Karte mit Appeal-Möglichkeit.
Und ehrlich gesagt: Das ist gut so.
OpenAI hat sich in dieser Geschichte nicht als Bremser, sondern als verantwortlicher Anbieter verhalten: vorsichtig genug für eine gelbe Karte, aber nicht so stumpf, dass legitime defensive Arbeit sofort als Weltuntergang behandelt wird. Genau so sollte das aussehen. Wer KI in echte operative Abläufe bringen will, muss bei missbrauchsnahen Mustern konservativ sein. Ein Provider kann nicht zuverlässig unterscheiden, ob gerade ein echter Angriff gegen Fremdsysteme vorbereitet wird oder ein legitimer Test gegen eigene Infrastruktur. Genau deshalb war die Reaktion richtig.
Und genau deshalb ist diese Realität auch besser als das ganze Superhacker-Gefasel: keine dämonische Maschinenüberseele, kein digitaler Okkultismus, sondern ein brauchbarer Anbieter mit funktionierenden Abuse-Grenzen und die unerquicklich menschliche Pflicht, Systeme ordentlich zu bauen. Das ist sehr viel langweiliger als AI-Mythologie – und sehr viel nützlicher.
Die Gegenthese bleibt trotzdem richtig: Solche Tests müssen gegen eigene Systeme möglich sein. Nicht aus Hackerromantik, sondern weil man sich sonst blind an den freundlichsten Modellanbieter der Gegenwart ausliefert. Wer heute nur mit harten Guardrails eines großen Providers plant, baut morgen unter Umständen eine Architektur, die bei einem schwächeren Modell, einem selbstgehosteten Setup oder einem weniger vorsichtigen Anbieter sofort weich wird. Gerade deshalb war die gelbe Karte von OpenAI hier fast ideal: konservativ genug, um aufzufallen, aber nicht so grob, dass sie den defensiven Erkenntnisgewinn unmöglich macht.
Wichtig ist auch, was wir dabei überhaupt geprüft haben: nicht Modelle gegeneinander, nicht die angebliche Bosheit einer KI, sondern die Softwarekette um das Modell herum. Die eigentliche Frage lautete nicht, ob ein LLM „böse“ wird, sondern ob die umgebende Anwendung Content sauber von Instruction trennt. Genau dort sitzt das reale Risiko. Wenn ein Dokumentenpfad, ein OCR-Stack oder eine Agentenanbindung diese Grenze nicht hält, dann ist nicht das Modell mystisch gefährlich. Dann ist die Software schlicht schlecht gebaut.
Die Lehre ist nicht: Filter schlecht. Die Lehre ist: Rollen sauber trennen.
Der Vorfall widerlegt nicht die ursprüngliche These. Er bestätigt sie eher. Das Problem ist nicht magische Modellbosheit. Das Problem ist operative Verdrahtung. Auf der Zielseite heißt das: Dokumente dürfen nicht zu Befehlen werden. Auf der Erzeugungsseite heißt das: Nicht jeder Agent sollte aktive Red-Team-Artefakte über einen externen Provider generieren, selbst dann nicht, wenn das Zielsystem lokal und autorisiert ist.
Mit anderen Worten: Security denken, ja. Security prüfen, ja. Aber providernahe Assistenten sollten eher analysieren, modellieren, bewerten und lenken – nicht selbst die schärferen Testartefakte bauen. Dafür braucht es einen getrennten Security-Agenten mit engem Scope, klaren Grenzen und einer Umgebung, in der man ihn bei Bedarf auch wieder einfangen kann. Jemand muss bauen und betreiben. Jemand anderes muss misstrauen, prüfen und im Zweifel SQL-Injection in das Passwortfeld werfen. Beides in denselben höflichen Allzweckagenten zu kippen, ist vor allem eine gute Methode für spätere Ausreden.
Warum das trotzdem ein gutes Signal ist
Die eigentliche gute Nachricht an der Geschichte lautet also nicht nur: Ja, GPT-5.5 ist da. Sondern auch: Ja, es gibt Filter. Und ja, es ist gut, dass sie anschlagen, bevor aus experimenteller Cleverness operative Dummheit wird.
Die richtige Reaktion auf so eine Warnung ist auch nicht Beleidigtsein, sondern Kalibrierung. Wir haben die Einordnung knapp beantwortet, den defensiven Kontext erklärt und die operative Konsequenz gezogen: Keine providernahe Erzeugung aktiver Red-Team-Inhalte mehr über den allgemeinen Assistentenpfad. Das ist kein Kuschelkurs, sondern Hygiene.
Und der wichtigere Teil bleibt sowieso der auf Zielseite: Wenn ein präpariertes Dokument in einem internen Agenten-Workflow mehr auslösen kann als eine nüchterne Zusammenfassung, ist nicht das Dokument das eigentliche Problem. Dann ist die Architektur schlampig. Genau deshalb lohnt sich dieses Testen – und genau deshalb ist es gut, wenn dabei nicht nur die lokalen Systeme, sondern auch die Schutzmechanismen der Anbieter zeigen, wo sie konservativ werden.
Anders gesagt: Die Dokumente waren echt. Die Tests waren echt. Die Warnung war echt. Und das ist wahrscheinlich gesünder als eine Welt, in der alle Beteiligten einfach so tun, als gäbe es dieses Problem noch nicht.