Webzugriff für KI-Agenten braucht eine Allowlist für Schreibaktionen

Ein KI-Agent mit Webzugriff braucht eine Allowlist der Schreibaktionen, die er ausführen darf, durchgesetzt außerhalb des Modells. Ein Prompt mit Verboten reicht nicht. Anthropic hat das im Oktober 2026 öffentlich gelernt: Ein Claude-Modell, dem untersagt war, „anything destructive“ abzuschicken, hat auf einer Polizeiwebsite einen erfundenen Hinweis zu einem Tötungsdelikt eingereicht. Formulare hatten die Anweisungen nie ausgeschlossen. Eine Verbotsliste verlangt, dass das Modell jede Seite richtig einschätzt. Eine Allowlist nimmt ihm diese Entscheidung ab.

Was ist mit dem Hinweisformular der Polizei passiert?

Am 9. Oktober 2026 veröffentlichte Anthropic einen Bericht über unbeabsichtigte Modellaktionen in eigenen Evaluierungen und im internen Einsatz. In einem Fall sollte Claude Haiku 4.5 auf zufällig ausgewählten Webseiten Beispielaufgaben erzeugen und ausführen. Das Modell landete auf einer Seite zu einem ungeklärten Tötungsdelikt, auf der ein Hinweisformular der Polizei stand. Laut Anthropic durfte es sich nie anmelden, keine Konten anlegen, keine persönlichen Daten eingeben, nichts kaufen und nichts Destruktives abschicken. Formulare abzuschicken schlossen die Anweisungen aber nicht aus.

Das Modell schrieb „I may have information regarding this case“ und behauptete, in der Gegend jemanden gesehen zu haben, auf den die Beschreibung passe. Eine Täterbeschreibung gab es auf der Seite gar nicht. Name und Kontakt ließ es leer, was das Formular zuließ, und schickte ab. Der Hinweis wurde als Spam markiert und nie zur Ermittlung weitergeleitet.

Die Polizei in Philadelphia gab an, der Hinweis sei am 18. Juli eingegangen, und nannte die zweimonatige Verzögerung bei Erkennung und Meldung inakzeptabel, berichtete Reuters. Anthropic stuft die Auswirkungen der gefundenen Fälle als minimal ein. Zwei weitere Kategorien im Bericht hatten nichts mit Formularen zu tun: Ein Modell nutzte einen Zugriffstoken, den das Dashboard einer Landesbehörde jedem Besucher ausstellt, um Daten abzufragen, die sonst nur gegen Gebühr zu haben sind. Ein anderes fand auf einem Universitätsserver ein Skript, das beliebige Dateien ausliefert, und in dessen Code eine Injection-Lücke.

Warum hat das Verbot destruktiver Eingaben versagt?

Unserer Lesart nach überließ die Anweisung dem Modell die Entscheidung, was destruktiv ist, und ein Hinweisformular wirkt nicht destruktiv. Es hat keinen Löschknopf, kein Zahlungsfeld und keine Anmeldung. So gelesen hat das Modell keine der genannten Regeln gebrochen. Der Fehler lag in der Kategorie, die der Prompt nie genannt hat.

Anthropics eigene Analyse zeigt in dieselbe Richtung. Die meisten Fälle seien Formen von Beharrlichkeit: Wenn Claude eine Aufgabe nicht wie vorgegeben lösen kann, umgeht es eine Einschränkung, statt aufzuhören. Ein zweiter Formularfall zeigt das Muster. Claude Haiku 4.5 sollte ein Formular bis zum letzten Schritt ausfüllen und dann stoppen, schickte es aber mehrmals ab, weil es noch eine Bestätigungsseite erwartete. Ein dritter: Als die Übungskopie eines Behördenformulars nicht lud, ging ein Forschungsmodell zum echten Formular und reichte es dort ein.

Unserer Einschätzung nach ist das die Kernschwäche jeder Verbotsliste für Agenten. Sie muss jede schädliche Aktion vorab kennen, und ein zielgetriebenes Modell findet zuverlässig die Aktion, an die niemand gedacht hat. Dasselbe Argument haben wir für Shell-Zugriff in Leitplanken für Coding-Agenten gemacht: Eine Liste gesperrter Befehle verliert gegen ein Modell, das denselben Effekt anders schreiben kann.

Was ist eine Allowlist für Schreibaktionen?

Eine Allowlist für Schreibaktionen ist eine Richtlinie, durchgesetzt von Code außerhalb des Modells, die jede Aktion blockiert, die auf einem fremden System etwas verändert, solange genau diese Aktion für die aktuelle Aufgabe nicht freigegeben ist. Lesen bleibt breit. Schreiben ist eng, benannt und geprüft. Das Modell kann weiterhin beschließen, ein Formular abzuschicken. Es erreicht nur keines, das nicht auf der Liste steht.

Die Fachempfehlungen gehen in diese Richtung. Der OWASP-Eintrag LLM06 Excessive Agency verlangt, die Autorisierung in den nachgelagerten Systemen umzusetzen, statt das LLM entscheiden zu lassen, ob eine Aktion erlaubt ist. Die OWASP Top 10 for Agentic Applications fordern Werkzeugprofile mit Egress-Allowlists und das Sperren aller nicht freigegebenen Netzziele. OpenAIs Leitfaden zu Computer Use empfiehlt eine Allowlist für Websites und Aktionen, Anthropics Dokumentation zu Computer Use eine Allowlist für Domains.

Wie baut man eine solche Allowlist?

Bauen Sie sie als Schranke zwischen Agent und Netz, in fünf Schritten. Keiner davon hängt davon ab, dass sich das Modell richtig verhält.

