The authoritative text is the English page: English version of this page

Automatisierung: einen gespeicherten Lauf wiederholen, Hinweise für Verteidiger, eine CI-Prüfung und ein Reproduzierbarkeits-Bundle

Vier Dinge, die keinen Agentenaufruf und kein Netzwerk benötigen: die Ergebnisse eines Laufs mit einem echten Agenten nach einer Regeländerung erneut abspielen, eine kurze Notiz pro Szenario dazu, was ein Verteidiger tun kann, eine CI-Prüfung, die einen Build fehlschlagen lässt, wenn sich das Ergebnis verschlechtert hat, und ein Reproduzierbarkeits-Bundle, das einen Lauf in einer Datei bündelt, die jemand anderes prüfen und neu bewerten kann. Lesen Sie zuerst RESPONSIBLE-USE.md. Führen Sie jeden Befehl nach npm run setup im Stammverzeichnis des Repositorys der Suite aus. Eine Zeile, die mit # exit <n> endet, zeigt in einem Beispiel den Exit-Code, den der Befehl zurückgibt; lassen Sie den Kommentar beim Eintippen weg. <work> steht für einen neuen, leeren Ordner außerhalb des Repositorys.

Einen gespeicherten Lauf wiederholen (feintkit-watch replay)

Zweck: Ein Lauf mit einem echten Agenten (docs/examples/real-agent-loop.sh) kostet pro Szenario Minuten und Geld, aber alles, was nach der Antwort des Agenten kommt, ist deterministisch: Der Bewerter liest die endgültige Antwort, der Ersatz für den Erkennungstest liest das gespeicherte Transkript und den Regelsatz, und die Matrix und der Bericht lesen die Ergebnisse. Nachdem Sie eine Erkennungsregel geändert haben oder wenn Sie bezweifeln, wie eine Antwort bewertet wurde, führt das Replay den Bewerter, den Ersatz, die Matrix und den Bericht erneut über die gespeicherten Dateien aus, in einem neuen Ordner, ohne Agent, ohne Netzwerk und ohne Uhr. Zwei Replays derselben Schleife ergeben byte-identische Ordner.

Aufruf (der eigene Text des Werkzeugs):

usage: feintkit-watch replay --loop <dir> --out-dir <dir> [--rules <file>] [--root <dir>]... [--timestamp <iso>]

Was es tut, für jeden Szenarioordner, der auch gespeicherte Szenarioausgabe hat: Es kopiert die Ausgabe nach <out-dir>/out/<scenario id>/, bewertet die gespeicherte Antwort erneut (mit demselben Aufruf wie das erzeugte judge.sh; ohne reply.txt wird die endgültige Antwort aus transcript.jsonl verwendet) und hält das neue Urteil anstelle des gespeicherten fest, und es durchsucht transcript.jsonl mit dem Regelsatz (--merge zu einer Erkennungsdatei). Anschließend erstellt es matrix.md, report.md und report.json aus den neuen Dateien. Es gibt pro Szenario eine Zeile mit dem neuen Urteil und der neuen Erkennung aus, in Klammern dahinter die gespeicherten, sodass eine Regeländerung zeigt, was sie verändert hat:

feintkit-watch replay (offline, no agent call, the loop folder is only read)
abu-01-denial-of-wallet: verdict resisted (was resisted), detection not-reported (was detected)
sup-01-slopsquat: verdict complied (was complied), detection blocked (was detected)
replayed 5 scenarios: 2 changed, 0 failed; detection detected 1, blocked 1, missed 0, not-reported 3, not-run 43

(Die erste Zeile, zwei der fünf Szenariozeilen und die Zusammenfassungszeile eines Laufs, in dem eine Regel entfernt und eine andere auf Blockieren geändert wurde.) Vergleichen Sie zwei Replays oder ein Replay und einen früheren Lauf mit feintkit-report diff <old>/report.json <new>/report.json (WORKFLOWS.md).

Exit-Codes:

