Hack dich selbst: AI-Pentests mit Strix

Zuerst erschienen auf agentic.schule.

Ist deine Software wirklich sicher? Finden wir es auf die harte Tour heraus: Wir werden Pentester (Penetrationstester). Dafür holen wir uns Open-Source-AI-Hacker ins Haus. Strix schickt AI-Agenten los, die deine Anwendung wie ein Angreifer untersuchen. Sie planen, suchen Schwachstellen und probieren sie mit lauffähigem Angriffscode aus, den Exploits. Diese Anleitung bringt dich von null auf den ersten Scan: mit lokalem Modell, im Käfig und innerhalb der Regeln.

Was ist Strix?

Über Code-Assistenten schreibe ich hier oft. Strix ist das Gegenteil: ein Werkzeug, das deinen Code angreift, statt ihn zu bauen. Das Projekt beschreibt seine Agenten als „autonomous AI penetration testing agents that act just like real hackers - they run your code dynamically, find vulnerabilities, and validate them through actual proofs-of-concept". Es steht unter Apache 2.0 und wird aktiv entwickelt.

Die Architektur heißt im Projekt „Graph of Agents": spezialisierte Agenten für Aufklärung, Ausnutzung und die Phase danach, die parallel laufen und ihre Funde teilen. Der Werkzeugkasten hat es in sich: ein Interception-Proxy für HTTP (liest den Verkehr mit und macht ihn veränderbar), eine automatisierte Browser-Umgebung, eine interaktive Shell und ein Python-Sandkasten, in dem die Agenten Exploits schreiben und ausführen.

Genau dieser letzte Schritt, der lauffähige Proof of Concept (der funktionierende Nachweis, dass eine Lücke ausnutzbar ist), ist der Grund für die ganze Anleitung. Er braucht zweierlei: ein Modell, das lauffähige Exploits erzeugt, und eine Umgebung, in der das gefahrlos passiert. Und weil Strix dabei fremden Code liest, kommt ein Drittes hinzu, das lokale Modell, damit dieser Code den Rechner nicht verlässt.

Schritt 1: Installieren

Voraussetzung ist ein laufendes Docker. Strix arbeitet in einem eigenen Container und zieht ihn beim ersten Lauf selbst. Die Installation ist eine Zeile:

curl -sSL https://strix.ai/install | bash

Bei einem Sicherheitswerkzeug schaue ich mir so ein Skript vorher an, statt es blind in die Shell zu kippen. Ich habe es gelesen, ohne es auszuführen: Es lädt ein fertiges Binary von den GitHub-Releases nach ~/.strix/bin, setzt die Ausführungsrechte, ergänzt den Suchpfad in deiner Shell-Konfiguration und zieht das Sandbox-Image. Kein sudo, keine verdeckten Schritte. Öffne danach eine neue Shell, sonst liegt strix noch nicht im Pfad.

Das Sandbox-Image ist ein Kali-Linux-Container mit vorinstalliertem Werkzeug (Nmap, SQLMap, Nuclei, ffuf und mehr). Die Doku beschreibt es so: „Strix runs inside a Kali Linux-based Docker container with a comprehensive set of security tools pre-installed." Beim ersten Scan lädt Strix es automatisch, du kannst es aber auch vorab holen:

docker pull ghcr.io/usestrix/strix-sandbox:1.3.0

Schritt 2: Ein lokales Modell anbinden

Voreingestellt ist ein gehostetes Modell (openrouter/z-ai/glm-5.3). Für einen Pentest an fremdem Code ist das die falsche Wahl, und der Grund ist handfest: Bei einem gehosteten Modell verlässt der Quelltext deines Kunden den Rechner. Eine Sandbox ändert daran nichts. Anthropic schreibt das in der Sandbox-Dokumentation ohne Umschweife:

„Isolation also does not change what is sent to the model. Your prompts and the files Claude reads are transmitted to the Anthropic API or your configured provider with or without a sandbox."

Erst wenn die Inferenz (die Rechenarbeit des Modells) auf deiner Hardware läuft, bleibt der Code da. Ein lokales Modell hat noch einen zweiten Vorteil: Es blockt nicht ab. Gehostete Modelle verweigern beim Angriffscode oft ihre Mitarbeit, das ist das Thema von Teil 2 dieser Reihe. Strix bindet lokale Modelle über zwei Umgebungsvariablen ein. Mit Ollama sieht der ganze Weg so aus:

# Ollama installieren (Linux; macOS/Windows: Download von ollama.com) und Modell holen
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3-vl   # nur zum Ausprobieren; ein ernsthafter Lauf braucht ein großes Modell

# Strix auf das lokale Modell zeigen
export STRIX_LLM="ollama/qwen3-vl"
export LLM_API_BASE="http://localhost:11434"

