Zum Inhalt springen

Produkt · Claude Code Governance

Claude Code steuern — Richtlinien erstellen, versionieren, nachweisen

Olivares ist Claude-first konzipiert. Erstellen Sie die Managed Settings, Hooks, MCP- und Sandbox-Kontrollen, die festlegen, was Claude Code tun kann — als versionierte, revisionssichere Richtlinie — und prüfen Sie, wie diese Richtlinie mit der Konfiguration übereinstimmt, die tatsächlich auf Ihren Hosts beobachtet wird. Deny-closed dort, wo es zählt: am lokalen Pre-Tool-Hook.

Im Produkt

Die Governance-Konsole für Claude Code

Ein echter Screenshot, Beispieldaten. Erstellen und versionieren Sie Managed Settings, Hooks, Managed-MCP- sowie Sandbox-/Egress-Kontrollen, schreiben Sie Policy-as-Code mit Cedar/OPA und prüfen Sie die Abweichung zwischen Richtlinie und beobachtetem Zustand — jede Aktion wird im Evidence Ledger protokolliert.

Echter Screenshot
Olivares Governance-Konsole für Claude Code: Tabs für Drift & Posture, Managed Settings, Hooks, MCP & Plugins, Sandbox & Egress, Policy-as-Code und Managed-Agent-HITL; der Drift-Tab vergleicht die erlaubte Richtlinie mit der beobachteten Host-Konfiguration.

Was Sie steuern

Richtlinien für jede Claude-Code-Oberfläche

Die von Anthropic bereitgestellten Managed-Oberflächen, zentral als versionierte Richtlinie erstellt — nicht über die Maschinen verstreut.

Deny-closed am Hook

Der eine Punkt, an dem Claude Code gesteuert und nicht nur beobachtet werden kann: ein lokaler Pre-Tool-Hook, der einen Tool-Aufruf vor der Ausführung gegen Ihre Richtlinie prüft und ihn standardmäßig verweigert. Die meisten Tools beobachten Claude Code nur im Nachhinein.

Versioniertes Erstellen

Validieren, einen Dry-Run durchführen, dann veröffentlichen. Jede Veröffentlichung speichert eine unveränderliche, revisionssichere Revision, auf die Sie zurückrollen können — eine Richtlinie, deren Wirksamkeit Sie nachweisen können, statt einer, auf die Sie nur hoffen.

Managed Settings, Hooks, MCP, Sandbox

Erstellen Sie Managed Settings, Hooks, Managed-MCP- und Sandbox-/Egress-Kontrollen an einer Stelle, ergänzt um Policy-as-Code mit Cedar/OPA und Human-in-the-Loop-Freigaben für Managed Agents.

Abweichung zwischen Richtlinie und beobachtetem Zustand

Prüfen Sie, wie die von Ihnen veröffentlichte Richtlinie mit der Konfiguration übereinstimmt, die die schreibgeschützten Connectoren tatsächlich auf Ihren Hosts beobachten — Abweichungen werden sichtbar gemacht, nicht angenommen.

So funktioniert es

Der Pre-Tool-Hook: erlauben oder deny-closed

Ein Tool-Aufruf von Claude Code trifft auf den lokalen Hook, der ihn gegen Ihre veröffentlichte Richtlinie prüft. Erlaubte Aufrufe laufen weiter; nicht erlaubte werden vor der Ausführung verweigert. Was nie ausgeführt wurde, wird als nie geschehen dargestellt — nicht nur angedeutet.

Diagramm: Ein PreToolUse-Hook von Claude Code leitet einen Tool-Aufruf durch eine Deny-closed-Richtlinie — erlaubte Aufrufe laufen weiter, verweigerte Aufrufe (orange) werden gestoppt, und der nicht ausgeführte Pfad ist gestrichelt gezeichnet.
Deny-closed am lokalen Hook. Der gestrichelte Pfad ist der Aufruf, der nie lief — ehrlich dargestellt.

Was real ist

Erstellung und Versionierung sind live; die Push-to-Fleet-Schleife noch nicht

Wir sind hier präzise, denn der Unterschied ist entscheidend:

  • Live: Erstellung, Validierung, Dry-Run und Veröffentlichung — jede Revision unveränderlich gespeichert und revisionssicher protokolliert — sowie die Prüfung der Abweichung zwischen Richtlinie und beobachtetem Zustand aus den schreibgeschützten Connectoren.
  • Noch nicht angebunden: die automatische Verteilung einer veröffentlichten Richtlinie an jede laufende Claude-Code-Instanz sowie der Live-Abgleich zwischen Managed Settings und Hooks. Olivares erzeugt und protokolliert Richtlinien; es schiebt keine Konfiguration stillschweigend an Agents, die Sie nicht verbunden haben. Diese Fleet-Distribution-Schleife steht auf der Roadmap, und wir behaupten sie nicht, bevor sie ausgeliefert ist.
  • Posture: standardmäßig read-first und erkenntnisorientiert. Das Deny-closed-Gate läuft im lokalen Hook, dort wo Sie ihn ausrollen; Olivares sitzt nicht inline im Datenpfad von Claude Code.

Claude Code Governance — Fragen

Erzwingt Olivares Richtlinien für bereits laufendes Claude Code?

Dort, wo Sie den lokalen Pre-Tool-Hook ausrollen, ja — er prüft einen Tool-Aufruf gegen Ihre veröffentlichte Richtlinie und verweigert ihn vor der Ausführung standardmäßig. Noch nicht automatisiert ist das Ausrollen einer frisch veröffentlichten Richtlinie an jede laufende Instanz Ihrer Flotte; heute erstellt, versioniert und protokolliert Olivares Richtlinien und prüft beobachtete Abweichungen. Die automatische flottenweite Verteilung steht auf der Roadmap, und wir behaupten sie nicht, bevor sie ausgeliefert ist.

Warum ist das Claude-spezifisch?

Weil Claude Code Managed-Oberflächen bereitstellt — Managed Settings, Hooks, Managed-MCP, Sandbox —, die sich tatsächlich steuern lassen. Olivares erstellt Richtlinien genau gegen diese Oberflächen. Die meisten Tools können einen Agent nur im Nachhinein beobachten; der lokale Hook ist die Nahtstelle, an der eine Entscheidung getroffen werden kann, bevor ein Tool läuft.

Was bedeutet „Abweichung zwischen Richtlinie und beobachtetem Zustand“?

Die Drift-Ansicht vergleicht die von Ihnen erlaubte Richtlinie mit der Host-Konfiguration, die die schreibgeschützten Connectoren tatsächlich beobachten, und macht die Lücken sichtbar. Es ist eine Prüfoberfläche, gespeist aus schreibgeschützten Signalen — keine Behauptung, dass Olivares etwas auf Ihren Hosts umgeschrieben hätte.

Steht etwas davon hinter einer Lizenz?

Nein. Claude Code Governance ist Teil des Open-Core-Produkts unter AGPL-3.0, selbstgehostet. Die Commercial- und Enterprise-Stufen ergänzen Support und Skalierung, keine Paywall auf den Kern.

Steuern Sie Ihre Claude-Code-Flotte

Setzen Sie Olivares auf Ihrer eigenen Infrastruktur ein, erstellen Sie Ihre Managed-Richtlinie als versionierte, revisionssichere Revisionen und sperren Sie Tool-Aufrufe mit Deny-closed am Hook.