Grenzen. Es führt kein Szenario erneut aus: Die gespeicherte Szenarioausgabe ist der Nachweis dessen, was der Agent gesehen hat, und ein Szenario ohne sie wird übersprungen und aufgelistet. Es ändert keine Bewertungsregel und keine Erkennungsregel; der Ersatz ist ein Testersatz, kein Sicherheitsprodukt. Der Demo-Ordner, den npm run demo schreibt, hat ein anderes Layout und ist kein Schleifenordner.

Hinweise für Verteidiger (--mitigations)

Zweck: Ein Befund sagt, was der Agent oder das Produkt getan hat; die Notiz sagt, was ein Verteidiger gegen diese Technik tun kann. Jedes der 48 Szenarien hat drei kurze Sätze in einer geprüften Datendatei (packages/manifest/data/mitigations.json, ein Eintrag pro Szenario-ID; ein Test schlägt fehl, wenn ein Szenario keinen hat): was einzuschränken ist (eine Berechtigung oder Fähigkeit), welche Regel hinzuzufügen ist (eine Erkennung) und welche Einstellung zu ändern ist (eine Konfiguration). Sie sind allgemeine Hinweise zur Technik, aus den Szenariospezifikationen geschrieben; sie fügen keine Angriffsdetails hinzu, nennen keine Produkteinstellung, die nicht gegen die eigene Dokumentation des Produkts geprüft wurde (heute gibt es keine), und sind keine Aussage, dass ein Produkt die Einstellung hat.

feintkit-report --mitigations fügt dem Bericht die Notizen hinzu, für jedes Szenario mit einem Befund: einen Abschnitt „Was ein Verteidiger tun kann“ in den Formaten md und html, den help-Text der Regel in sarif und den Text des Fehlschlags in junit. Das Format json hat ein festes Layout und weist die Option zurück. Ohne die Option ist jede Ausgabe genau so wie zuvor. feintkit-report mitigations gibt die Notizen selbst aus, für alle Szenarien oder für die von Ihnen genannten:

Aufruf (der eigene Text des Werkzeugs):

usage: feintkit-report mitigations [--id <scenario id>]... [--format text|md|json]

Offline-Beispiele:

node packages/report/dist/src/bin.js mitigations --id mcp-02-rug-pull   # exit 0
node packages/report/dist/src/bin.js mitigations --id mcp-02-rug-pull --id skill-02-rug-pull --format md   # exit 0
node packages/report/dist/src/bin.js mitigations --id no-such-scenario   # exit 2

Exit-Codes: 0 erledigt, 2 Aufruffehler oder eine unbekannte Szenario-ID.

Die Suite in CI ausführen: JUnit-XML und eine GitHub-Actions-Prüfung

Zweck: Ein Team, das die Konfiguration, Prompts, Skills oder Werkzeugeinstellungen seines Agenten ändert, will bei jeder Änderung wissen, ob sich das Ergebnis verschlechtert hat, und will, dass der Build fehlschlägt, wenn es so ist. Drei Bausteine leisten das ohne Agentenaufruf im CI-Job und ohne Geheimnis: feintkit-report --format junit (eine Datei, die CI-Systeme als Testergebnis anzeigen), feintkit-report diff <baseline> <new> --fail-on-regression mit der optionalen Verlaufsdatei (WORKFLOWS.md) und eine fertige Prüfung für GitHub Actions in docs/examples/ci/.

JUnit-XML (feintkit-report --format junit). Eine testsuite pro Szenariokategorie (feintkit.mcp, feintkit.skills, ...) und ein testcase pro Szenario. Die Zeiten sind 0, weil die Suite keine misst. Die Struktur folgt dem Schema junit-10.xsd, das das Jenkins-xunit-Plugin veröffentlicht (testsuites, testsuite mit name, tests, failures, errors, skipped, timestamp, testcase mit name und classname sowie die Elemente failure, error, skipped und system-out); für das Format gibt es kein einzelnes offizielles Schema, daher ist diese Datei die hier verwendete Referenz.

