Produit · Gouvernance de Claude Code
Gouvernez Claude Code — rédigez la politique, versionnez-la, prouvez-la
Olivares est conçu Claude-first. Rédigez les managed settings, hooks, MCP et contrôles de sandbox qui déterminent ce que Claude Code peut faire — sous forme de politique versionnée et auditée — et examinez la façon dont cette politique se compare à la configuration réellement observée sur vos hôtes. Fermée par défaut là où c’est pertinent : le hook local de pre-tool.
Dans le produit
La console de gouvernance de Claude Code
Une capture d’écran authentique, avec des données d’exemple. Rédigez et versionnez managed settings, hooks, managed-MCP et contrôles de sandbox/egress, écrivez de la policy-as-code Cedar/OPA et examinez la dérive politique-vs-observé — chaque action consignée dans le registre de preuves.
Ce que vous gouvernez
Une politique pour chaque surface de Claude Code
Les surfaces managées qu’expose Anthropic, rédigées de façon centralisée sous forme de politique versionnée — et non éparpillées entre les machines.
Fermée par défaut au niveau du hook
Le seul endroit où Claude Code peut être gouverné, et pas seulement observé : un hook local de pre-tool qui évalue un appel d’outil au regard de votre politique avant son exécution, et qui refuse par défaut. La plupart des outils se contentent d’observer Claude Code après coup.
Rédaction versionnée
Validez, exécutez en dry-run, puis publiez. Chaque publication enregistre une révision immuable et auditée vers laquelle vous pouvez revenir — une politique dont vous pouvez prouver qu’elle est en place, et non une politique dont vous espérez qu’elle l’est.
Managed settings, hooks, MCP, sandbox
Rédigez managed-settings, hooks, managed-MCP et contrôles de sandbox/egress au même endroit, ainsi que la policy-as-code Cedar/OPA et les approbations human-in-the-loop pour les agents managés.
Dérive politique-vs-observé
Examinez la façon dont la politique que vous avez publiée se compare à la configuration que les connecteurs read-only observent réellement sur vos hôtes — la dérive est mise en évidence, et non supposée.
Comment ça marche
Le hook de pre-tool : autoriser, ou refuser par défaut
Un appel d’outil de Claude Code atteint le hook local, qui le confronte à votre politique publiée. Les appels autorisés se poursuivent ; ceux qui ne le sont pas sont refusés avant leur exécution. Ce qui n’a jamais été exécuté est représenté comme n’ayant jamais eu lieu — sans le sous-entendre.
Ce qui est réel
La rédaction et le versionnage sont live ; la boucle de diffusion vers le parc ne l’est pas
Nous sommes précis sur ce point, car la différence compte :
- Live : rédaction, validation, dry-run et publication — chaque révision persistée de façon immuable et auditée — ainsi que l’examen de la dérive politique-vs-observé issue des connecteurs read-only.
- Pas encore câblé : la distribution automatique d’une politique publiée à chaque instance de Claude Code en cours d’exécution, ainsi que la dérive en direct entre managed-settings et hooks. Olivares émet et consigne la politique ; il ne pousse pas silencieusement de configuration vers des agents que vous n’avez pas connectés. Cette boucle de distribution au parc figure sur la roadmap, et nous ne la revendiquons pas avant qu’elle ne soit livrée.
- Posture : read-first et détective par défaut. La barrière fermée par défaut s’exécute dans le hook local là où vous le déployez ; Olivares ne s’interpose pas dans le chemin de données de Claude Code.
Gouvernance de Claude Code — questions
Olivares applique-t-il une politique sur le Claude Code déjà en cours d’exécution ?
Là où vous déployez le hook local de pre-tool, oui — il évalue un appel d’outil au regard de votre politique publiée et refuse par défaut avant l’exécution de l’appel. Ce qui n’est pas encore automatisé, c’est la diffusion d’une politique fraîchement publiée vers chaque instance en cours d’exécution de tout votre parc ; aujourd’hui, Olivares rédige, versionne et consigne la politique, et examine la dérive observée. La distribution automatique à l’ensemble du parc figure sur la roadmap, et nous ne la revendiquons pas avant qu’elle ne soit livrée.
Pourquoi est-ce spécifique à Claude ?
Parce que Claude Code expose des surfaces managées — managed settings, hooks, managed-MCP, sandbox — qui peuvent réellement être gouvernées. Olivares rédige la politique précisément au regard de ces surfaces. La plupart des outils ne peuvent qu’observer un agent après coup ; le hook local est la jointure où une décision peut être prise avant qu’un outil ne s’exécute.
Qu’est-ce que la « dérive politique-vs-observé » ?
La vue de drift compare la politique que vous avez autorisée à la configuration de l’hôte que les connecteurs read-only observent réellement, et met en évidence les écarts. C’est une surface d’examen alimentée par des signaux read-only — et non une affirmation selon laquelle Olivares aurait modifié quoi que ce soit sur vos hôtes.
Une partie de tout cela est-elle soumise à une licence ?
Non. La gouvernance de Claude Code fait partie du produit open-core sous AGPL-3.0, en auto-hébergement. Les paliers commercial et enterprise ajoutent du support et de la mise à l’échelle, et non un péage sur le cœur du produit.
Gouvernez votre parc Claude Code
Déployez Olivares sur votre propre infrastructure, rédigez votre politique managée sous forme de révisions versionnées et auditées, et filtrez les appels d’outil de façon fermée par défaut au niveau du hook.