____         ____                       ____  _
    / __ \  ___  / __/___   ___   ___  ___  / ___|| | __ _ __      __
   / / / / / _ \/ /_// _ \ / _ \ / __|/ _ \| |    | |/ _` |\ \ /\ / /
  / /_/ / /  __/ __//  __/| | | |\__ \  __/| |___ | | (_| | \ V  V /
 /_____/  \___/_/   \___/ |_| |_||___/\___| \____||_|\__,_|  \_/\_/

DefenseClaw kombiniert eine Python-Operator-CLI, einen Go-Gateway-Sidecar und ein OpenClaw-TypeScript-Plugin. Gemeinsam setzen sie eine einfache Betriebsregel durch: Nicht vertrauenswürdige Agentenfähigkeiten werden gescannt, verwaltet, protokolliert und blockiert, wenn die Richtlinie sie als unsicher einstuft.

Highlights

• Zulassungskontrolle – Scannen Sie Skills, MCP-Server, Plugins und Code vor der Ausführung.
• Laufzeit-Schutzmaßnahmen – Überprüfen Sie Aufforderungen, Vervollständigungen und Tool-Aufrufe mit Regex-Regeln, Richtlinien, optionalem LLM-Beurteiler und Cisco AI Defense-Inspektion.
• CodeGuard – Integrierte statische Prüfungen auf Geheimnisse, gefährliche Ausführung, unsichere Deserialisierung, schwache Kryptografie, Injektionsmuster und riskanten Dateizugriff.
• OpenShell-Sandbox-Unterstützung – Linux-Sandbox-Einrichtung mit Netzwerk-, Dateisystem-, Syscall- und Richtlinienkontrollen.
• Registries – Erfassen externer Skill-/MCP-Kataloge (HTTPS-YAML im Unternehmen, smithery.ai, skills.sh, Git, ClawHub) mit SSRF-Schutz, scanner-gesteuerten Entscheidungen und automatischer Übernahme in die Asset-Richtlinie. Siehe docs/REGISTRIES.md.
• Prüfung und Beobachtbarkeit – Ein Konfig-v8-Graph für Bucket-Erfassung, obligatorischer SQLite-Verlauf, zentrale Schwärzung und unabhängige JSONL-, OTLP-, Prometheus-, Splunk-HEC-, Galileo-, HTTP-, Konsolen- und lokale Grafana/Splunk-Ziele.
• Operator-UX – Eine CLI und TUI für Einrichtung, Gesundheitschecks, Warnungen, Block-/Erlaubnislisten, Scannerergebnisse und Richtlinien-Workflows.

Umfang und Einschränkungen

DefenseClaw ist eine Durchsetzungs- und Beweisschicht für agentische KI-Bereitstellungen. Es verbessert die Sicherheit, indem es Scannerergebnisse, Laufzeitinspektion, Richtlinienentscheidungen, Sandbox-Kontrollen und Prüfpfade kombiniert, beweist jedoch nicht, dass eine Agenten-, Skill-, Plugin- oder Modellinteraktion risikofrei ist.

Bereitstellungen mit hohem Risiko sollten DefenseClaw mit menschlicher Überprüfung, Berechtigungen mit geringsten Privilegien, Sandboxing, CI-Gates und Produktionsüberwachung kombinieren. Im Beobachtungsmodus werden Ergebnisse protokolliert, ohne zu blockieren. Im Aktionsmodus können konfigurierte HOHE und KRITISCHE Ergebnisse Aufforderungen, Tool-Aufrufe oder die Komponentenzulassung blockieren.

Dokumentation

Die Projekt-Markdown-Dokumentation ist unter docs/ zentralisiert. Paketlokale READMEs bleiben bei Bundles oder Beispielen, die lokalen Kontext benötigen.

Installation

Voraussetzungen

Aus dem Quellcode erstellen (nur für Entwickler)

Wählen Sie den Befehl nach Absicht:

Die Quellziele und `scripts/install-dev.sh` sind Entwicklungswerkzeuge, kein Upgrade-Pfad. Direkte Installationsziele lehnen es ab, eine release-verwaltete Installation oder eine Installation, die einem anderen Checkout gehört, zu überschreiben. `make all` ist der explizite Neuinstallations-Workflow für Entwicklungsrechner: Wenn die installierte CLI bereits exakt auf das aktuelle Checkout verweist, kann sie markerschlosen oder vorherigen Release-Quellstatus zurückgewinnen und nach dem Neubau einen strengen Eigentumsmarker setzen. Dies kann die aktuellen Migrationen des Checkouts gegen den Entwicklerstatus ausführen und darf nicht als Release-Upgrade verwendet werden. Release-verwaltete Installationen müssen den release-eigenen Resolver `scripts/upgrade.sh` oder `scripts/upgrade.ps1` verwenden. `make install`, `make dev-install` und `scripts/install-dev.sh` sind niederstufige, strikte Installationsroutinen für ein neues oder isoliertes Entwicklerverzeichnis; sie sind nicht der normale Befehl für wiederholte Entwicklung.

### Installieren mit dem Release-Skript```bash
VERSION=0.8.6
INSTALL_URL="https://raw.githubusercontent.com/cisco-ai-defense/defenseclaw/${VERSION}/scripts/install.sh"
curl -LsSf "$INSTALL_URL" | VERSION="$VERSION" bash
defenseclaw init --enable-guardrail

Für plattformspezifische Schritte siehe docs/INSTALL.md.

Auf nativen Windows x64 verwenden Sie das native Setup EXE und den Hook-Only-Connector-Pfad in der Native Windows-Anleitung. WSL wird nicht unterstützt. Codex CLI und Claude Code sind die einzigen zertifizierten Windows-Connectors.

Schnellstart```bash

Check the local install and dependencies

defenseclaw doctor

Initialize config, scanner defaults, and guardrail plumbing

defenseclaw init --enable-guardrail

Scan installed agent capabilities

defenseclaw skill scan all defenseclaw mcp list defenseclaw plugin scan extensions/defenseclaw

Start the Go gateway sidecar

defenseclaw-gateway start

Open the operator dashboard

defenseclaw tui

Führen Sie die Guardrail im Beobachtungsmodus während der Abstimmung aus:```bash
defenseclaw setup guardrail --mode observe --restart

Wechseln Sie in den Aktionsmodus, wenn die Richtlinie bereit ist zu blockieren:```bash defenseclaw setup guardrail --mode action --restart

Siehe [docs/QUICKSTART.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/QUICKSTART.md) für die vollständige Anleitung.

---

## Architektur

| Komponente | Laufzeit | Rolle |
|-----------|---------|------|
| Python CLI | Python | Operator-Befehle, Scanner-Orchestrierung, Konfigurationseinrichtung, lokale Bundles |
| Gateway sidecar | Go | REST API, WebSocket Bridge, Policy Engine, Guardrail Proxy, Audit Store, Telemetrie |
| OpenClaw plugin | TypeScript | Fetch-Interception, Tool-Call-Inspektions-Hooks, Slash-Befehle, Sidecar-Integration |
| Policies | YAML/Rego | Admission-Entscheidungen, Guardrail-Aktionen, Sandbox/Firewall-Verhalten, Scanner-Profile |
| Dokumentation | Markdown/JSON | Zentrale Dokumente, paketlokale READMEs und DeepWiki-Konfiguration |

Der Gateway stellt lokale REST-APIs für die CLI und das Plugin bereit, verbindet sich über WebSocket mit OpenClaw, inspiziert den LLM-Traffic über einen lokalen Proxy und zeichnet Entscheidungen in einem dauerhaften Audit-Store auf.```text
Agent runtime -> OpenClaw plugin -> DefenseClaw gateway -> policy + scanners + audit
                                    |
                                    +-> guardrail proxy -> LLM provider
                                    +-> OTLP / Splunk / webhooks / JSONL

Für Diagramme und detaillierte Abläufe lesen Sie bitte docs/ARCHITECTURE.md.