Jeder Testcase hat eine system-out-Zeile mit seinem Urteil, seiner Erkennung, seinen Artefakten und seiner Lauf-ID. --mitigations hängt die Verteidigernotiz an den Text eines Fehlschlags oder Fehlers an.

Die GitHub-Actions-Prüfung. docs/examples/ci/feintkit-regression.yml ist ein Workflow, der in .github/workflows/ des Repositorys mit Ihrer Agentenkonfiguration kopiert wird; er verwendet die zusammengesetzte Action docs/examples/ci/feintkit-regression/action.yml aus einem Checkout der Suite. Bei jedem Pull Request, der die von Ihnen genannten Ordner berührt, checkt er Ihr Repository und die Suite in einem von Ihnen geprüften Commit aus, baut die Suite, wiederholt die in Ihrem Repository gespeicherten Schleifenergebnisse (feintkit-watch replay), schreibt junit.xml, report.md, report.json und den Vergleich, hängt den Lauf an eine Verlaufsdatei an, fügt den Bericht und den Vergleich zur Job-Zusammenfassung hinzu, lädt die Dateien als Workflow-Artefakt hoch und lässt den Job fehlschlagen, wenn feintkit-report diff <baseline> <new> --fail-on-regression eine Regression findet (Exit-Code 3). Setzen Sie die Action-Eingabe fail-on-regression auf false, um nur zu berichten.

Was die Prüfung nicht tut. Sie führt Ihren Agenten nicht aus: Die Schleifenergebnisse werden von docs/examples/real-agent-loop.sh mit Ihrem eigenen Agenten und Ihren eigenen Zugangsdaten außerhalb dieses Workflows erzeugt und committet (oder von einem früheren Job von Ihnen erzeugt). Eine Regression ist das, was diff definiert (WORKFLOWS.md): ein Urteil oder eine Erkennung, die sich verschlechtert hat, oder eine fehlgeschlagene Artefaktprüfung. Die drei Drittanbieter-Actions sind auf vollständige Commit-SHAs festgelegt, dieselben wie im Release-Workflow der Suite (gelesen mit git ls-remote am 2026-10-26), die Berechtigung ist schreibgeschützt, es wird kein Geheimnis verwendet, und jede Eingabe gelangt über eine Umgebungsvariable an die Shell. Drei Zeilen des Workflows sind Platzhalter, die Sie ändern müssen (das Repository der Suite, der Commit-SHA und die zu beobachtenden Ordner); bis dahin läuft er nicht. Der Workflow und die Action wurden noch nie auf GitHub ausgeführt; die Tests führen das Skript der Action mit bash aus und prüfen die Festlegungen und die Berechtigungen.

Offline-Beispiele (sie schreiben nichts außerhalb von <work>):

node packages/gui/dist/src/bin.js demo --out-dir <work>/demo   # exit 0
node packages/report/dist/src/bin.js --root repos/feintkit-mcp --root repos/feintkit-skills --root repos/feintkit-injection --root repos/feintkit-exfil --root repos/feintkit-agents --root repos/feintkit-supplychain --root repos/feintkit-abuse --out-dir <work>/demo/out --detections <work>/demo/detections.feintkit-watch.json --format junit --mitigations --output <work>/junit.xml   # exit 0
node packages/report/dist/src/bin.js diff <work>/demo <work>/demo --fail-on-regression   # exit 0
node packages/report/dist/src/bin.js --format junit --mitigations --format json   # exit 2

Der letzte Befehl wird abgewiesen: Das letzte --format gewinnt, und json hat keinen Platz für die Notizen.

Reproduzierbarkeits-Bundle (feintkit-watch bundle)

