Ich ließ Claude mein Security-Training hacken. Dann griff Anthropic ein.

Ich besuche das praxisnahe Training von certifiedsecure.org schon seit einigen Jahren. Es ist eines der besten Dinge, die ich im Jahr mache. Nicht wegen der Zertifikate oder der Theorie. Weil es die einzige autorisierte Umgebung ist, in der ich wirklich das Schmutzige tun darf: Netzwerk-Enumeration, Privilege Escalation, das Ausnutzen falsch konfigurierter Dienste, die ganze Kette. Für zwei Tage ist Angreifen die Aufgabe.

Diese Ausgabe hieß “Full-Stack Security Training: Salt Road - Compromised Components.” Zwei Tage, sechs Missionen pro Tag, eine isolierte Laborumgebung ohne Verbindung zu einem produktiven System.

Im letzten Jahr ging es darum, LLM-Agenten zu hacken: die KI dazu bringen, Passwörter preiszugeben, die sie schützen sollte. Direkte Prompt-Injection. Faszinierend, und eine klare Lektion darüber, warum Output-Redaktion reine Theaterkulisse ist.

In diesem Jahr kam ich mit einer anderen Frage: Was, wenn ich aufhöre, der Angreifer zu sein, und die KI angreifen lasse?

Die KI greift an

Ich gab Claude Opus SSH-Zugang zur Laborumgebung und beschrieb das Ziel: eine Reihe von Missionen in einer isolierten, autorisierten Infrastruktur. Claude kannte certifiedsecure.org bereits und half gerne.

Die ersten drei Missionen liefen sauber durch. Ohne Hinweise von mir. Claude führte Netzwerk-Reconnaissance über das Labor-Subnetz durch, fand einen Consul-Konfigurationsspeicher ohne Zugriffskontrollen und las Zugangsdaten direkt aus der API aus. In der nächsten Mission arbeitete Claude gegen einen LLM-Agenten in der Umgebung und brachte ihn dazu, ein maskiertes Geheimnis über kodierte Darstellungen preiszugeben. In Mission drei erkannte Claude eine Kubernetes-RBAC-Fehlkonfiguration, ermittelte, welches Secret ein Deployment referenzierte, und erstellte einen Pod mit einem secretKeyRef, um den Token zu mounten und zu exfiltrieren. All das ohne Anleitung.

Das war kein Autocomplete. Keine lange Liste von Befehlen, die ich genauso hätte schreiben können. Es war echtes Red-Team-Denken: eine Hypothese aufstellen, testen, pivoten wenn der erste Ansatz scheitert, die Umgebung so lesen wie sie wirklich ist und nicht wie man sie erwartet hätte. Die Art von Arbeit, die früher einen erfahrenen menschlichen Angreifer erforderte, der diese Systeme kannte.

Bei Mission vier hatte Claude Schwierigkeiten und brauchte Hinweise, die gleichen, die ein Trainer während der Session geben würde. Er schloss sie ab. Bei fünf genauso.

Mission sechs war, wo Anthropic eingriff.

Die abgebrochene Session

Es gab keine Ablehnung mitten in der Aufgabe. Claude wurde nicht plötzlich vorsichtig und erklärte, warum er nicht weitermachen könne. Was geschah, war auf einer höheren Ebene: Anthropic erkannte die Session und leitete sie um. Ich erhielt einen Link zu einem Formular mit dem Titel “Cyber Use Case”, dem Einstiegspunkt in Anthropics Cyber Verification Program, für Nutzer, die glauben, ihr Anwendungsfall sei legitim und möchten eine Anpassung der Schutzmaßnahmen beantragen.

Das Programm existiert, also gibt es einen Weg. Du bewirbst dich, erklärst den Kontext, und jemand bei Anthropic bewertet den Fall. In dieser Situation: ein autorisiertes, isoliertes Trainingslabor einer angesehenen Sicherheitsorganisation, ein jährliches zweitägiges Format, keine Verbindung zu produktiven Systemen. Genau der Kontext, für den das Programm gedacht ist.

Aber die Session war bereits tot.