Scannen und Guardrails

DefenseClaw fasst Cisco AI Defense Scanner und lokale Richtlinien in einen einzigen Zulassungsablauf zusammen:

Scanner-Richtlinien befinden sich in policies/scanners/. Guardrail-Regelpakete befinden sich in policies/guardrail/.

Beobachtbarkeit

DefenseClaw zeichnet Durchsetzungs- und Laufzeitnachweise über mehrere Kanäle auf:

Config v8 hält die Quelle prägnant, während Auslassungen zu einem vollständigen effektiven Plan zusammengestellt werden:```yaml config_version: 8 observability: {}

Das Standardverhalten sammelt jedes registrierte Log, Trace und jede Metrik und bewahrt jedes gesammelte Log unredigiert in der obligatorischen lokalen SQLite-Datenbank. Es erfolgt kein Remote-Export, bis ein Ziel hinzugefügt wird. Ein aktiviertes Ziel ohne `send` oder `routes` empfängt jeden Bucket und jedes Signal, das sein Typ unterstützt, unredigiert: Allgemeines OTLP erhält Logs/Traces/Metriken, Splunk HEC erhält Logs, Prometheus erhält Metriken und die Galileo-Voreinstellung erhält Traces. Mehrere Ziele erhalten unabhängige Kopien.

Überprüfen Sie die erweiterte Richtlinie und die unredigierten Zweige mit:```bash
defenseclaw config show --effective --section observability
defenseclaw observability plan

Use centralized none, sensitive, content, strict oder benutzerdefinierte feldbewusste Schwärzungsprofile pro Bucket oder Ziel. Bei voller Wiedergabetreue können Standardeinstellungen Prompts, Outputs, Tool-Argumente/-Ergebnisse, Beweise, Pfade und Identifikatoren umfassen. Konfigurieren Sie daher ein Schwärzungsprofil, bevor Sie über eine Vertrauensgrenze exportieren, die diese Inhalte nicht erhalten darf.

Bearbeiten Sie Bucket und Schwärzungsrichtlinie in der Quelldatei, validieren Sie es, bevor das Gateway es sieht, und überprüfen Sie das kompilierte Ergebnis, anstatt die generierte Referenz vollständig zu kopieren:```bash umask 077 cp "$HOME/.defenseclaw/config.yaml"
"$HOME/.defenseclaw/config.yaml.before-observability-edit" ${EDITOR:-vi} "$HOME/.defenseclaw/config.yaml"

defenseclaw config validate &&
defenseclaw config show --effective --section observability &&
defenseclaw observability plan &&
defenseclaw-gateway restart &&
defenseclaw doctor

Nicht nach einem Validierungsfehler neu starten. Stellen Sie das private Backup wieder her, korrigieren Sie die
Quelle und validieren Sie erneut. Ein globales oder bucketweises Redaktionsprofil gilt auch für die
erzeugte lokale SQLite-Projektion. Um eine vollständige lokale Historie zu behalten, während nur eine entfernte Vertrauensgrenze redigiert wird, lassen Sie das globale/bucket-Profil auf `none`
und setzen Sie `send.redaction_profile` oder ein Routenprofil auf diesem entfernten Ziel.

Starten Sie die lokale Beobachtbarkeit mit:```bash
defenseclaw setup local-observability up
defenseclaw-gateway start
defenseclaw setup local-observability status

Dashboard-Leere ist nicht ein Zustand: 0 bedeutet, dass das instrumentierte Signal null passende Ereignisse hatte, No data bedeutet, dass keine passende Serie/Log/Trace für den ausgewählten Bereich und die Filter existiert, und Not reported bedeutet, dass der Connector/Provider keinen optionalen Wert wie Tokens oder Kosten geliefert hat. Bedingte Panels wie HITL, Nur-Fehler-Ansichten und ein Trace-Wasserfall, bevor eine Trace-ID ausgewählt ist, werden voraussichtlich No data anzeigen. Ein Zieltest prüft nur die Konnektivität und erzeugt keinen normalen Dashboard-Verkehr; generieren Sie eine frische reale Agentenrunde, einen Tool-Aufruf, einen Scan oder eine Genehmigung, um die entsprechenden Panels zu validieren.

