
Laufzeitsicherheit für KI-Agenten: Agenten entdecken, ihre Berechtigungen abbilden und durchsetzen, was sie tun dürfen.
<img src="https://raw.githubusercontent.com/kontext-security/kontext-cli/main/assets/kontext-computer-wordmark.gif" alt="Kontext animiertes Wortmarke" width="100%" />
<div align="center">
<p>
<a href="https://kontext.security">Website</a>
|
<a href="https://docs.kontext.security/getting-started/welcome">Dokumentation</a>
|
<a href="https://app.kontext.security">Dashboard</a>
|
<a href="https://discord.gg/gw9UpFUhyY">Discord</a>
</p>
<p>
<a href="https://github.com/kontext-security/kontext-cli/blob/main/LICENSE"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-152822?labelColor=0d1714"></a>
<a href="https://github.com/kontext-security/kontext/releases"><img alt="Latest release" src="https://img.shields.io/github/v/release/kontext-security/kontext?color=152822&labelColor=0d1714"></a>
<img alt="Built with Go" src="https://img.shields.io/badge/Go-1.25-152822?labelColor=0d1714">
</p>
</div>
# Riskante KI-Agent-Aktionen stoppen, bevor sie ausgeführt werden
KI-Agenten schlagen nicht nur Code vor. Sie führen Shell-Befehle aus, lesen Dateien, rufen Dienste auf, verändern Infrastruktur und interagieren mit Produktionssystemen.
**Kontext platziert lokale Richtlinien zwischen KI-Agenten und den von ihnen aufgerufenen Tools.** Es beobachtet unterstützte Aktionen, bewertet Richtlinien, bevor folgenreiche Aktionen ausgeführt werden, und zeichnet die Entscheidung und das Ergebnis in einem Autorisierungsjournal auf.
Beginnen Sie im Beobachtungsmodus. Sehen Sie, was die Richtlinie stoppen würde. Verschieben Sie unterstützte Grenzen in die Durchsetzung, wenn Sie bereit sind.
Fehler bei der Richtlinienbewertung erlauben den Tool-Aufruf, auch im Durchsetzungsmodus, und bleiben als Fehler im Aktivitätsprotokoll sichtbar. Abgeschlossene Richtlinien-Ablehnungen und nicht verfügbare erforderliche Genehmigungen blockieren weiterhin. Dieser Fehler-Fallback ändert das Verhalten nicht, wenn der Daemon nicht verfügbar ist oder die Durchsetzung keine nutzbare Richtlinie hat.
- **Lokale Entscheidungen:** Die Richtlinienbewertung erfolgt parallel zum Agenten.
- **Durchsetzung vor der Aktion:** Übereinstimmende Aktionen können an unterstützten synchronen Hooks abgelehnt werden.
- **Kein Wrapper-Befehl:** Installieren Sie Kontext einmal und verwenden Sie Ihre Agenten weiterhin normal.
- **Zuordenbare Nachweise:** Bewahren Sie den Agenten, die Sitzung, die Aktion, die Richtlinienentscheidung und das Ergebnis auf.
- **Verwalteter Rollout:** Verteilen Sie Richtlinien und überprüfen Sie redigierte Aufzeichnungen in einer Organisation.
Kontext unterstützt derzeit **Claude Code, Claude Cowork und Codex**. Die genaue Ereignis- und Durchsetzungsabdeckung variiert je nach Agent – siehe die
[Agent-Unterstützungsmatrix](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md).
Verwaltete Claude-Hooks erkennen Cowork-Sitzungen mit vollständigen oder verkürzten Sitzungsverzeichnisnamen und bewahren ihre Cowork-Identität in Aktivitätsaufzeichnungen.
---
## Schnellstart
### Kontext installieren
```bash
brew install kontext-security/tap/kontext
```
### Diesen Mac verbinden
Erstellen Sie ein Installations-Token im
[Kontext-Dashboard](https://app.kontext.security) und führen Sie dann aus:
```bash
kontext setup
```
Das optionale lokale Risikomodell benötigt llama.cpp: Führen Sie `brew install llama.cpp` aus, dann `kontext setup --with-local-llm`.
Setup:
- speichert das Installations-Token im macOS-Anmeldeschlüsselbund;
- installiert Hooks für unterstützte Agenten;
- startet den lokalen Kontext-Daemon;
- verbindet die Installation mit Ihrer Kontext-Organisation.
Überprüfen Sie die Installation:
```bash
kontext doctor
```
Verwenden Sie dann Claude Code oder Codex weiterhin normal. Sie müssen den Agenten nicht über einen separaten Wrapper starten.
> Self-Serve-Setup unterstützt derzeit macOS. Verwaltete und Cloud-Umgebungen können dieselbe lokale Laufzeit ausführen, wenn sie einen unterstützten Hook-Vertrag, Speicher und Daemon-Lebenszyklus bereitstellen.
---
## Was ändert sich nach dem Setup?
Ohne Richtlinie vor der Aktion führt ein Agent eine Aktion aus, bevor ein Sicherheitsteam deren Protokolle überprüfen kann:
```text
agent requests an action
|
v
action executes
|
v
activity appears in a log
```
Mit Kontext:
```text
agent requests an action
|
v
Kontext receives it through a supported hook
|
v
local policy evaluates the action
|
+---- allow ----------> action continues
|
+---- would deny -----> action continues and evidence is recorded
| (observe mode)
|
+---- deny -----------> action is stopped before execution
(enforce mode)
|
v
decision and outcome enter the authorization ledger
```
Dies schafft einen Entscheidungspunkt vor der Aktion, nicht nur eine Aufzeichnung danach.
---
## Erst beobachten. Durchsetzen, wenn bereit.
Jede unbekannte Aktion am ersten Tag zu blockieren, erzeugt Rauschen und unterbricht Entwickler. Jede Aktion unbegrenzt zuzulassen, lässt Richtlinien zu passiver Überwachung verkommen.
Kontext trennt den Rollout in zwei Modi:
### Beobachtungsmodus
Der Beobachtungsmodus zeichnet die Richtlinienentscheidung auf, ohne den Agenten zu unterbrechen.
Verwenden Sie ihn, um zu beantworten:
- Welche Tools rufen Agenten auf?
- Welche Aktionen würde die aktuelle Richtlinie ablehnen?
- Welche Repositories, Dateien und Systeme sind beteiligt?
- Wo würde die Durchsetzung legitime Arbeit unterbrechen?
- Welche Ereignisoberflächen können die Aktion tatsächlich stoppen?
### Durchsetzungsmodus
Der Durchsetzungsmodus gibt eine echte Ablehnung zurück, wenn eine deterministische Richtlinie an einem unterstützten synchronen Pre-Action-Hook übereinstimmt.
Richtlinien können Grenzen um Aktionen wie die folgenden definieren:
- destruktive Befehle;
- Zugriff auf sensible Dateien;
- Operationen auf Produktionssystemen;
- Zugriff auf Anmeldedaten;
- Datenexporte.
Die Durchsetzung ist bewusst auf Ereignisoberflächen beschränkt, bei denen der Agent auf Kontext wartet, bevor er fortfährt. Kontext behauptet nicht, dass der Empfang eines Ereignisses bedeutet, dass es jede Aktion dieses Agenten stoppen kann.
---
## Wissen, was passiert ist – und warum
Jedes unterstützte Ereignis, das Kontext erreicht, kann Nachweise zum lokalen Autorisierungsjournal beitragen.
Eine Aufzeichnung kann enthalten:
- den Agenten und die Sitzung;
- das Lebenszyklus- oder Tool-Ereignis;
- den Tool-Namen und die verfügbare Eingabe;
- die lokale Richtlinienentscheidung;
- die für diese Entscheidung verantwortliche Richtlinie;
- das verfügbare Aktionsergebnis;
- redigierte Nachweise für die spätere Überprüfung.
Kontext zeichnet Tool-Aktivitäten und Entscheidungsnachweise auf. Es erfasst keine Modellschlussfolgerungen und rekonstruiert nicht den vollständigen Gesprächsverlauf.
Verwaltete Bereitstellungen können redigierte Aufzeichnungen in das Kontext-Dashboard exportieren, um organisationsweite Überprüfung, Aufbewahrung und Untersuchung zu ermöglichen.
Journal-Exporte und Idle-Heartbeats melden die CLI-Version des laufenden Daemons als `device.cli_version`, getrennt vom Paketmarker in `device.deployment_version` (oder dessen Self-Serve-Fallback). Eine Aktualisierung des Paketmarkers ändert die gemeldete CLI-Version erst, wenn ein Daemon, der die neue Binärdatei ausführt, Telemetrie sendet.
---
## Richtlinien dort, wo der Agent läuft
Der Entscheidungspfad bleibt lokal:
```text
Claude Code / Cowork / Codex
|
v
supported hook
|
v
local Kontext runtime
|
+-----+------+
| |
v v
policy decision local ledger
|
v
allow / would deny / deny
```
Ein gehosteter Dienst muss nicht jeden Tool-Aufruf beantworten.
Verwaltete Bereitstellungen fügen Organisationskonfiguration, Richtlinien-Rollout, Aufzeichnungsexport, Identität und Aufbewahrung hinzu. Sie verlagern den synchronen Entscheidungspfad nicht aus der Agentenumgebung.
---
## Unterstützte Agenten
„Unterstützt“ bedeutet mehr als das Akzeptieren eines Ereignisses. Kontext dokumentiert, welche Ereignisse es empfängt, welche Ereignisse blockieren können und wie jede Integration installiert wird.
| Agent | Was Kontext aufzeichnet | Blockierung vor der Aktion | Installation |
| --- | --- | --- | --- |
| **Claude Code** | Sitzungslebenszyklus, Pre-Tool-Use, erfolgreiche und fehlgeschlagene Post-Tool-Use | Pre-Tool-Use | Installiert durch `kontext setup` |
| **Codex** | Sitzungsstart, Pre-Tool-Use, Post-Tool-Use, Prompt-Übermittlung, Stop | Pre-Tool-Use | Installiert durch `kontext setup`; Hooks müssen in Codex vertrauenswürdig sein |
| **Claude Cowork** | Claude Code-kompatible Sitzungs- und Tool-Ereignisse | Pre-Tool-Use | Konfigurieren Sie den Hook innerhalb der Cowork-Umgebung |
Siehe die [Agent-Unterstützungsmatrix](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md) für genaues Verhalten, Bereitstellungsumfang und bekannte Lücken. Sie ist die maßgebliche Quelle für die Durchsetzungsabdeckung.
---
## Kontext und Sandboxes lösen unterschiedliche Probleme
Eine Prozess-Sandbox fragt:
> Auf welche Dateien, Netzwerkziele, Anmeldedaten und Betriebssystemressourcen kann dieser Prozess zugreifen?
Kontext fragt:
> Welcher Agent versucht welche Aktion, welche Richtlinie gilt, sollte die Aktion fortgesetzt werden, und welche Nachweise belegen die Entscheidung?
Kernel-Sandboxes sind starke Eindämmungsgrenzen. Kontext bietet semantische Richtlinien und Zuordnung an unterstützten Agenten- und Tool-Hooks.
Sie sind komplementär:
```text
Kontext
decides whether the action is authorized
|
v
sandbox
constrains what the process can physically access
```
Kontext beansprucht keine Isolierung auf Kernel-Ebene. Verwenden Sie eine geeignete Sandbox, wenn das Bedrohungsmodell Prozess-, Dateisystem- oder Netzwerkeindämmung erfordert.
---
## Warum nicht einfach Agenten-Protokolle sammeln?
Protokolle sagen Ihnen, was ein Agent nach einem Ereignis gemeldet hat.
Kontext erstellt eine Autorisierungsentscheidung, bevor unterstützte folgenreiche Aktionen ausgeführt werden, und verknüpft diese Entscheidung dann mit dem verfügbaren Ergebnis.
Dieser Unterschied ist wichtig bei:
- Richtlinien-Rollout;
- Vorfalluntersuchung;
- Überprüfung des Produktionszugriffs;
- Behandlung von Entwicklerausnahmen;
- Compliance- und Audit-Überprüfung.
Das Ergebnis ist nicht nur „der Agent hat ein Tool aufgerufen“. Es ist der Nachweis, was angefordert wurde, welche Richtlinie galt, ob es erlaubt wurde und was als Nächstes passierte.
---
## Kontext in Ihrer gesamten Organisation ausführen
Verwaltete Bereitstellungen fügen hinzu:
- zentral verwaltete deterministische Richtlinien;
- Unternehmensidentität und Organisationskontrollen;
- Observe-to-Enforce-Rollout;
- Unterstützung für verwaltete Agenten- und Cloud-Bereitstellung;
- Export redigierter Nachweise;
- Audit-Aufbewahrung;
- Überwachung von Bereitstellungszustand und Rückstand;
- Onboarding für Sicherheits- und Plattformteams.
Für Bereitstellungsplanung und Organisations-Onboarding kontaktieren Sie
[[email protected]](mailto:[email protected]) oder
[vereinbaren Sie ein Gespräch](https://calendar.superhuman.com/book/11W5Y8b5JsB8dOzQbd/YECs9).
---
## Eine Installation diagnostizieren
```bash
kontext doctor
```
`doctor` prüft:
- installierte Agenten-Hooks;
- Daemon-Zustand und -Version;
- Zustand des verwalteten Exports;
- ausstehenden Export-Rückstand.
Es beendet sich mit einem Nicht-Null-Code, wenn eine konfigurierte Installation fehlerhaft ist.
Die Claude-Hook-Validierung akzeptiert äquivalentes Shell-Quoting, erfordert aber weiterhin die erwartete ausführbare Datei, Argumente und Ereigniseinstellungen. Die Codex-Hook-Diagnose prüft sowohl System- als auch Benutzerdateien: Eine fehlende oder leere Datei ist gültig, wenn die andere eine vollständige Installation enthält. Fehlerhafte oder unvollständige nicht-leere Dateien und widersprüchliche Installationen melden weiterhin ein fehlerhaftes Setup.
Wenn bei einem eigenen Claude-Drop-in nur Ereignisse fehlen, die von der aktuellen Version benötigt werden, benennt doctor die fehlenden Ereignisse und den bereichsspezifischen `hooks install`-Befehl. Self-Serve-Reparaturen fordern nur zur Aktualisierung der Claude-Systemdatei zur Eingabe von sudo auf; Organisationsreparaturen erfordern `sudo` mit `--scope system`. `doctor --fix` installiert Hooks nicht neu.
Wenn ein Self-Serve-Daemon veraltet ist:
```bash
kontext doctor --fix
```
Rotieren Sie das Installations-Token, indem Sie das Setup erneut ausführen:
```bash
kontext setup
```
Entfernen Sie die Self-Serve-Installation:
```bash
kontext setup --uninstall
```
---
## Datenverarbeitung
- Richtlinienentscheidungen erfolgen lokal.
- Tool-Aktivitäten und Entscheidungsnachweise werden lokal gespeichert.
- Sensible Werte werden vor der lokalen Speicherung und dem verwalteten Export redigiert.
- Kontext speichert keine Modellschlussfolgerungen oder den vollständigen Gesprächsverlauf.
- Verwaltete Bereitstellungen können redigierte Aufzeichnungen in das Organisations-Dashboard exportieren.
Siehe die [Guard-Dokumentation](https://github.com/kontext-security/kontext-cli/blob/main/docs/guard.md) für die Laufzeit- und Datengrenze.
---
## Entwicklung
```bash
go build -o bin/kontext ./cmd/kontext
go test ./...
go test -race ./...
go vet ./...
```
## Community
- Lesen Sie [SUPPORT.md](https://github.com/kontext-security/kontext-cli/blob/main/SUPPORT.md) für Support-Kanäle.
- Lesen Sie [CONTRIBUTING.md](https://github.com/kontext-security/kontext-cli/blob/main/CONTRIBUTING.md), bevor Sie einen Beitrag einreichen.
- Melden Sie Schwachstellen über unsere [Security Policy](https://github.com/kontext-security/kontext-cli/blob/main/SECURITY.md).
- Kontext wird unter der [MIT License](https://github.com/kontext-security/kontext-cli/blob/main/LICENSE) veröffentlicht.
### Authority-Bericht
`kontext report` zeigt entdeckte Agenten und Berechtigungen genau so an, wie sie zuletzt von der Cloud akzeptiert wurden. Verwenden Sie `kontext report --json` für die Rohdaten. Vor dem ersten erfolgreichen Senden meldet es keine Daten.
Setzen Sie `KONTEXT_AUTHORITY_SCAN=off` in der Daemon-Umgebung, um die Erfassung und Übertragung von Berechtigungen auf diesem Mac zu deaktivieren.