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 Agent, Sitzung, Aktion, Richtlinienentscheidung und 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.

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

brew install kontext-security/tap/kontext

Diesen Mac verbinden

Erstellen Sie ein Installations-Token im Kontext-Dashboard und führen Sie dann aus:

kontext setup

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:

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 wird eine Agent-Aktion ausgeführt, bevor ein Sicherheitsteam ihre Protokolle überprüfen kann:

agent requests an action
        |
        v
action executes
        |
        v
activity appears in a log

Mit Kontext:

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 diese definieren:

• destruktive Befehle;
• Zugriff auf sensible Dateien;
• Operationen auf Produktionssystemen;
• Zugriff auf Anmeldedaten;
• Datenexporte.

Die Durchsetzung ist bewusst auf Ereignisoberflächen beschränkt, an denen der Agent auf Kontext wartet, bevor er fortfährt. Kontext behauptet nicht, dass der Empfang eines Ereignisses bedeutet, jede Aktion dieses Agenten stoppen zu können.

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 verfügbare Eingaben;
• 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 nicht die Modellschlussfolgerung oder rekonstruiert den vollständigen Gesprächsverlauf.

Verwaltete Bereitstellungen können redigierte Aufzeichnungen in das Kontext-Dashboard exportieren für organisationsweite Überprüfung, Aufbewahrung und Untersuchung.

Richtlinien dort, wo der Agent läuft

Der Entscheidungspfad bleibt lokal:

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 Agent-Umgebung.

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.

Siehe die Agent-Unterstützungsmatrix 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 Agent- und Tool-Hooks.

Sie sind komplementär:

Kontext
  decides whether the action is authorized
              |
              v
sandbox
  constrains what the process can physically access

Kontext beansprucht keine Kernel-Level-Isolierung. Verwenden Sie eine geeignete Sandbox, wenn das Bedrohungsmodell Prozess-, Dateisystem- oder Netzwerkeindämmung erfordert.

Warum nicht einfach Agent-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 Agent- und Cloud-Bereitstellungen;
• 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] oder vereinbaren Sie ein Gespräch.

Eine Installation diagnostizieren

kontext doctor

doctor prüft:

• installierte Agent-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.

Wenn ein Self-Serve-Daemon veraltet ist:

kontext doctor --fix

Rotieren Sie das Installations-Token, indem Sie das Setup erneut ausführen:

kontext setup

Self-Serve-Installation entfernen:

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 vollständigen Gesprächsverläufe.
• Verwaltete Bereitstellungen können redigierte Aufzeichnungen in das Organisations-Dashboard exportieren.

Siehe die Guard-Dokumentation für die Laufzeit- und Datengrenze.

Entwicklung

go build -o bin/kontext ./cmd/kontext
go test ./...
go test -race ./...
go vet ./...

Community

• Lesen Sie SUPPORT.md für Support-Kanäle.
• Lesen Sie CONTRIBUTING.md, bevor Sie einen Beitrag einreichen.
• Melden Sie Schwachstellen über unsere Security Policy.
• Kontext wird unter der MIT License veröffentlicht.

Authority-Bericht

kontext report zeigt entdeckte Agenten und Authority 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 Authority-Erfassung und -Übertragung auf diesem Mac zu deaktivieren.