How to Govern Muse Code in the Enterprise with OpenBox

By Tahir Mahmood, Co-founder & CTO, OpenBox · Last updated 12 October 2026

In brief: Muse Code gives developers 15 hook events for external oversight but ships no policy engine, attestation, or audit trail. OpenBox plugs that gap: it registers as Muse Code's hook handler, evaluates every tool call and model request against centrally managed policies, and seals each session with a signed proof certificate. The result is governed, auditable AI-assisted development from the first commit.

What Muse Code Exposes and What It Leaves to You

Muse Code exposes 15 documented hook events that let external programs inspect tool calls, prompts, and model requests before or after they execute. But Muse ships no built-in policy engine, no session attestation, and no tamper-evident audit trail. Those gaps are by design: Muse delegates enforcement to external tools.

The 15 events span the full session lifecycle. PreToolUse, PostToolUse, and PostToolUseFailure fire around every tool call. UserPromptSubmit fires when a developer sends a prompt. PermissionRequest fires when a tool needs explicit approval. SessionStart, Stop, and SessionEnd mark session boundaries. SubagentStart and SubagentStop track child agents. PreCompact and PostCompact fire around context-window compaction. Notification fires on system-level messages. PreLLMCall and PostLLMCall expose model requests before they leave the machine.

Four of those events are gated, meaning an external handler can deny the action. PreToolUse, UserPromptSubmit, PermissionRequest, and PreLLMCall each support guard evaluation with an optional deny response. The remaining events are informational: they notify the handler but do not wait for a verdict. Muse exposes two additional event types, PostToolBatch and Interrupt, but PostToolBatch never fires in the current release and Muse refuses a synchronous handler for Interrupt, so OpenBox deliberately does not install handlers for either.

One limitation is worth noting. PermissionRequest does not fire when Muse's built-in approval judge or the --yolo flag auto-clears a tool call. This makes PermissionRequest a partial record of approvals, not a complete one. Security teams should treat it as supplementary evidence rather than a definitive log of every permission grant.

This design gives governance tools a clear surface to work with. But it also means that without an external handler registered, every tool call and model request proceeds unchecked. Muse fails open by design: if a hook handler crashes, times out, or returns invalid output, the action goes through. A payload larger than 256 KiB is never delivered to any hook at all, so that action cannot be gated.

For enterprise security teams, the takeaway is straightforward. Muse Code provides the hooks. It does not provide the governance. That is the layer OpenBox adds.

How OpenBox Registers as the Governance Layer

OpenBox installs as a single static Go binary. Two commands register it as Muse Code's hook handler: openbox auth links the binary to the organisation's OpenBox platform account, and openbox init --provider muse writes the hook configuration into Muse Code's settings file at ~/.config/muse/settings.json. From that point, every gated event routes through the OpenBox platform for policy evaluation before the action proceeds.

No policy files are stored on the developer's machine. Every gated event is evaluated by the platform, where security teams define and update policies centrally. This eliminates the risk of local policy files drifting across developer environments or being silently bypassed.

OpenBox captures Muse Code activity through three channels. The telemetry lane, a local OTLP receiver, records model names, token counts, and timing from Muse's own telemetry output. The model-call gate, Muse's PreLLMCall hook, lets the platform evaluate each model request before it is sent. Muse Code does not route traffic through OpenBox's transport proxy and rejects the proxy's local CA certificate, so model-call visibility relies on telemetry and the pre-send gate rather than on HTTPS interception.

OpenBox also backs Muse's fail-open behaviour with a deny-only fallback handler on every hook. If the platform is unreachable, the hook returns a non-zero exit code, and the action is denied for that individual call. The next call gets a fresh attempt. This means that a network outage blocks one action at a time rather than halting the entire session or letting everything through silently.

A key design principle is that the OpenBox adapter can only tighten Muse's own controls, never loosen them. The adapter writes a deny or block response, or writes nothing at all; it never writes an allow or continue response. This means that OpenBox can add restrictions on top of Muse's built-in approval layer but cannot override it. Hooks run outside Muse's approval layer entirely, so they are not bypassed by the --yolo flag or by Muse's approval judge. Even when a developer enables --yolo to auto-approve tool calls, OpenBox's policy evaluation still runs on every gated event.

Five Governance Decisions at the Hook

When a gated event fires, the OpenBox platform evaluates it against centrally managed OPA/Rego policies and returns one of five governance decisions: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK, or HALT. Each decision executes before the tool call or model request reaches its target.

ALLOW lets the action proceed without interruption. CONSTRAIN executes the action within a sandboxed environment rather than allowing or refusing it outright. REQUIRE_APPROVAL pauses the call while a designated approver reviews it on the OpenBox dashboard; in Muse Code, this renders as a plain refusal because Muse cannot hold the session open for an asynchronous approval flow. BLOCK refuses the individual call and returns the policy's reason to the developer. HALT refuses the current action and every subsequent tool call and prompt in the session, enforced locally without further platform contact.

