Governing Claude Code itself

The clearest proof of a governance layer is to point it at a real agent doing real work. So Starfish now governs Claude Code through its hooks: a resident, fail-closed Policy Decision Point that adjudicates every tool call before it runs. Kill the daemon and tool calls are denied, not allowed, because failing open would let an attacker simply turn governance off.

We mapped Claude Code's native tools onto the governed vocabulary and watched it work against the live daemon: reading a project file is allowed, editing asks for approval, writing outside the project or into the governance directory is denied, a benign shell command asks while rm -rf / is denied outright, and an unknown tool hits default-deny.

A lockdown the agent cannot undo

The strongest deployment uses Claude Code's own managed-settings layer, a root-owned file that user and project settings cannot override. With it, only Starfish's hooks load, no user permission rule can pre-authorize a tool, and bypass mode is disabled. We then went looking for the lockdown's own weaknesses and closed them: absolute binary paths so PATH cannot be hijacked, environment scrubbing against loader injection, a governed-projects registry so deleting the governance folder cannot quietly downgrade a project, and a config-drift tripwire that drops the daemon into safe mode the moment the settings change.

We verified the mechanism on a live Claude Code install. The deny actually blocks, it survives a co-existing allow-hook, a permission rule does not skip it, and bypass mode does not skip it. The work continues, but the thesis now runs in the open: an agent you build with, fully governed.