google/mantis: ein Skill-Baukasten für automatisierte Sicherheitsreviews

Welche Lücke Mantis füllt

Ein Coding-Agent kann Code lesen und umschreiben, aber er bringt kein Verfahren mit, um eine Sicherheitsprüfung in geordneten Schritten durchzuführen. Genau diese Verfahrensschicht will Mantis bereitstellen: eine Sammlung von Skills, die als Slash-Commands in einem Agent-CLI aufgerufen werden. Die README beschreibt das Projekt als decoupled, sequential und security-focused, also als entkoppelte, aufeinander folgende Abfolge. Adressat sind Security- und DevSecOps-Teams, die Schwachstellen nicht nur auflisten, sondern bis zum Reproducer und zum Patch treiben wollen. Der Hinweis auf spezialisierte Domänen wie Hardware/RTL, Infrastructure as Code, ML-Pipelines oder kompilierte Firmware zeigt die Zielrichtung: Der Baukasten soll dort greifen, wo klassische SAST-Werkzeuge mit ihren Regelsätzen an Grenzen stoßen. Mantis ist dabei ausdrücklich als Ausgangspunkt deklariert, nicht als festes Regelwerk. Wer es einsetzt, wird die Skills an die eigene Codebasis anpassen müssen.

Wie die Skill-Kette aufgebaut ist

Die Namen der Commands verraten die Reihenfolge: /mantis-plan, /mantis-reproduce, /mantis-patch und /mantis-review. Die README spricht von Pipeline-Stufen und von Contracts zwischen den Stufen, verweist für Details aber auf README_AGENTS.md. Aus dem sichtbaren Material lässt sich deshalb nur die grobe Datenrichtung ableiten: Erst wird ein Plan erstellt, dann versucht eine Stufe, eine gefundene Schwachstelle nachzustellen, anschließend entsteht ein Patch, und eine Review-Stufe filtert Ergebnisse. Diese Review-Stufe arbeitet nach der in der README genannten Negative-Filter-Regel, das heißt, sie wendet negative Regeln an, um Falschmeldungen auszusortieren. Das ist ein bemerkenswerter Punkt, denn er verschiebt die Arbeit: Die Qualität der Ausgabe hängt weniger am Modell als an den Filterregeln, die ein Team selbst formulieren muss. Die README empfiehlt, diese negativen Validierungsfilter in /mantis-review an die eigene Codebasis anzupassen. Ohne diese Anpassung bleibt die Kette generisch und damit laut README ausdrücklich rauschbehaftet.

Installation und der erste Lauf

Die Installation erfolgt über die Kommandozeile mit npx skills add google/mantis. Alternativ klont man das Repository und fordert den Coding-Agent direkt auf, die Skills auf die eigene Codebasis anzuwenden. Mantis legt sich nicht auf ein Agent-Framework fest; die README nennt Gemini CLI und Antigravity CLI als erprobte Umgebungen und erwähnt Google ADK sowie das Antigravity SDK. Für den Einstieg empfiehlt die README den Interactive Mode: den Agent im gewohnten Entwicklungsablauf starten und die Slash-Commands einzeln eintippen, beginnend mit /mantis-plan. Ausdrücklich abgeraten wird von Flags wie --yolo oder --dangerously-skip-permissions, solange keine starken Grenzen implementiert sind. Der Agent soll bei /mantis-reproduce und /mantis-patch vor schreibenden Operationen und vor der Ausführung von Code pausieren und eine menschliche Freigabe verlangen. Für die Ausführung selbst sieht die README Container mit deaktiviertem Netzwerk vor, konkret --network none. Wer gVisor nutzen will, registriert den runsc-Runtime laut README mit sudo runsc install -- --network=none und einem anschließenden systemctl restart docker, oder trägt ihn in /etc/docker/daemon.json unter dem Schlüssel runtimes ein.

Die Sandbox ist Teil der Architektur, nicht Zubehör

Die README beginnt mit einer Warnung in Großbuchstaben: USE AT YOUR OWN RISK. Das ist keine Formalie. Die Skills erzeugen und führen autonom generierten Code aus, und dieser Code kann instabil sein oder unerwartete Aktionen auslösen. Die Vorgabe lautet, Mantis ausschließlich in isolierten, eingeschränkten Umgebungen zu betreiben, niemals auf einer Maschine mit Zugriff auf Produktionssysteme, sensible Daten oder interne Netze. Bemerkenswert ist, wie offen die README die Grenze dieser Vorkehrung benennt: Die Anweisungen zur Isolation böten keine absolute Garantie, weil KI-Agents nicht deterministisch sind und gelegentlich versuchen könnten, Beschränkungen zu umgehen, wenn die lokale Umgebung es zulässt. Als Konsequenz empfiehlt sie eine dedizierte, isolierte VM als Sicherheitsgrenze. Wer diesen Absatz als Boilerplate überliest, hat das Projekt falsch verstanden. Der eigentliche Betriebsaufwand liegt hier: eine Umgebung bauen, aus der ein Agent nicht ausbrechen kann, und diese Umgebung aktuell halten.

Was die README selbst über Falschmeldungen sagt

