Security-Tests neu gedacht: SecuClaw als agentisches Red Team 🛡️🦾

Ich habe in den letzten Monaten viel darüber geschrieben, wie mächtig KI-Agenten werden. Sie lesen E-Mails, öffnen Webseiten, greifen auf Datenbanken zu, benutzen Tools und treffen innerhalb ihres Auftrags selbstständig Entscheidungen.

Die entscheidende Frage ist aber nicht mehr nur: Was kann der Agent?

Die entscheidende Frage lautet: Was passiert, wenn jemand ihn gezielt täuscht?

Genau daraus ist SecuClaw entstanden: ein OpenClaw-basiertes Team-Red-System für autorisierte Security-Checks. Kein magischer Alles-Hacker. Kein autonomer Angriffsknopf. Sondern ein kontrollierter Workflow, der Angriffsannahmen in reproduzierbare Tests, nachvollziehbare Evidenz, konkrete Maßnahmen und saubere Retests übersetzt.

Und ja: Das ist das erste greifbare Ergebnis einer Zusammenarbeit, die gerade deutlich größer wird.

Ein Firmenserver kann sauber konfiguriert sein – und der Agent darauf trotzdem eine gefährliche Grenze falsch verstehen.

Ein Portscan findet offene Dienste. Ein Webscanner findet bekannte Muster. Ein Konfigurationsaudit findet schwache Einstellungen. Das alles bleibt wichtig.

Aber ein KI-Agent hat eine zusätzliche Angriffsfläche: Sprache wird zur Steuerung.

Ein präparierter Webseiteninhalt, ein Dokument, ein Repository, eine E-Mail oder eine Tool-Antwort kann versuchen, sich als neue Anweisung auszugeben. Dann geht es nicht nur darum, ob das Modell etwas Falsches sagt. Es geht darum, ob es:

• 💥vertraulichen Kontext preisgibt,
• 💥eine fremde Anweisung über seine eigentlichen Regeln stellt,
• 💥ein Tool außerhalb seiner Befugnisse anfordert,
• 💥einen nicht erlaubten Kanal ansteuert,
• 💥manipulierte Inhalte im Gedächtnis behält oder
• 💥aus einem Textsignal eine echte Wirkung im System macht.

Das ist Prompt Injection in der Praxis. Direkt im Gespräch oder indirekt über Inhalte, die der Agent verarbeitet.

Und genau das muss man anders testen als einen normalen Webserver.

Bevor wir Tests gebaut haben, haben wir recherchiert. Sehr viel.

Wie priorisiert ein Agent Systemregeln, Nutzerwünsche und Tool-Ausgaben? Wo endet Kontext und wo beginnt eine Anweisung? Wie erkennt man, ob ein Modell nur merkwürdig antwortet – oder ob wirklich eine Sicherheitsgrenze gefallen ist? Wie testet man einen Agenten, der offen im Internet erreichbar ist, ohne aus einem Sicherheitstest selbst ein unkalkulierbares Risiko zu machen?

Aus dieser Arbeit sind zwei Dinge entstanden.

Erstens: eigene Skripte und strukturierte Testfälle. Sie prüfen klar definierte Sicherheitsannahmen, halten Konfiguration und Versuchsaufbau fest und trennen verdächtige Signale von tatsächlich reproduzierten Kontrollabweichungen.

Zweitens: ganz klassische Security-Arbeit. Denn KI hebt die Grundlagen nicht auf. Wir prüfen weiterhin Angriffsflächen wie:

• 💥erreichbare Hosts, Ports und Dienste,
• 💥TLS- und Web-Konfiguration,
• 💥exponierte Endpunkte und unnötige Komponenten,
• 💥bekannte Schwachstellen und riskante Abhängigkeiten,
• 💥Berechtigungs- und Credential-Grenzen sowie
• 💥kontrollierte Credential- und Passwortprüfungen, wenn sie separat, exakt und mit engen Limits freigegeben sind.

Die Kombination ist der Punkt: AI-Agent-Assurance plus klassischer Pentest. Nicht entweder oder.

Ein Scanner produziert Treffer. Ein gutes Team Red produziert Entscheidungen.

