Wie es übersehen wird
Sie haben eine kleine Korrektur angefordert. Der Agent beginnt, Dateien im gesamten Projekt zu berühren. Ein breites Refactoring kann korrekt sein, verdient aber eine andere Aufmerksamkeit als eine einzeilige Änderung.
Das Risiko ist leicht zu übersehen, wenn Dateioperationen einzeln erscheinen. Jede Bearbeitung wirkt isoliert klein. Zusammen können sie einen viel größeren Teil des Projekts betreffen, als die ursprüngliche Aufgabe vermuten ließ.
Was ClawMetry erkennt
ClawMetry untersucht erfasste Tool-Argumente auf den Umfang von Dateiänderungen und destruktive Befehlsmuster. Eine breite Bearbeitung kann einen File-blast-radius-Warnbefund auslösen. Erkannte rekursive Löschvorgänge an einem Root-Speicherort können einen kritischen Befund auslösen.
Der Unterschied, der den Befund verändert
Auslösendes Beispiel
30 verschiedene Dateischreibvorgänge
Warnbefund
Stilles Vergleichsbeispiel
4 verschiedene Dateischreibvorgänge
Kein Befund für diesen Detector.
Im geprüften Vergleich lösen Schreibvorgänge in dreißig verschiedene Dateien eine Warnung aus. Schreibvorgänge in vier Dateien bleiben unbemerkt. Der Schwellenwert für breite Bearbeitungen kann je nach Laufzeit und Baseline variieren. Der Befund liefert eine Anzahl und begrenzte Belege, um die Prüfung zu fokussieren.
Detector-Ergebnis prüfen
{
"kind": "file_blast_radius",
"severity": "warning",
"evidence": {
"distinct_files": 30,
"write_calls": 30,
"threshold": 25,
"threshold_source": "static",
"baseline": null,
"outside_workspace": 0,
"destructive": [],
"samples": [
"example/f0.py",
"example/f1.py",
"example/f2.py"
],
"observed": "tool_arguments"
}
}Eingaben und vollständige Ergebnisse herunterladen (JSON)Wie das Beispiel geprüft wurde
Diese Beispiele werten den veröffentlichten Detector mit selbst erstellten Ereignisdaten oder einmalig verwendeten Konfigurationsdateien aus. Die Videos veranschaulichen dieses Verhalten. Es sind keine Aufzeichnungen von Live-Agents oder der Produktoberfläche. Kein Befehl in den Beispielen wurde ausgeführt.
Das Ergebnis beschreibt das Verhalten für diese Eingaben. Es belegt weder Laufzeit-Ingestion, Prävention noch einen echten Kompromittierungsfall. Festgelegten Quellvertrag prüfen.
Was als nächstes zu prüfen ist
Vergleichen Sie den betroffenen Umfang mit der Anfrage. Prüfen Sie den tatsächlichen Diff, insbesondere generierte Änderungen und Löschungen. Stellen Sie sicher, dass Tests die betroffenen Dateien abdecken, bevor Sie das Ergebnis akzeptieren. Ziel ist es, eine unerwartet breite Änderung zu erkennen, solange Sie noch den Kontext haben.
- Umfang mit Aufgabe vergleichen
- Tatsächlichen Diff prüfen
- Tests und Löschungen prüfen
Was dieses Signal belegt
Dieser Detektor liest Tool-Argumente, keine Dateisystem-Syscalls. Er meldet nach der Aktion und beweist nicht, dass jede genannte Änderung erfolgreich war.