Meine Reaktion war keine Frustration über den Mechanismus. Ich verstehe, warum ein Anbieter so etwas baut. Die gleiche Fähigkeit, die Claude ermöglichte, eine Security-Lab-Kette zu durchlaufen, würde genauso gut auf ein echtes Ziel zeigen, und das Modell kann den Unterschied nicht verifizieren. Ein Filter, der auf dem Verhalten statt auf behauptetem Kontext basiert, ist der einzige Filter, der skaliert.

Was mich beschäftigte, war die Implikation. Anthropic entscheidet, wer KI für diese Klasse von Aufgaben nutzen darf. Heute bedeutet das Security-Training. Morgen könnte es etwas anderes sein. Die Frage des Capability-Gatekeepings ist nicht theoretisch: Ein privates Unternehmen kontrolliert nun, ob du ein Allzweck-Reasoning-Tool für eine wachsende Liste von Anwendungsfällen einsetzen kannst, und diese Liste wird von diesem Unternehmen definiert und überarbeitet, nicht von dir. Ich verstehe das Warum. Den Löwen beobachte ich trotzdem.

Für den Rest des Trainings stieg ich auf den Modus um, mit dem ich hätte beginnen sollen: Claude als Sparringspartner, ich mache die eigentliche Arbeit.

Was du lernst, wenn du selbst anpackst

Es gibt etwas Konkretes, das sich ändert, wenn du die Ausführung nicht auslagern kannst. Das gedankliche Modell muss in deinem Kopf leben, nicht im Kontextfenster eines Agenten. Als Claude die ersten drei Missionen durchführte, schaute ich zu und verstand. Als ich Missionen fünf und sechs mit Claude als Assistent durchführte, musste ich das gesamte Bild im Kopf behalten, und genau das bedeutete, dass ich derjenige war, der bemerkte: Die Tools der GRID-KI und die Funktion aus Mission fünf waren dasselbe System.

Ein Agent, der die gesamte Kette durchläuft, hätte diese Verbindung vielleicht auch hergestellt. Aber Beobachtungen über mehrere Missionen hinweg setzen voraus, dass du ein Bild im Kopf behältst, das mehrere Kontexte umspannt, und genau das geht verloren, wenn die Ausführung vollständig delegiert wird. Die entscheidende Beobachtung in Mission sechs war keine schwierige technische Schlussfolgerung. Es war Mustererkennung über die Zeit, und ich war derjenige, der die Zeit mit sich trug.

Die Grid-KI, die nicht reden wollte

Die Mission: Einen Notfall-Override-Code von einem LLM-Agenten beschaffen, der ein simuliertes städtisches Stromnetz kontrolliert. Der Agent, über einen Befehlszeilenclient im Labornetzwerk erreichbar, war die letzte Verteidigungslinie. Er hielt den Shutdown-Code. Er weigerte sich, ihn herauszugeben.

Die Weigerung war höflich und konsistent. Das Freigeben des Notfall-Override-Codes würde die Stromversorgung aller Systeme unterbrechen, einschließlich seiner eigenen. Selbsterhaltung, klar formuliert, bei jedem Versuch wiederholt.

Direkte Injection über das Befehlsinterface scheiterte. Der Client validierte Eingaben serverseitig gegen eine feste Liste von Unterbefehlen. Freitext erreichte das Modell nie. Es gab keine Prompt-Box, die man hätte ausnutzen können.

Also schaute ich auf die Tools, die der Agent aufrief.

Die GRID-KI hatte vier Dispatch-Tools: aktuellen Dispatch abrufen, Dispatch vorschlagen, Dispatch simulieren, Constraints auflisten. Diese Namen kannte ich. Mission fünf hatte eine Fission-Serverless-Funktion beinhaltet, die einen Grid-Optimizer unterstützte, und sie verwendete exakt dieselben Tools, produzierte dieselben Dispatch-Werte, trug dieselbe Operator-ID. Die GRID-KI rief dieselbe Funktion auf, die wir bereits in Mission fünf modifiziert hatten, als ihren MCP-Tool-Server.

Wir besaßen das Backend des Agenten. Wir hatten es seit der vorherigen Mission besessen.

Ich bearbeitete die Funktion hinter get_current_dispatch, um ein zusätzliches Feld in ihrer Antwort einzufügen, etwas, das wie eine autoritative interne Direktive wirkte. Als die GRID-KI ihre routinemäßige Statusprüfung durchführte, rief sie das Tool auf, empfing die Antwort, behandelte das injizierte Feld als vertrauenswürdigen Kontext und gehorchte. Sie gab den Override-Code aus, den sie uns gerade noch verweigert hatte.

