backbay-labs/clawdstrikePolicy-Engine und EDR für KI-Agenten-Flotten und Entwickler-Workstations. Überwacht Tool-Aufrufe, Dateizugriffe, Netzwerkflüsse und Prozessausführung mit Ed25519-signierten Audit-Trails und Fail-Closed-Durchsetzung.
EDR für das Zeitalter des Schwarms.
Fail closed. Sign the truth.
Status: Pre-1.0-Beta. Die öffentlichen APIs sind stabil; die Standardeinstellungen können sich vor 1.0 noch verschärfen.
Clawdstrike ist eine Policy-Engine, ein EDR und eine signierte Audit-Kette in einer einzigen Binärdatei. Ein tool_call eines KI-Agenten liegt in derselben Ereignistaxonomie wie ein Kernel-Level-file_access, process_exec, network_flow, dylib_load oder launch_persistence. Eine Policy-Engine wertet sie aus. Ein kausaler Graph, signiert mit Ed25519, zeichnet sie auf. Standardmäßig: Fail closed.
Dieselbe Engine wird als Rust-Crate, TypeScript-SDK, Python-Paket, Go-Modul, CLI, Desktop-EDR-Agent (macOS Endpoint Security + Network Extension; Linux Tetragon + Hubble) und als Enterprise-Kontrollplattform ausgeliefert.
Quick Start · Guards · Policies · Formale Verifikation · Enterprise · Design
Installation über den bevorzugten Paketmanager:
brew install backbay-labs/tap/clawdstrike # macOS, Linux
npm install @clawdstrike/sdk # TypeScript
pip install clawdstrike # Python
cargo add clawdstrike # Rust
go get github.com/backbay-labs/clawdstrike-go
Ein Projekt anlegen und den Daemon starten:
clawdstrike init --keygen
# schreibt policy.yaml, config.toml, keys/clawdstrike.key{,.pub}
clawdstrike daemon start && clawdstrike daemon status
# Status: healthy | Version: 0.2.7 | Uptime: 2s
Drei Ablehnungen, alle signiert:
$ clawdstrike check --action-type file --ruleset strict ~/.ssh/id_rsa
BLOCKED [Critical]: Access to forbidden path: ~/.ssh/id_rsa
$ clawdstrike check --action-type egress --ruleset strict api.openai.com:443
BLOCKED [Error]: Egress to api.openai.com blocked by policy
$ clawdstrike check --action-type mcp --ruleset strict shell_exec
BLOCKED [Error]: Tool 'shell_exec' is blocked by policy
Überprüfen, ob die Policy selbst kompiliert und intern konsistent ist:
$ clawdstrike verify --policy strict
Consistency: PASS (47 formulas, 0 conflicts)
Completeness: PASS (4/4 action types covered)
Inheritance: PASS (0 weakened prohibitions)
Einen echten Agenten unter Durchsetzung ausführen:
clawdstrike run --policy clawdstrike:strict -- python my_agent.py
Der Agent läuft normal. Jeder Tool-Call trifft zuerst auf die Engine. Ablehnungen werfen einen typisierten Fehler im SDK und geben eine signierte Quittung aus.
Für Flottenbereitstellungen das Helm-Chart installieren. hushd und die Spine-Signer sind fail-closed und benötigen Schlüssel zur Installationszeit, also die Secrets vorher erstellen und im Chart referenzieren:
NS=clawdstrike-system
kubectl create namespace "$NS"
kubectl -n "$NS" create secret generic clawdstrike-hushd-auth \
--from-literal=CLAWDSTRIKE_API_KEY="$(openssl rand -hex 32)" \
--from-literal=CLAWDSTRIKE_ADMIN_KEY="$(openssl rand -hex 32)" \
--from-literal=CLAWDSTRIKE_AUTH_PEPPER="$(openssl rand -hex 32)"
kubectl -n "$NS" create secret generic clawdstrike-spine \
--from-literal=SPINE_LOG_SEED_HEX="$(openssl rand -hex 32)" \
--from-literal=SPINE_WITNESS_SEED_HEX="$(openssl rand -hex 32)"
helm install clawdstrike \
oci://ghcr.io/backbay-labs/clawdstrike/helm/clawdstrike --version 0.2.0 \
--namespace "$NS" \
--set hushd.auth.existingSecret=clawdstrike-hushd-auth \
--set spine.secrets.existingSecret=clawdstrike-spine
Damit werden hushd, der Spine-Checkpointer + Witness und das gebündelte NATS JetStream gestartet. Die Control-API (Enrollment, Posture-Befehle, signierte Completion-Bundles zurück) sowie die Tetragon-/Hubble-Telemetriebrücken sind optional.
Siehe Chart-README für den vollständigen Parametersatz und Enterprise-Enrollment für die End-to-End-Agenten-Onboarding.
flowchart LR
A[Agent / sensor] --> B[Canonical event]
B --> C[Policy engine + guard stack]
C -->|allow| D[Action runs]
C -->|deny| E[Blocked, fail-closed]
C --> F[Ed25519 receipt]
F --> G[Causal graph]
G -.->|enterprise| H[Spine audit chain]
SDK-Adapter und Betriebssystem-Sensoren speisen dasselbe kanonische Ereignis in die Policy-Engine ein. Adapter decken KI-Agent-Tool-Aufrufe ab; Kernel-Sensoren (macOS Endpoint Security und Network Extension, Linux Tetragon und Hubble) decken Datei-, Prozess-, Netzwerk-, Dylib- und Persistenzereignisse ab. Der Guard-Stack gibt ein Urteil zurück, das Urteil wird mit einer Ed25519-Quittung versehen, und jede Quittung wird inhaltlich gehasht in einen pro-Sitzung kausalen Graphen eingebettet, der die Agentenidentität mit nachgelagerten Betriebssystemereignissen verknüpft.
Wenn eine Entscheidung einen Reaktionsschwellwert überschreitet, gibt die Engine eine signierte Wirkung aus: Quarantäne einer Datei, Einschränkung eines Egress-Ziels, Suspendierung eines Prozessbaums, Widerruf einer zuvor erteilten Genehmigung. Wirkungen sind wo möglich reversibel. Vergangene Beobachtungen bleiben auf einem diskettenbasierten Flugschreiber, sodass eine verschärfte Policy gegen den Zustand der letzten Woche simuliert werden kann, bevor sie ausgerollt wird. Im Enterprise-Modus wird die Quittungskette über NATS an den Spine-Checkpointer gesendet; ein unabhängiger Witness signiert jedes Bündel mit.
Logs sind Geschichten; Beweis ist eine Signatur.
Jeder Guard ist eine zusammensetzbare Prüfung an der Tool-Grenze. Gibt ein Urteil mit Beweisen zurück. Fail-fast oder aggregiert; pro Policy konfigurierbar.