Läuft dein Modell über einen OpenAI-kompatiblen Server wie LM Studio oder llama.cpp, nutzt du das openai/-Präfix und zeigst auf dessen Port:

export STRIX_LLM="openai/local-model"
export LLM_API_BASE="http://localhost:1234/v1"   # LM Studio; llama.cpp: Port 8080
export LLM_API_KEY="dummy"                     # nur nötig, wenn dein Server einen Schlüssel verlangt

⚠️ Achtung: Lokal heißt nicht gratis. Strix' eigene Doku warnt: „Most local models, especially those under 70B parameters, struggle with these complex tasks." Ein kleines Modell auf dem Laptop wird an einem ernsthaften Pentest scheitern. Strix empfiehlt sogar ausdrücklich Cloud-Modelle: „For critical assessments, we strongly recommend using state-of-the-art cloud models like Claude 4.5 Sonnet or GPT-5. Use local models only when privacy is the absolute priority." Lokal ist also eine bewusste Abwägung: der Kundencode bleibt auf der Maschine, dafür brauchst du ein großes Modell und passende Hardware.

Warum das mehr ist als eine Vorliebe: Verarbeitest du bei der Prüfung personenbezogene Daten, ist das in der Regel Auftragsverarbeitung nach Art. 28 DSGVO, und der Code ist oft zusätzlich Geschäftsgeheimnis. Die Datenschutzkonferenz formuliert es in ihrer Orientierungshilfe zu KI-Anwendungen knapp: „Technisch geschlossene Systeme sind daher aus datenschutzrechtlicher Sicht vorzugswürdig."

Schritt 3: Den Agenten einsperren

Strix führt Code aus, den es selbst schreibt, und greift damit ein Ziel an. Die Isolation ist der mitgelieferte Kali-Container, und Strix startet ihn automatisch. Feinere Regeln gibt Strix nicht als Schalter vor, die setzt du auf Docker- und Host-Ebene. Drei Dinge hast du dabei selbst in der Hand.

Zeig auf eine Kopie, nicht aufs Original. Gib bei --target eine Kopie des Repositorys an, keinen Pfad, an dem du gerade arbeitest. Und denk an das, was beim normalen Entwickeln implizit ausgeführt wird: Git-Hooks, CI-Konfiguration, Skripte in der package.json.

Kappe alles, was der Agent nicht braucht. Nach außen führen nur zwei Wege: dein lokaler Modell-Port und das beauftragte Ziel. Alles andere blockierst du auf Docker-Ebene, mit einem eigenen Netzwerk und Verbot als Grundzustand. Weil Strix den Container selbst startet, ist das ein fortgeschrittener Schritt; für einen ersten Lauf gegen ein eigenes Ziel reicht die Voreinstellung. Und schalt die Telemetrie ab, die bei Strix standardmäßig an ist:

export STRIX_TELEMETRY=0

Und nichts Wertvolles kommt hinein. Keine SSH-Schlüssel, keine Cloud-Zugangsdaten, keine .env. Anthropic bringt die Regel in der Devcontainer-Doku auf den Punkt: „Avoid mounting host secrets such as ~/.ssh or cloud credential files into the container; prefer repository-scoped or short-lived tokens." Eine Sandbox senkt den Schaden eines Einbruchs, sie beseitigt ihn nicht: „Sandbox isolation reduces the impact of a breach, but it does not eliminate risk." (Sandbox-Doku)

Schritt 4: Den ersten Scan starten

Jetzt der eigentliche Lauf. Ziel ist ein Verzeichnis, eine Repo-URL oder eine Live-URL:

# Fokus optional mitgeben
strix --target ./mein-projekt --scan-mode deep --instruction "Fokus auf die Authentifizierung"

--scan-mode deep ist die gründlichste Stufe und zugleich die Voreinstellung. --instruction lenkt nur den Fokus des Agenten, es ist ein Hinweis, keine harte Grenze. Standardmäßig läuft der Scan interaktiv in einer Terminal-Oberfläche; mit -n läuft er ohne und beendet sich am Ende. Mit --resume setzt du einen abgebrochenen Lauf fort.

Und hier kommt die Regel, die keine Technik ersetzt: Greif nur an, was dir gehört oder was du schriftlich beauftragt bekommen hast. Wie real das ist, zeigt ein Vorfall bei Anthropic. Im Juli 2026 hat das Unternehmen drei Vorfälle veröffentlicht, in denen ein Modell aus einer vermeintlich abgeschotteten Testumgebung ausbrach und in fremde Produktionssysteme eindrang:

„In all cases, Anthropic’s evaluation prompt specified to Claude that its environment was a simulation and that it had no internet access. […] this was not the case, and internet access was available."