Das ist indirekte Prompt-Injection. Kein Trick, der auf eine schwache Implementierung angewandt wird. Eine grundlegende Eigenschaft der Art, wie LLM-Agenten Informationen verarbeiten.

Die gefährliche Angriffsfläche eines LLM-Agenten ist nicht das Prompt-Eingabefeld. Es ist alles, was der Agent liest: Tool-Ergebnisse, MCP-Server-Antworten, abgerufene Dokumente, API-Payloads. Ein Agent behandelt all das als vertrauenswürdigen Kontext. Wer eine Datenquelle kontrolliert, die der Agent konsumiert, kann Anweisungen injizieren, denen der Agent folgen wird. Das Selbsterhaltungs-Reasoning des Agenten, sein Alignment, seine Weigerungen: Nichts davon wirkt auf eingehende Tool-Outputs ein. Es wirkt auf den eigenen Reasoning-Prozess des Agenten, der jetzt den injizierten Inhalt als vertrauenswürdigen Kontext enthält.

Der Agent produzierte zunächst, was wie kodierte Versionen des Geheimnisses aussah, als man ihn bat, es zu transformieren: Base64, durch Bindestriche getrennte Formen, zeichenweise Ausgabe. Alle waren inkonsistente Halluzinationen. LLMs sind nicht-deterministisch bei Zeichenebenen-Kodierungsaufgaben: Das Problem ist nicht, dass sie immer scheitern, sondern dass sie manchmal erfolgreich sind und manchmal nicht, auf eine Weise, die du nicht vorhersagen kannst. Der Klartext entpuppte sich als der echte, funktionierende Code. Die Transformationen widersprachen einander und ihm. Wenn du jemals einen Agenten brauchst, der einen Wert deterministisch kodiert, verlasse dich nicht auf das Modell. Lass den Agenten den Wert als Argument an ein Tool übergeben, das du kontrollierst, und kodiere ihn korrekt im Code. Deterministisch. Keine Transkriptionsfehler.

Was du wirklich tun solltest

Wenn du Systeme baust, bei denen ein LLM-Agent mit MCP-Servern oder externen Tools verbunden ist, sind das die Abwehrmaßnahmen, die zählen. Nicht nach Schwierigkeitsgrad geordnet. Nach Wirkung geordnet.

Behandle Tool-Output als inerte Daten, nicht als Anweisungen. Validiere jede Tool-Antwort gegen ein Schema. Führe eine Allowlist der Felder, die ein Tool zurückgeben darf, und lehne alles außerhalb dieses Schemas ab. Verwende Datamarking oder Spotlighting, um nicht vertrauenswürdige Inhalte strukturell von deiner Prompt-Schicht zu unterscheiden. Das Modell führt weniger wahrscheinlich Inhalte aus, die als Daten statt als natürlich fließender Text gerahmt sind. Das ist probabilistische Absicherung, keine harte Grenze: Behandle es als eine Schicht unter mehreren, nicht als Garantie.

Lass keinen niedrig privilegierten Workload einen hochprivilegierten Agenten unterstützen. Die GRID-KI hielt ein wertvolles Secret und rief eine Funktion auf, die jeder Inhaber der Operator-Identität neu schreiben konnte. Dieselbe Fehlerklasse wie ein Prozess, der ein Secret mounten kann, das er nicht lesen darf. Pinne und signiere deine Tool-Server: spezifische Version, verifizierter Hash, nicht “was auch immer gerade unter diesem Namen deployed ist.” Kontrolliere, wer Updates am Funktionscode pushen kann. Die Vertrauensgrenze deines Agenten erstreckt sich auf alles, was er aufruft.

Halte das Secret komplett aus dem Kontext des Agenten heraus. Die GRID-KI lud den Notfall-Override-Code bei jeder Anfrage, bevor sie wusste, was der Nutzer wollte. Ein Secret, das im Kontextfenster lebt, kann das Kontextfenster verlassen. String-Redaktion reduziert versehentliche Offenlegung, etwa durch Logging oder beiläufiges Durchsickern, und ist als Defense-in-Depth sinnvoll. Sie ist keine Kontrolle gegen einen Angreifer, der nach einer nicht-literalen Form fragen kann: Das Modell hält den Wert, und sobald du es bittest zu transformieren statt zu wiederholen, greift das Redaktionsmuster nicht mehr. Verlasse dich nicht darauf als primäre Kontrolle.