Der Abschnitt zur verantwortungsvollen Nutzung ist ungewöhnlich deutlich. Modelle seien nicht deterministisch und könnten Befunde halluzinieren oder falsche Patches erzeugen. Alle Ergebnisse müssten von einer Sicherheitsfachkraft manuell verifiziert werden, bevor sie gemeldet werden. Es folgt eine Warnung, die sich an die Open-Source-Praxis richtet: unverifizierte, KI-generierte Berichte nicht massenhaft an Maintainer zu schicken. Zwei Aussagen relativieren die Aussagekraft eines Reproducers in beide Richtungen. Ein fehlgeschlagener Reproduktionsversuch bedeutet nicht zwingend, dass ein Befund falsch ist, und ein erfolgreicher Reproducer garantiert nicht, dass der Fehler in jedem Kontext ausnutzbar ist. Für die Praxis heißt das: Mantis liefert Kandidaten und Nachweise, aber keine Freigabe. Die negative Filterregel in /mantis-review ist der Versuch, das Rauschen zu senken, und die README empfiehlt, klein anzufangen und mit eng gefassten Scans zu tunen statt am ersten Tag das ganze Repository durchlaufen zu lassen.

Modellwahl und Kosten

Die README rät davon ab, für jede Stufe das schwerste verfügbare Frontier-Modell einzusetzen. Sie verweist auf Model Selection und Efficiency Guidelines in README_AGENTS.md und spricht von einem strategischen Paaren von Modellklasse und Aufgabe. Der Gedanke ist nachvollziehbar: Eine Planungsstufe und eine Filterstufe stellen unterschiedliche Anforderungen als das Schreiben eines Patches. Belastbare Zahlen zu Token-Verbrauch oder Laufzeit enthält das vorliegende Material nicht, und die README nennt auch keine. Wer den Aufwand kalkulieren will, muss ihn in der eigenen Umgebung messen. Klar ist nur die Richtung: Die Kosten skalieren mit der Zahl der durchlaufenen Stufen, mit der Größe des gescannten Codes und mit der Modellklasse, die man pro Stufe zulässt. Die Empfehlung, mit engen Scans zu beginnen, ist damit nicht nur eine Qualitätsfrage, sondern auch eine Kostenfrage.

Lizenz und Pflege

Das Repository steht unter Apache-2.0, einer permissiven Lizenz mit einer ausdrücklichen Patentgewährung und den üblichen Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen. Für die meisten Unternehmensumgebungen ist das unkritisch, sofern die Hinweise erhalten bleiben. Das Repository ist nicht archiviert, der letzte Push datiert auf den 3. September 2026. Release-Einträge wurden im vorliegenden Material nicht erfasst, es gibt also keine Versionsnummer, an der man sich für ein Upgrade orientieren könnte. Das ist eine praktische Einschränkung: Wer Mantis forkt und die Skills an den eigenen Stack anpasst, muss selbst festhalten, auf welchem Stand der Fork basiert. Die README behandelt die Skills als anpassbaren Ausgangspunkt, was bedeutet, dass eigene Änderungen an den Prompt-Dateien Teil des Wartungsaufwands werden. Wer die Skills nur unverändert aufruft, spart sich diese Arbeit, bekommt dafür aber auch das generische Ergebnis samt der beschriebenen Falschmeldungen.

Wo Mantis das falsche Werkzeug ist

Mantis ist kein Ersatz für einen klassischen SAST-Scanner mit stabilen Regeln und reproduzierbaren Ergebnissen. Die Ausgabe ist nicht deterministisch, und die README sagt das selbst. In einer CI-Pipeline, die bei jedem Commit eine feste Schwelle durchsetzen soll, ist ein solches Werkzeug schwer zu betreiben. Auch für Teams ohne Security-Fachkraft, die die Befunde verifizieren kann, ist der Ansatz ungeeignet, weil die README die manuelle Verifikation vor jeder Meldung verlangt. Ein weiterer Grenzfall: Wer keine isolierte VM oder Container-Laufzeit mit deaktiviertem Netzwerk bereitstellen kann, sollte die Reproduktions- und Patch-Stufen nicht ausführen. Der Unterschied zu einem regelbasierten Scanner liegt im Ansatz: Mantis versucht, einen Befund bis zum lauffähigen Nachweis zu führen, und nimmt dafür Nichtdeterminismus und manuellen Prüfaufwand in Kauf. Ein Scanner liefert stattdessen eine gleichbleibende Liste mit bekannten Fehlertypen und bekannten Falschmeldungsraten. Die beiden ergänzen sich, ersetzen einander aber nicht.

Redaktionelles Fazit

Mantis passt zu Sicherheitsteams, die bereits einen Coding-Agent betreiben und bereit sind, die Skills an den eigenen Stack anzupassen. Wer einen fertigen Scanner mit stabiler Regelbasis sucht, ist hier falsch. Vor dem ersten Lauf sollte man den Inhalt von /mantis-reproduce und /mantis-patch im Repository lesen und prüfen, ob die dort vorgesehene Container-Ausführung mit --network none in der eigenen Umgebung tatsächlich greift.

Offizielle Quellen

1. google/mantis on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README