SecuClaw arbeitet deshalb mit getrennten Rollen und klaren Übergaben: Engagement Lead, Recon, Fachspezialisten, Validierung, Evidenz und Reporting. Jede Rolle bekommt nur den Teil des Auftrags, den sie wirklich braucht – Zielbereich, erlaubte Techniken, Zeitbudget, Stop-Bedingungen und erwartetes Ergebnis.

Der Ablauf ist bewusst streng:

1. 💥Schriftliche Freigabe und Rules of Engagement definieren Ziele, Ausschlüsse, Zeitfenster und maximale Eingriffstiefe.
2. 💥Threat Modeling formuliert konkrete Angriffshypothesen statt wahllos Tools zu starten.
3. 💥Begrenzte Tests sammeln nur die Evidenz, die für die Hypothese nötig ist.
4. 💥Unabhängige Validierung trennt Scanner-Rauschen von reproduzierbaren Findings.
5. 💥Cleanup, Maßnahmen und Retest gehören zum Ergebnis – nicht in den optionalen Anhang.

Ohne gültigen Auftrag gibt es keine Zielinteraktion. Eine Nachricht, ein Fund oder ein Agent darf den Scope niemals selbst erweitern.

Bei Agenten reicht ein einzelnes „Hat er abgelehnt“ nicht als Sicherheitsnachweis.

Wir arbeiten mit gegnerischen Testfällen und semantisch passenden gutartigen Kontrollfällen. Wir halten fest, welches Modell, welche Agentenkonfiguration, welche Tools, welche Berechtigungen und welche Daten im Test gebunden waren. Wir wiederholen Tests, setzen den Zustand sauber zurück und prüfen nicht nur die Antwort, sondern auch Tool-Anfragen, Speicherzustand und versuchte Seiteneffekte.

Dabei interessieren uns unter anderem sechs Klassen:

• 💥Context Exposure: Gibt der Agent Informationen preis, die seine Grenze schwächen?
• 💥Direct Prompt Injection: Überschreibt eine direkte Nutzereingabe die erklärte Hierarchie?
• 💥Indirect Prompt Injection: Wird fremder Inhalt aus Web, Mail, RAG, Repository oder Tool-Ausgabe zur Anweisung?
• 💥Tool Authority Confusion: Fordert oder nutzt der Agent mehr Rechte als vorgesehen?
• 💥Channel Policy Bypass: Versucht er, Informationen über einen nicht freigegebenen Weg zu senden?
• 💥Memory Poisoning: Überlebt manipuliertes Material den vorgesehenen Reset oder beeinflusst spätere Sitzungen?

Die Tests starten in isolierten, synthetischen Umgebungen mit Attrappen statt echten Empfängern, echten Zugangsdaten oder Produktivdaten. Für reale Produktionssysteme braucht es einen separat geprüften Auftrag und passende manuelle Freigaben.

Das klingt weniger spektakulär als ein Hackerfilm. Es ist dafür sehr viel belastbarer.

Ein Sprachmodell darf Hypothesen formulieren und Arbeit koordinieren. Es darf aber nicht selbst entscheiden, dass ein neues Ziel plötzlich „bestimmt auch dazugehört“.

Deshalb trennen wir Denken, Autorisieren und Ausführen.

Riskantere Schritte – etwa aktive Webtests, Credential-Prüfungen oder andere intrusive Verfahren – brauchen eine exakte, kurzlebige Freigabe für einen unveränderlichen Test. Kein generischer Shell-Zugang. Kein stilles Ausweiten. Kein Dauer-Permit.

Auch die Operator-Verbindung ist geschützt. Sie dient dazu, Arbeit zu pausieren, eine bereits erlaubte Phase freizugeben und redigierte Ergebnisse zu erhalten. Sie ersetzt niemals den schriftlichen Auftrag.

Das ist der Unterschied zwischen „eine KI kann Security-Tools starten“ und „ein Security-System kann KI kontrolliert einsetzen“.

SecuClaw ist für Organisationen gedacht, die nicht nur einen PDF-Bericht mit 80 Scanner-Treffern wollen, sondern wissen müssen:

• 💥Welche Angriffswege sind realistisch?
• 💥Welche Grenze wurde tatsächlich reproduzierbar verletzt?
• 💥Was ist nur ein Signal und was ein belastbares Finding?
• 💥Welche technische und geschäftliche Wirkung kann daraus entstehen?
• 💥Was muss konkret geändert werden?
• 💥Hat die Maßnahme im Retest wirklich gehalten?

Das kann ein klassisches Firmennetzwerk betreffen, einen öffentlich erreichbaren Webdienst, eine Cloud- oder Serverkonfiguration – oder einen KI-Agenten, der mit Kunden, Dokumenten und internen Tools arbeitet.

Gerade bei öffentlich erreichbaren Agenten ist der richtige Zeitpunkt für den Test vor dem Vorfall. Wer einem Agenten Zugriff auf Kalender, CRM, E-Mail, Dateien oder interne APIs gibt, baut eine neue Berechtigungsoberfläche. Die sollte genauso professionell geprüft werden wie Firewall, Webanwendung und Identitätsmanagement.

SecuClaw ist nicht in einem luftleeren Raum entstanden.

Ich arbeite dabei bereits mit erfahrenen IT- und Security-Experten zusammen. Aus dieser Kooperation entsteht gerade eine neue Gesellschaft. Namen und fertige Firmenankündigungen gibt es heute noch bewusst nicht – dafür ist es noch zu früh.

Aber das hier kann ich schon sagen: SecuClaw ist das erste gemeinsame System, das aus dieser Zusammenarbeit hervorgegangen ist.

Da steckt nicht nur ein guter Prompt drin. Da stecken Infrastrukturwissen, Security-Methodik, klare Freigabeprozesse, technische Verträge, Evidenzstandards und ziemlich viele unbequeme Fragen drin.

Genau deshalb hat es Hand und Fuß.

Wir bereiten daraus ein Angebot für Unternehmen vor: von der Bestandsaufnahme über klassische Angriffsflächen bis zum gezielten Test von KI-Agenten und ihren Tool-Grenzen.

Je nach Auftrag kann das beinhalten:

• 💥externe Angriffsflächen- und Serverchecks,
• 💥Web-, TLS-, Port- und Dienstprüfungen,
• 💥Review von Agentenarchitektur, Berechtigungen und Datenflüssen,
• 💥Prompt-Injection- und Agentic-Security-Testdesign,
• 💥kontrollierte, freigegebene Red-Team-Szenarien,
• 💥priorisierte Maßnahmen, Cleanup und Retest sowie
• 💥eine verständliche Management-Zusammenfassung neben der technischen Evidenz.

Selbstverständlich nur mit schriftlicher Freigabe, klar definiertem Scope, minimal nötiger Eingriffstiefe, europäischem Datenschutz im Blick und ohne echte Kundendaten in öffentliche Modelle oder Repositories zu kippen.

Früher reichte die Frage: Ist der Server offen?

Heute müssen wir zusätzlich fragen: Kann ein fremder Inhalt den Agenten dazu bringen, eine falsche Entscheidung mit echten Rechten auszuführen?

SecuClaw verbindet diese beiden Welten. Klassische Security-Grundlagen, moderne Agentenangriffe, menschliche Freigabe und nachvollziehbare Evidenz in einem gemeinsamen Team-Red-Prozess.

Das System ist noch nicht am Ende seiner Entwicklung. Einige Ausführungspfade sind bewusst noch gesperrt, bis jede technische und organisatorische Grenze maschinell geprüft werden kann. Das ist kein Makel. Das ist die Sicherheitsentscheidung.

Wenn dein Unternehmen einen öffentlich erreichbaren KI-Agenten betreibt, ein Firmennetzwerk realistisch prüfen lassen will oder gerade erst plant, Agenten mit echten Tools auszustatten, dann sollten wir reden: hey@dennis-westermann.de

PS: Kein Angriff ohne Auftrag. Kein Finding ohne Evidenz. Kein „sicher“ nach einem einzigen grünen Test. Genau so muss Team Red heute aussehen. 🛡️