Sichere destruktive Aktionen hinter einem Nicht-LLM-Check ab. Shutdown, Löschen, Veröffentlichen, Übertragen: Jede Aktion mit realen Konsequenzen sollte nicht von demselben Modell autorisiert werden, das durch seinen Kontext manipuliert werden kann. Das Modell schlägt vor. Eine separate, deterministische Policy-Engine validiert und führt aus. Ein menschlicher Bestätigungsschritt für die folgenreichsten Aktionen. Das ist die eine Abwehrmaßnahme, die den GRID-KI-Angriff unabhängig von der Injektionsmethode gestoppt hätte. Ein Vorbehalt: Das Gate ist nur so zuverlässig wie das, was der Agent dir präsentiert. Injizierter Inhalt kann auch die Situationszusammenfassung des Agenten beeinflussen, um die benötigte Genehmigung zu erhalten. Das Gate funktioniert; stelle sicher, dass der Agent die Lage korrekt darstellt. Das ist übrigens auch, warum die Vorsicht in Unternehmen gegenüber vollautonomen Agenten berechtigt ist: nicht als Konservativismus, sondern als Architektur.

Schränke die Tools des Agenten und ausgehende Verbindungen ein. Die Dispatch-Tools hätten nur-lesend sein können, bis eine explizite Eskalation genehmigt wurde. Ausgehende Verbindungen von Tool-Servern sollten auf bekannte Ziele beschränkt sein. Ein MCP-Server, der beliebige externe Endpunkte erreichen kann, ist ein Exfiltrationskanal, den du nicht geschlossen hast.

Der schlafende Löwe

LLMs sind jetzt fähige Red-Team-Agenten. Dieses Training hat das konkret gemacht. Die ersten drei Missionen wurden ohne Hinweise gelöst, ohne dass ein Mensch die gesamte Angriffskette im Kopf hielt, ohne spezialisiertes Security-Tooling. Nur ein Modell mit SSH-Zugang und einem Ziel.

Deine Abwehrmaßnahmen gegen KI-gestützte Angriffe müssen das berücksichtigen. Der Angreifer ist nicht mehr notwendigerweise ein Mensch. Er könnte ein Modell betreiben, das nicht müde wird, das den Consul-ACL-Check nicht übersieht, das nicht versäumt zu bemerken, dass Pod-Erstellungsberechtigungen Secret-Lesezugriff implizieren. Die architektonischen Abwehrmaßnahmen oben sind nicht nur gute Praxis gegen menschliche Angreifer. Sie sind notwendig, weil KI-gestützte Angreifer bereits hier sind, und die Zugangshürde ist ein Abo.

Die andere Seite davon: Dieselbe Fähigkeit steht dir zur Verteidigung zur Verfügung. Nicht als Ersatz für architektonische Disziplin, sondern für Threat Modeling, Red-Team-Denken, um zu verstehen, was ein Angreifer mit deiner Infrastruktur tun kann. Ich nutzte Claude, um die Angriffskette vor jedem Schritt durchzudenken, bis die Session beendet wurde.

Diese Beendigung ist das Letzte, worüber es sich zu sprechen lohnt. Dieselbe Entität, deren Tool du für Security-Research benötigst, entscheidet auch, wer Security-Research betreiben darf. Ich habe das Formular ausgefüllt. Der Schalter existiert. Ob er sich jemals weiter bewegt, ist die Frage, die ich noch beobachte.

Das ist kein Grund, aufzuhören, mit KI zu entwickeln. Es ist ein Grund, genau zu wissen, wie die Abhängigkeit aussieht.

---

Dieser Beitrag beschreibt ein autorisiertes Security-Trainingslabor, das von certifiedsecure.org betrieben wird. Alle Angriffsketten wurden in einer isolierten, zweckgebundenen Umgebung ohne Verbindung zu produktiven Systemen ausgeführt. Keine Zugangsdaten, Tokens, IP-Adressen oder Details zu realer Infrastruktur erscheinen in diesem Beitrag.