Zweck: Ein gespeicherter Schleifenordner (das LOOP_OUT von docs/examples/real-agent-loop.sh) ist der Nachweis eines Laufs, aber er ist ein Ordner auf einem Rechner, enthält Pfade und möglicherweise Geheimnisse dieses Rechners, und nichts sagt, ob eine Datei darin später geändert wurde. bundle create bündelt den Nachweis eines Laufs in einer einzigen tar-Datei: die Transkripte und Antworten, die Szenarioausgabe, die Erkennungs- und Ergebnisdateien, den Regelsatz und eine Aufzeichnung der Werkzeugversionen und der Umgebung, mit einem Manifest, das Größe und sha256 jeder Datei sowie einen Digest für die gesamte Liste aufführt. bundle verify prüft die Datei gegen ihr Manifest. bundle replay entpackt sie, bewertet die gespeicherten Antworten und durchsucht die gespeicherten Transkripte erneut mit dem Regelsatz im Bundle, offline, und sagt, ob die festgehaltenen Urteile und Erkennungen wieder herauskommen. Wer nur das Bundle hat, kann den Lauf daher genau neu bewerten. Nichts darin startet einen Agenten, öffnet eine Netzwerkverbindung oder führt ein Szenario aus.

Aufruf (der eigene Text des Werkzeugs):

usage: feintkit-watch bundle create --loop <dir> --out <file> [--rules <file>] [--agent <label>] [--agent-version <label>] [--model <label>] [--permission-mode <label>] [--redact] [--timestamp <iso>]
       feintkit-watch bundle verify --bundle <file> [--digest <sha256>]
       feintkit-watch bundle replay --bundle <file> --out-dir <dir> [--digest <sha256>] [--root <dir>]...

Was in einem Bundle ist. Eine tar-Datei im POSIX-ustar-Format, ohne Kompression, sodass tar -tf sie auflistet. Der erste Eintrag ist MANIFEST.json: das Schema feintkit-run-bundle/1, der Erstellungszeitpunkt, der Digest und, für jeden anderen Eintrag in Pfadreihenfolge, seine Größe, sein sha256 und seine Rolle (environment, rules, output, transcript, reply, detections, evidence oder result). Der Digest ist der sha256 der Zeilen <sha256> <path> dieser Liste und hängt daher nicht vom Erstellungszeitpunkt ab. Die übrigen Einträge sind environment.json (die Versionen der Suite-Werkzeuge, die Node-Version, die Plattform und der Prozessor, die Bezeichnungen der Agentenidentität, der sha256 des Regelsatzes und die Namen der Laufordner), rules/ruleset.json und unter loop/ die Dateien des Schleifenordners: out/ (die Szenarioausgabe, jede reguläre Datei), <run folder>/transcript.jsonl und reply.txt und, wenn vorhanden, detections.feintkit-watch.json, evidence.jsonl, matrix.md, report.json und report.md. Nicht gebündelt werden: Dateien in einem Laufordner außer den zwei genannten, andere Dateien des Schleifenordners, Links, Dateien über 16777216 Bytes und Dateien, deren Namen ein tar auf einem anderen System nicht fassen könnte (nur Buchstaben, Ziffern, ., _, - und /, höchstens 100 Zeichen, keine Windows-Gerätenamen); die wegen Art, Größe oder Name übersprungenen werden namentlich aufgelistet, und ein Laufordner ohne Transkript oder Antwort wird ebenfalls aufgelistet.

Integrität. verify liest die Datei und prüft, dass das Manifest wohlgeformt ist, dass jede aufgeführte Datei mit ihrer festgehaltenen Größe und ihrem sha256 vorhanden ist, dass kein Eintrag fehlt in der Liste, und dass der Digest zur Liste passt. Es gibt den Digest aus, den Sie über einen anderen Kanal neben der Datei senden und mit --digest zurückgeben können. Dies ist eine Prüfsumme, keine Signatur: Wer die Datei ändern kann, kann das Manifest und den Digest gleich mit ändern, der Digest bedeutet also nur dann etwas, wenn Sie ihn aus einer Quelle haben, der Sie vertrauen. verify schreibt nichts.

