Skip to content

Product · Claude Code governance

Govern Claude Code — author policy, version it, prove it

Olivares is built Claude-first. Author the managed settings, hooks, MCP and sandbox controls that shape what Claude Code can do — as versioned, audited policy — and review how that policy compares with the configuration actually observed on your hosts. Deny-closed where it matters: the local pre-tool hook.

In the product

The Claude Code governance console

A genuine screenshot, example data. Author and version managed settings, hooks, managed-MCP and sandbox/egress controls, write Cedar/OPA policy-as-code, and review policy-versus-observed drift — every action recorded to the evidence ledger.

Real screenshot
Olivares Claude Code governance console: tabs for drift & posture, managed settings, hooks, MCP & plugins, sandbox & egress, policy-as-code and managed-agent HITL; the drift tab compares permitted policy against observed host configuration.

What you govern

Policy for every Claude Code surface

The managed surfaces Anthropic exposes, authored centrally as versioned policy — not scattered across machines.

Deny-closed at the hook

The one place Claude Code can be governed, not just watched: a local pre-tool hook that evaluates a tool call against your policy before it runs, and denies by default. Most tools only observe Claude Code after the fact.

Versioned authoring

Validate, dry-run, then publish. Every publish persists an immutable, audited revision you can roll back to — policy you can prove is in place, not policy you hope is.

Managed settings, hooks, MCP, sandbox

Author managed-settings, hooks, managed-MCP and sandbox/egress controls in one place, plus Cedar/OPA policy-as-code and human-in-the-loop approvals for managed agents.

Policy versus observed drift

Review how the policy you published compares with the configuration the read-only connectors actually observe on your hosts — drift surfaced, not assumed.

How it works

The pre-tool hook: allow, or deny-closed

A Claude Code tool call hits the local hook, which checks it against your published policy. Allowed calls proceed; disallowed ones are denied before they run. What was never executed is drawn as never-happened — not implied.

Diagram: a Claude Code PreToolUse hook routes a tool call through deny-closed policy — allowed calls proceed, denied calls (orange) are stopped, and the not-executed path is drawn dashed.
Deny-closed at the local hook. The dashed path is the call that never ran — drawn honestly.

What’s real

Authoring and versioning are live; the push-to-fleet loop is not

We are precise about this, because the difference matters:

  • Live: authoring, validation, dry-run and publish — every revision persisted immutably and audited — plus review of policy-versus-observed drift from the read-only connectors.
  • Not yet wired: automatic distribution of a published policy to every running Claude Code instance, and live managed-settings-versus-hooks drift. Olivares emits and records policy; it does not silently push configuration to agents you have not connected. That fleet-distribution loop is on the roadmap, and we do not claim it before it ships.
  • Posture: read-first and detective by default. The deny-closed gate runs in the local hook where you deploy it; Olivares does not sit inline in Claude Code’s data path.

Claude Code governance — questions

Does Olivares enforce policy on Claude Code that is already running?

Where you deploy the local pre-tool hook, yes — it evaluates a tool call against your published policy and denies by default before the call runs. What is not yet automated is pushing a freshly published policy out to every running instance across your fleet; today Olivares authors, versions and records policy, and reviews observed drift. Automatic fleet-wide distribution is on the roadmap, and we do not claim it before it ships.

Why is this Claude-specific?

Because Claude Code exposes managed surfaces — managed settings, hooks, managed-MCP, sandbox — that can actually be governed. Olivares authors policy against exactly those surfaces. Most tooling can only observe an agent after the fact; the local hook is the seam where a decision can be made before a tool runs.

What is “policy versus observed drift”?

The drift view compares the policy you permitted against the host configuration the read-only connectors actually observe, and surfaces the gaps. It is a review surface fed by read-only signals — not a claim that Olivares rewrote anything on your hosts.

Is any of this behind a licence?

No. Claude Code governance is part of the open-core product under AGPL-3.0, self-hosted. The commercial and enterprise tiers add support and scale, not a paywall on the core.

Govern your Claude Code fleet

Deploy Olivares on your own infrastructure, author your managed policy as versioned, audited revisions, and gate tool calls deny-closed at the hook.