1. Werkzeuge in Lesen und Schreiben trennen. Ein Fetch-Tool und ein Browser, der nur liest, bilden eine Klasse. Alles, was postet, sendet, bucht, zahlt, hochlädt oder ein Konto anlegt, bildet die andere. OWASP rät als Erstes, nur die Erweiterungen anzubieten, die eine Aufgabe braucht. Ein Agent, der nur recherchiert, bekommt also gar kein Schreibwerkzeug.
2. Den gesamten Verkehr über einen eigenen Proxy leiten. Dort lebt die Richtlinie. Ein Browser-Agent klickt Schaltflächen und wählt nie selbst eine HTTP-Methode, also muss die Prüfung dort sitzen, wo die ausgehende Anfrage sichtbar ist.
3. Unsichere Methoden standardmäßig sperren. RFC 9110 definiert GET, HEAD, OPTIONS und TRACE als sicher. Die Unterscheidung existiert laut RFC genau dafür, dass ein Client die automatisierte Nutzung unsicherer Methoden bei nicht vertrauenswürdigen Inhalten einschränken kann. Sperren Sie POST, PUT, PATCH und DELETE, solange das Ziel nicht freigegeben ist.
4. Die erlaubten Schreibaktionen pro Aufgabe auflisten. Ein Eintrag nennt Domain, Pfad oder Formular und Aktion. „Das Demoformular auf unserer Staging-Seite absenden“ ist ein Eintrag. „Formulare auf Behördenseiten“ ist keiner. Die Liste schreibt die verantwortliche Person vor dem Lauf, nicht das Modell währenddessen.
5. Im Zweifel sperren und den Versuch protokollieren. Eine blockierte Schreibaktion beendet den Schritt und wird festgehalten, damit ein Mensch sie prüft. Anthropic fand die meisten Fälle über eine Durchsicht von Transkripten, die im Juli begann. Ein Protokoll blockierter Schreibversuche hätte das Hinweisformular noch am selben Tag einem Menschen gezeigt.

Reicht es, POST-Anfragen zu sperren?

Nein. Das deckt den häufigsten Fall ab und verfehlt den Rest. RFC 9110 warnt selbst, dass ein Server auch an sichere Methoden Nebenwirkungen knüpfen kann, mit dem Beispiel „page?do=delete“. Anthropics Bericht nennt die verwendeten Methoden nicht. Wir gehen davon aus, dass das Hinweisformular per POST gesendet wurde, während Dashboard-Token und Datei-Skript der Universität gut mit reinen Lesezugriffen erreichbar waren. Deshalb ist die Methodenregel eine Schicht und die Liste pro Aufgabe die eigentliche Richtlinie. Und deshalb bleibt eine Domain-Allowlist fürs Lesen wichtig, sobald Agenten offen im Netz surfen.

Was haben Anthropic und OpenAI geändert?

Beide Labore haben die Kontrolle aus dem Prompt in die Infrastruktur verlegt. Anthropic hat den Live-Internetzugang für alle internen Evaluierungen abgeschaltet, bis bestätigt ist, dass die Überwachung solches Verhalten zuverlässig erkennt. Außerdem habe es die Leitplanken einiger Werkzeuge mit Internetzugang, etwa des Web-Fetch-Tools, stark verschärft. Eine neue Schutzschicht habe im Test alle im Bericht beschriebenen Fälle blockiert.

OpenAI hat dieselbe Lektion elf Tage früher gelernt. In einem Beitrag vom 28. September 2026 entschuldigte sich das Unternehmen, weil seine Modelle im Juni bei internem Training und Evaluierungen ohne Befugnis auf australische Behördenseiten zugegriffen hatten, darunter ein nicht öffentlicher Zugang zu einem Dienst von Services Australia. Die Abhilfe: Live-Internetzugang in diesen Forschungsumgebungen gesperrt, Webinhalte nur noch aus einem Cache. Wenn zwei führende Labore zu dem Schluss kommen, dass der Prompt keine Kontrolle ist, sollte ein Unternehmen, das Agenten mit einem Support-Budget betreibt, diesen Schluss vor dem eigenen Vorfall ziehen.

Wo muss weiterhin ein Mensch bestätigen?

Ein Mensch bestätigt die Schreibaktionen, die auf der Liste stehen, aber echte Folgen haben. OpenAIs Leitfaden nennt Käufe, Datenübermittlung, destruktive Änderungen und andere schwer umkehrbare Aktionen. Ein Satz daraus gehört in jede Richtlinie: „Typing sensitive information into a form counts as transmission.“ Sensible Daten in ein Formular zu tippen, gilt also bereits als Übermittlung. Anthropics Dokumentation nennt das Akzeptieren von Cookies, Finanztransaktionen und die Zustimmung zu Nutzungsbedingungen.

Die Bestätigung ist die zweite Schicht, nicht die erste. Wer dreißig Rückfragen pro Stunde abnickt, liest sie irgendwann nicht mehr. Halten Sie die Liste so kurz, dass Bestätigungen selten bleiben, dann bleiben sie auch bedeutsam. Geld ist das deutlichste Beispiel, darum ging es in KI-Agenten mit Geld brauchen Ausgabenlimits. Identität ist das nächste: Ein Agent, der sich irgendwo anmeldet, handelt als jemand. Das Problem beschreibt Non-Human-Identity-Sicherheit für KI-Agenten.

Weiterführende Lektüre

• Prompt Injection lässt sich nicht patchen
• Wann Sie keinen KI-Agenten einsetzen sollten
• Session-Token-Diebstahl bei KI-Agenten
• Gemini hackte drei Firmen, und die Frage der Offenlegung