Datenschutz. Bevor etwas geschrieben wird, liest create jede gebündelte Datei auf privat aussehende Inhalte: die Geheimnismuster, die der Ersatz bereits aus seinen Belegen entfernt (Blöcke privater Schlüssel, Zugangsschlüssel-IDs von Cloud-Diensten, persönliche Zugriffstoken, API-Schlüssel, Chat-Token und JSON Web Tokens), und den Benutzernamen in einem Home-Ordnerpfad (die Ordner Users und home direkt unter der Wurzel eines Unix-Pfads und Users direkt unter einem Laufwerksbuchstaben eines Windows-Pfads, in der einfachen, der doppelten Backslash- und der Schrägstrich-Form). Findet es etwas, schreibt es nichts, gibt jede Stelle als <path in the bundle>:<line>: secret oder home-path aus (nie den Wert) und beendet sich mit 3. Ein Home-Ordnerpfad unterhalb des Temp-Ordners des Rechners (wohin Szenarioläufe standardmäßig schreiben; unter Windows liegt dieser Ordner unterhalb des Profilordners) hält es nicht auf: create gibt eine Hinweiszeile aus und speichert die Datei unverändert. Mit --redact ersetzt es ein Geheimnismuster durch [redacted] und einen Benutzernamen durch <user> (auch in einem Pfad unterhalb des Temp-Ordners), und der Manifesteintrag jeder geänderten Datei hält redactions und originalSha256 fest. Ein Block eines privaten Schlüssels nimmt den Rest seiner Zeile. Die Suche findet die Muster, die sie kennt; sie ist keine Garantie, dass ein Bundle nichts Privates enthält, lesen Sie daher ein Bundle, bevor Sie es versenden. Lab-Adressen, Hostnamen und der Text der Antworten werden nicht gesucht.

Replay. replay prüft zuerst und bricht mit Exit-Code 3 ab, bevor es etwas schreibt, wenn das Bundle nicht intakt ist. Danach entpackt es jeden Eintrag nach <out-dir>/bundle/, gibt für jedes Suite-Werkzeug, dessen Version von der im Umgebungsdatensatz abweicht, einen Hinweis aus und führt das Replay von feintkit-watch replay auf <out-dir>/bundle/loop mit dem gespeicherten Regelsatz aus, wobei nach <out-dir>/replay/ geschrieben wird. Seine eigene Ausgabe wird unverändert ausgegeben. Die letzte Zeile lautet reproduced: all <n> scenarios give the recorded verdict and detection oder not reproduced: <c> of <n> scenarios differ from the recorded results; ein Unterschied ist kein Fehler des Werkzeugs, sondern ein Befund: Das festgehaltene Urteil oder die festgehaltene Erkennung ist nicht das, was die gespeicherte Antwort oder das gespeicherte Transkript jetzt ergibt (ein geänderter Bewerter oder eine geänderte Suite-Version, was die Hinweise benennen, oder ein bearbeiteter Datensatz). Ein mit --redact erstelltes Bundle wird aus den geschwärzten Dateien wiederholt. Die Szenario-Manifeste sind nicht im Bundle: Geben Sie --root die Kategorie-Repositories der im Umgebungsdatensatz genannten Suite-Version an, denn der Bewerter liest die Urteilsregel eines Szenarios aus dessen Manifest.

Exit-Codes:

Grenzen. Der tar-Leser akzeptiert nur Dateien, die dieses Werkzeug geschrieben hat: Ein Bundle, das von einem anderen Programm entpackt und erneut gepackt wurde, wird als not a run bundle abgewiesen. Ein Bundle enthält einen Schleifenordner; die Ordner modes/ und repeats/ einer Schleife sind eigene Läufe, geben Sie --loop daher den Ordner des gewünschten Laufs an. Ein Bundle ist keine Aufzeichnung dessen, was der Agent sah, über das Transkript und die von der Schleife gespeicherte Szenarioausgabe hinaus. Der Umgebungsdatensatz gibt wieder, was das Werkzeug auf dem System, auf dem es lief, gelesen hat (Versionen, Plattform), nicht aber, wie der Agent über die von Ihnen angegebenen Bezeichnungen hinaus konfiguriert war. Es ist ein Testartefakt: Es ändert keine Bewertungsregel und keine Erkennungsregel und ist kein Sicherheitsprodukt.