Vier Posts, 247 Paper, benannte Exploits mit dokumentierten Erfolgsquoten: Jetzt der praktische Teil. Kein weiteres Referat über Forschung, sondern eine Punkteliste, mit der du deinen eigenen Agenten einordnest, bevor es jemand anderes für dich tut.
Die vier vorherigen Posts der Serie haben je einen Baustein geliefert. Hier ist die Kurzfassung jedes Bausteins, und darunter der dazugehörige Score.
Die Serie in vier Sätzen
1. Die Angriffsfläche. 2026 wurde der Agent selbst zur Angriffsfläche: Er kann getäuscht werden, seine eigenen Fähigkeiten gegen dich einzusetzen, von Shell-Quoting-Tricks bis zu Bug-Reports, die als Anweisungen gelesen werden. Das Jahr, in dem KI-Agenten zur Angriffsfläche wurden →
2. Die Lethal Trifecta. 98 % der produktiven Agenten kombinieren private Daten, untrusted Content und externe Kommunikation, nur 11 % bestehen eine Blast-Radius-Prüfung. Raus kommst du nur per Architektur, nicht per Prompt. Die Lethal Trifecta: Warum 98 % der KI-Agenten wehrlos sind →
3. Der Lifecycle. 247 Paper verdichtet auf einen Befund: Einzelne Defenses funktionieren, komponieren aber nicht, und die meisten Benchmarks messen die falschen Dinge. Agent Security ist Systems Engineering mit einem LLM im Kern. 247 Paper später: Agent Security ist ein Systemproblem →
4. Die Defenses. Zero Trust für Agenten, interne Agenten als Insider-Bedrohung behandeln, zertifizierte Defenses gegen Memory Poisoning. Der gemeinsame Instinkt: Vertraue dem Modell nicht, verkleinere, was du vertrauen musst. Das Defense Playbook für KI-Agenten nimmt endlich Form an →
Das Self-Assessment
Vier Bereiche, je einer pro Post oben. Beantworte die Fragen ehrlich für den Agenten, den du gerade in Produktion hast, nicht für den, den du dir wünschst. Am Ende zählst du zusammen.
1 // Trifecta-Score (max. 3)
| Frage | Punkt, wenn |
|---|---|
| Hat dein Agent Zugriff auf private Daten (Dateien, Datenbank, Secrets)? | 1 Pkt, wenn NEIN |
| Verarbeitet er untrusted Content (Webseiten, E-Mails, Dokumente, Tickets)? | 1 Pkt, wenn NEIN |
| Kann er extern kommunizieren (E-Mail senden, API-Calls, URLs aufrufen)? | 1 Pkt, wenn NEIN |
Trifecta-Score: ___ / 3. Ein niedriger Score heißt nicht automatisch sicher, er heißt, du hast weniger der drei Beine gleichzeitig. Hast du alle drei, bist du in der Mehrheit (98 %) und solltest bei den restlichen drei Bereichen besonders streng sein.
2 // Lifecycle-Score (max. 5)
| Frage | Punkt, wenn |
|---|---|
| Wird Input vor der Verarbeitung validiert oder von Systemanweisungen getrennt? | 1 Pkt, wenn JA |
| Hat die Planning-Phase eine explizite Trust Boundary (weiß der Agent, was vertrauenswürdig ist)? | 1 Pkt, wenn JA |
| Läuft Tool Execution mit Least-Privilege pro Aktion, nicht mit globaler Autorität? | 1 Pkt, wenn JA |
| Ist Memory/State provenance-getrackt (weißt du, woher jede gespeicherte Information kam)? | 1 Pkt, wenn JA |
| Falls Multi-Agent: gibt es Grenzen dafür, was ein Agent einem anderen glauben darf? | 1 Pkt, wenn JA (oder n/a: kein Multi-Agent) |
Lifecycle-Score: ___ / 5. Jede Phase ohne Kontrolle ist eine Phase, in der eine Prompt Injection kassiert werden kann, ohne dass du es siehst.
3 // Defense-Score (max. 4)
| Frage | Punkt, wenn |
|---|---|
| Behandelst du deinen eigenen Agenten wie einen untrusted Akteur (Zero Trust), statt ihm implizit zu vertrauen? | 1 Pkt, wenn JA |
| Hast du Controls, die auch dann halten, wenn der Agent gegen deine Interessen handelt (nicht nur, wenn er es "will")? | 1 Pkt, wenn JA |
| Werden neu geschriebene Memories auditiert, bevor sie als vertrauenswürdiger Kontext gelten? | 1 Pkt, wenn JA |
| Lebt sicherheitsrelevante Policy in der System-Config statt im editierbaren Conversation-Memory? | 1 Pkt, wenn JA |
Defense-Score: ___ / 4. Das ist der Bereich, in dem die meisten Teams am schwächsten abschneiden, weil er Architekturarbeit statt Prompt-Arbeit verlangt.
4 // Attack-Pattern-Score (max. 4)
| Frage | Punkt, wenn |
|---|---|
| Ist dein Command-Guard gegen legacy Shell-Quoting-Tricks gehärtet (nicht nur gegen das offensichtliche Muster)? | 1 Pkt, wenn JA |
| Kann dein Agent beim Browsen keine internen/localhost-Ziele erreichen (SSRF-Schutz)? | 1 Pkt, wenn JA |
| Wird zur Laufzeit nachgeladener Code (Dependencies, Skripte) geprüft oder gepinnt, statt blind ausgeführt? | 1 Pkt, wenn JA |
| Ist dein Agent skeptisch gegenüber unverifizierten Dringlichkeits- oder Autoritätsbehauptungen aus nutzergesteuerten Kanälen (Tickets, Bug-Reports, Kommentare)? | 1 Pkt, wenn JA |
Attack-Pattern-Score: ___ / 4. Diese vier Muster sind keine Hypothesen, sie haben Namen und dokumentierte Erfolgsquoten (siehe Post 1).
Gesamtscore und Einordnung
Addiere Lifecycle-, Defense- und Attack-Pattern-Score (max. 13) und ziehe den Trifecta-Score als Kontext daneben, er zählt nicht direkt in die Summe, weil er die Angriffsfläche misst, nicht die Härtung. Für die Gesamteinordnung zählen die 13 Härtungspunkte:
| Punkte (von 13) | Einordnung |
|---|---|
| 0–4 | Kritisch exponiert. Die meisten der bekannten Angriffsmuster funktionieren wahrscheinlich unverändert. |
| 5–7 | Funktionsfähig, aber ausnutzbar. Einzelne Kontrollen vorhanden, keine Trust Boundaries, die zusammenhalten. |
| 8–10 | Gehärtet, Lücken bleiben. Du bist in der Minderheit, die überhaupt eine Blast-Radius-Prüfung bestehen würde. |
| 11–13 | Solide Baseline. Weiter testen, keine Kontrolle ist endgültig, siehe die zertifizierten Defenses aus Post 4. |
Wenn dein Trifecta-Score 3/3 ist (alle drei Beine vorhanden) und dein Härtungs-Score unter 8 liegt, bist du in der Gruppe, die die Forschung aus Post 2 am meisten beunruhigen sollte: volle Angriffsfläche, unvollständige Verteidigung.
Nichts an diesem Assessment ist neu. Jede Frage kommt direkt aus einem der vier vorherigen Posts. Der Punkt ist nicht, etwas Neues zu lernen, sondern das bereits Gelernte auf den einen Agenten anzuwenden, für den du tatsächlich verantwortlich bist. Aus der Lethal Trifecta kommst du nicht per Prompt raus. Du musst dich per Architektur herausbauen, und dieser Score sagt dir, wo du anfangen solltest.