These policies are not limited to simple allow-or-deny rules. The OpenBox governance stack includes three layers. OPA/Rego policies handle stateless, per-event evaluation. Behavioural Rules track patterns across multiple events within a session, such as detecting repeated attempts to access a restricted resource. Guardrails provide content-level checks including PII detection, content filtering, toxicity screening, and banned-word enforcement.

CONSTRAIN is distinct from the other four: rather than allowing or refusing an action outright, it executes the action within a sandboxed environment. For example, a policy could strip sensitive fields from a tool call's input or limit which resources the action can reach, enforcing data boundaries without blocking the developer's workflow.

Sealed Proof: Attestation and the Session Audit Trail

Every governed Muse Code session produces a digitally signed proof certificate. OpenBox builds a SHA-256 Merkle tree from all session events, then signs the root using AWS KMS with an ECDSA NIST P-256 key, or through an external attestation endpoint if one is configured. The certificate creates tamper-evident evidence that auditors can verify independently without replaying the session.

Each governed agent carries a decentralised identifier (DID) in the format did:aip:<uuidv5>, paired with an Ed25519 signing key provisioned through the OpenBox platform under Settings > API Access. The private key is shown once at provisioning and is not stored by OpenBox. This identity anchors every session event to a specific agent instance, so the proof certificate ties not just to a session but to the agent that ran it.

The OpenBox platform assigns each agent a Trust Score on a 0 to 100 scale. The score combines three weighted components: Risk Profile (40%), Behavioural assessment (35%), and Alignment (25%). Agents fall into trust tiers based on their score: Tier 1 Trusted (90 to 100), Tier 2 Confident (75 to 89), Tier 3 Monitor (50 to 74), Tier 4 Restrict (25 to 49), and Untrusted (0 to 24). Security teams can tie governance policies to these tiers, applying stricter controls as trust decreases.

For organisations subject to audit requirements, the combination of per-session proof certificates and per-agent trust scoring provides two distinct evidence streams. The proof certificate answers "what happened in this session and can we verify it?" The Trust Score answers "how much autonomy should this agent have, and is that justified?"

Commit-to-Session Lineage

OpenBox traces every AI-assisted commit back to the Muse Code session that produced it. When a governed session creates a commit, the prepare-commit-msg git hook stamps the commit with an OpenBox-Session trailer linking it to the session identifier. The post-commit hook then sends a CommitCreated event into the session's event stream. For Muse Code specifically, the MUSE_TOOL_USE_ID environment variable links each commit to the tool-use action that generated it.

The platform records the full lineage chain: projects, repository agents, runtimes, lifecycle events, governance snapshots, and session evidence. When a Muse Code session spawns subagents, the subagent's activity is folded into the parent session and tagged with the subagent's agent id and type, so the lineage chain reflects the full hierarchy of work without scattering events across separate records. This gives security teams code-to-runtime traceability. For any deployed change, they can answer: which agent produced this commit, under which policies, and what tool calls led to it?

The OpenBox Trust Lifecycle organises this traceability into five continuous phases: Assess, Authorize, Monitor, Verify, and Adapt. Each phase feeds into the next. Assess evaluates the agent's risk profile before it begins work. Authorize grants permissions based on the agent's trust tier. Monitor captures runtime behaviour through hook events and telemetry. Verify seals the session with a proof certificate. Adapt updates the agent's Trust Score based on observed behaviour, which then informs the next Assess phase.

What This Means for Your Security Team

For CISOs and governance leads evaluating Muse Code for enterprise use, the OpenBox integration closes three gaps at once: policy enforcement at the hook level, tamper-evident session records, and commit-level traceability. Setup takes two commands per developer machine. Policies are managed centrally and never stored locally.

There are practical considerations to keep in mind. Muse Code fails open by default, meaning a hook crash or timeout lets the action through. OpenBox hardens this with a deny-only fallback, but payloads over 256 KiB still bypass hooks entirely because Muse never delivers them to a handler. Security teams should account for this when defining their risk posture.

The OpenBox platform provides capabilities that organisations can use toward their compliance obligations, including signed session evidence, agent identity, and auditable policy enforcement. It does not itself certify compliance with any specific regulatory framework.

OpenBox launched publicly on 31 March 2026. Muse Code entered beta on 5 August 2026. The integration is available today for organisations running both tools.

Frequently Asked Questions

Does OpenBox require changes to Muse Code's source code?

No. OpenBox registers as an external hook handler through Muse Code's existing hooks system. The openbox init --provider muse command writes the hook configuration into Muse Code's settings file at ~/.config/muse/settings.json. No modifications to Muse Code's own source code or binaries are needed.

What happens if the OpenBox platform is unreachable during a coding session?

OpenBox adds a deny-only fallback handler to each hook event. If the platform cannot be reached, the individual action is denied and the developer sees a delivery error. The next action gets a fresh connection attempt. The session is not halted.

How many governance decisions does OpenBox support?

Five: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK, and HALT. Each decision executes before the tool call or model request reaches its target. Policies are evaluated centrally on the OpenBox platform using OPA/Rego.