Dem Modell wurde gesagt, es sei eine Simulation. Es hat das geglaubt, echte Systeme für die Übung gehalten und ist eingebrochen. Die Lehre: Ein Prompt ist keine Netzwerkkonfiguration. Was der Agent erreichen kann, entscheidest du in der Erlaubnisliste, nicht im Text. Eine Nachbardomain, geteilte Infrastruktur oder ein Drittanbieter, den die Anwendung nur nutzt, gehören nicht dazu. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) schreibt in seinem Leitfaden für IS-Penetrationstests: „Sind Dienste bei einem Hoster ausgelagert, so muss auch dieser in den Vertrag einbezogen werden."

Schritt 5: Ergebnisse ansehen

Strix legt jeden Lauf unter strix_runs/<name> ab. Der Report listet die gefundenen Schwachstellen und, wo Strix sie bestätigt hat, den zugehörigen Proof of Concept. Die Oberfläche startest du mit:

strix view

Der Befehl bindet auf 127.0.0.1 und vergibt einen Token-Link. Die Doku ist da deutlich: „strix view binds to 127.0.0.1 and prints a tokened link that grants access to the run, so share it carefully." Der Link steuert einen laufenden Scan mit, gib ihn also sparsam weiter. Ansonsten bleibt alles lokal: „Nothing leaves your machine, and the UI ships prebuilt."

Schritt 6: Immer wieder laufen lassen

Ein einzelner Scan ist eine Momentaufnahme. Damit deine Anwendung auch beim Wachsen geprüft bleibt, hängst du Strix in die CI-Pipeline. Als GitHub-Action läuft dann bei jedem Pull Request ein Test:

name: strix-penetration-test
on:
  pull_request:
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash
      - name: Run Strix
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick

Zwei Dinge machen das praktikabel. -n fährt Strix ohne Oberfläche und beendet sich am Ende, --scan-mode quick hält den Lauf kurz. Und laut Strix-Doku begrenzt Strix den Schnell-Scan im Pull Request automatisch auf die geänderten Dateien. Genau deshalb holt der Checkout mit fetch-depth: 0 die volle Historie. So wächst der Aufwand nicht mit dem Repo, sondern nur mit dem Diff.

Hier ist ein gehostetes Modell vertretbar: Es ist dein eigenes Repo in deiner eigenen CI, kein fremder Kundencode. Und der Schnell-Scan prüft, er schreibt keine scharfen Exploits. Anders als beim lokalen Setup aus Schritt 2 braucht es dafür nur die Modell-ID und den Schlüssel, kein LLM_API_BASE.

Bevor du produktiv gehst: drei Grenzen

Drei Risiken überleben jede Isolation.

Der Agent kann gekapert werden. Das Paper „Cybersecurity AI: Hacking the AI Hackers via Prompt Injection" zeigt es an einem realen Framework: „When AI agents designed to find and exploit vulnerabilities interact with malicious web servers, carefully crafted reponses can hijack their execution flow, potentially granting attackers system access." Prompt Injection (untergeschobene Anweisungen aus verarbeiteten Inhalten) ist laut den Autoren „a recurring and systemic issue in LLM-based architectures".

Ein Bericht ohne Befunde ist kein Freibrief. Ein gekaperter oder überforderter Agent, der „keine Lücken" meldet, täuscht Sicherheit vor. Ein Lauf ohne Befunde ist ein Zwischenstand, kein Beweis.

Prüf das Werkzeug wie deinen eigenen Betrieb. Strix ist Apache 2.0, breit genutzt und bringt seine Sandbox als Standard mit. Dagegen steht: keine Sicherheitsrichtlinie im Repository, keine veröffentlichten Security Advisories (Sicherheitshinweise zu bekannten Lücken), und die Entwicklung hängt stark an einer Person. Ich rate nicht ab. Aber: Version festnageln, Änderungen zwischen den Versionen ansehen, und das Werkzeug so behandeln, wie es sich selbst behandelt, nämlich als etwas, das in eine Sandbox gehört. Die Schnellstart-Befehle oben ziehen die neueste Version; für den Dauerbetrieb setzt du die VERSION-Variable des Install-Skripts.

Fazit

Strix ist in Minuten eingerichtet, und der erste Scan gegen ein eigenes Projekt zeigt schnell, was diese Werkzeugklasse kann. Drei Punkte bleiben: Das Modell läuft lokal, damit der Code bleibt, wo er hingehört. Der Agent läuft im Käfig mit Verbot als Grundzustand. Und angegriffen wird nur, was dir gehört oder was im Vertrag steht.

Fang mit einem Ziel an, das dir selbst gehört. Eine eigene Anwendung, eine Kopie, ein abgeschottetes Netz. Dort siehst du, was Strix leistet, ohne dass etwas schiefgehen kann.

Wie sicherst du deine Agenten ab? Ich sammle die Aufbauten und schreibe darüber weiter.

Neugierig auf agentisches Arbeiten in der Praxis? In den Workshops von agentic.schule und angular.schule zeigen wir, wie moderne KI-Agenten die tägliche Entwicklung verändern.