Der Knotengraph von Agent360 ist ein Loki-gestützter Lebenszyklus-DAG: Die Sitzungserstellung ist ein separater Anker, ein pro-Wurzel Prompt inputs-Knoten zählt distincte Tiefe-Null-model.request-Fakten im Bereich, und Eltern-zu-Kind-Delegation speist pro-Agent Modell-, Tool-, Genehmigungs-, Update-, Rundenausgangs- und Terminalzusammenfassungen. Prompt inputs deduplizieren nach Runde, Model-Request, Request, Operation, dann Occurrence-ID; die geordnete/rohe Ansichten behalten die einzelnen initialen und Folgeaufzeichnungen. Sitzungs- und Spawn-Anker können aus den vorherigen 24 Stunden wiederhergestellt werden, sodass Grenzfenster renderbar bleiben; ein wiederhergestellter Spawn wird nur behalten, wenn dieses Kind graphberechtigte Aktivität im ausgewählten Bereich hat. Wiederholte Modellaufrufe werden nach besitzendem Agent, Provider und Modell gruppiert. Wiederholte Tool-Aufrufe werden nach besitzendem Agent in Bash, MCP, Skills, Collaboration, File edits, Web/Browser, Visual oder Task-Kontrolle gruppiert; ein nicht erkanntes Tool behält seinen gemeldeten Namen. Exakte collaboration.send_message-Anfragen werden von der generischen Collaboration-Familie ausgeschlossen, sodass sie nur als Nachrichtengruppen erscheinen; andere Collaboration-Tools bleiben in dieser Familie. Request-Aufzeichnungen werden einbezogen, auch wenn kein terminales Gegenstück eingetroffen ist. Ihre gruppierte Gesamtzahl ist eine Request-Anzahl, keine Behauptung, dass jede Request noch ausstehend ist; der Terminal-Status bleibt in den verknüpften Roheinträgen verfügbar. Tiefe 0 ist die Wurzel und rekursive Kinder können bis zur Tiefe 64 gemeldet werden; Klick-Detail zeigt, ob jede Abstammungskante vom Connector gemeldet oder von DefenseClaw abgeleitet wurde. Knotenklicks legen exakte Zählungen und stabile Agent-/Root-/Parent-Identitäten offen, mit gefilterten Links zu den rohen OTEL-Ereignissen hinter jeder Gruppe. Optionale Current-/Root-/Parent-Session-Felder bleiben auf den Lebenszyklus-, Session-, geordneten und rohen Oberflächen; sie sind keine Agenten-Knoten-Gruppierungsschlüssel, sodass fehlende oder späte Session-Metadaten nicht die Gesamtzahl eines Agenten aufteilen können.

Dashboards schwärzen, maskieren oder verbergen Felder nicht erneut. DefenseClaw wendet zentralisierte v8-Redaktion vor dem kanonischen OTEL-Export an; Grafana zeigt oder verlinkt jedes Feld, das tatsächlich in dieser Projektion vorhanden ist, einschließlich Inhalt, wenn der Produzent es exportiert hat. Ein Feld, das vor dem Export entfernt oder transformiert wurde, kann vom lokalen Stack nicht wiederhergestellt werden. Update-Kanten stammen nur aus tatsächlichen collaboration.send_message-Tool-Einträgen. Für jeden Sender werden /root- und /root/*-Ziele in einen Messages to root-Knoten zusammengefasst, dessen Ziel-Agent-ID zur exportierten Wurzel aufgelöst wird. Exakte Wurzel-Aufgabenpfade und Aufrufe verbleiben in den geordneten/rohen Drill-Downs. Nicht-Wurzel-Ziele bleiben explizit nach exaktem Aufgabenpfad gruppiert und werden nicht als undurchsichtige Agent-ID-Joins erfunden, wenn der Connector diese Zuordnung nicht gemeldet hat. Generische Kompatibilitätsereignisse werden niemals als Updates umbenannt.

Optionale Ziele besitzen unabhängige begrenzte Warteschlangen. Standardmäßig 2.048 Datensätze und 64 MiB pro Warteschlange; Push-Batches standardmäßig 512 Datensätze, 8 MiB und 5 Sekunden (1 Sekunde für die ausgelassene Galileo-Voreinstellungsverzögerung). Warteschlangenüberlauf verwirft den neuesten versuchten Eintrag, ohne ältere FIFO-Arbeiten zu verdrängen oder obligatorische SQLite- und Geschwisterziele zu beeinträchtigen. Genaue Felder, Grenzen und Adapterunterschiede finden Sie in docs/OBSERVABILITY.md.

Fügen Sie Galileo Cloud oder selbstgehostetes Galileo hinzu, ohne die lokale Route zu ersetzen:```bash export GALILEO_API_KEY='...' defenseclaw setup galileo --project defenseclaw --logstream production defenseclaw setup galileo test

See [docs/OBSERVABILITY.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/OBSERVABILITY.md), den
[Galileo-Leitfaden](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs-site/content/docs/observability/galileo.mdx) und die
[Schema-Eigentümerschaftskarte](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/schemas/README.md). Splunk-spezifische Einrichtung befindet sich in
[docs/SPLUNK_APP.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/SPLUNK_APP.md).

Jede unterstützte vorhandene POSIX-Installation, einschließlich einer, die sich bereits auf `0.8.4` befindet,
überschreitet den harten Schnitt `0.8.5` mit dem authentifizierten Target-Release-Asset
`defenseclaw-upgrade.sh` im neuesten Modus, ohne eine Versionsüberschreibung. Der
unveränderliche integrierte Parser `0.8.4` kann das wahrheitsgemäße Zielmanifest,
dessen Windows-Bridge-Matrix leer ist, nicht akzeptieren. Führen Sie keine veralteten Raw-Network-Hinweise
aus, die von einer eingefrorenen integrierten CLI ausgegeben werden. Der release-eigene Resolver führt
`source → 0.8.4 bridge → frischer 0.8.4 controller → 0.8.5 hard cut` als eine
Transaktion durch. Die Migration
sichert die Konfiguration und konvertiert sie atomar, bewahrt das engere
Routing/Redaktionsverhalten und die root/subagent Agent360-Kompatibilität, aktualisiert
eigene lokale Dashboards ohne Zurücksetzen von Volumes und benötigt niemals einen separaten
Apply-Befehl. Siehe [CLI-Referenz — upgrade](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/CLI.md#upgrade) für den
authentifizierten Resolver-Bootstrap.

Verwenden Sie für Splunk Observability Cloud das Dashboard-Bundle unter
[bundles/splunk_o11y_dashboards/README.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/bundles/splunk_o11y_dashboards/README.md):```bash
defenseclaw setup splunk dashboards apply \
  --api-url <api-endpoint> \
  --o11y-api-token <api-access-token> \
  --with-detectors \
  --enable-detectors \
  --yes

Entwicklung```bash

Build all components

make build

Run primary test suites

make test

Run lint checks

make lint

Focused test and development guidance lives in [docs/TESTING.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/TESTING.md) and [docs/CONTRIBUTING.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/CONTRIBUTING.md).

---

## Mitwirken

Beiträge sind willkommen. Starten Sie mit [CONTRIBUTING.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/CONTRIBUTING.md), [docs/CONTRIBUTING.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/docs/CONTRIBUTING.md) und den fokussierten Dokumenten für den Bereich, den Sie ändern.

## Sicherheit

Melden Sie Sicherheitslücken bitte über den in [SECURITY.md](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/SECURITY.md) beschriebenen Prozess.

## Lizenz

Apache 2.0 – siehe [LICENSE](https://github.com/cisco-ai-defense/defenseclaw/blob/HEAD/LICENSE).

Copyright 2026 Cisco Systems, Inc. und ihre Tochtergesellschaften.