Separating Planning and Execution in LLM Agents: ArbiterOS Governance Kernel

Why Execution Rights Need a Separate Governance Layer

When agents can read code, edit files, send emails, and invoke APIs, errors that were once easy to undo in a chat become permanent actions in production systems. The core question becomes: who grants execution rights, and how can we intercept risky steps before they happen?

ArbiterOS, an open‑source project from HKU's CURE Lab, inserts a governance layer between the model’s output and the tool execution. It converts tool calls into structured Instruction objects, records data provenance and step dependencies, and lets a policy engine decide whether to allow, block, or request confirmation.

Architecture Overview

ArbiterOS fills a long‑missing layer in the agent control loop:

Agent & Model – understand the task, break it into steps, and select tools; they can also re‑plan after a block.

ArbiterOS Runtime – transforms model‑generated tool calls into Instruction, tracks source and dependencies, runs policies, and records a trace.

Tool Gateway – the actual execution point for files, databases, browsers, and external APIs.

Sandbox, IAM, Network Egress – enforce rigid permissions on what a process can read/write, which identities can act, and where network traffic may go.

Business System – handles final consistency, approval, idempotence, monitoring, compensation and rollback.

By separating planning (model) from execution (tool gateway), the execution authority no longer lives inside the same probabilistic component that decides "what to do".

Risk Resides in the Control Loop

Consider a simple task: read a test log, summarize it, and post the summary to an internal knowledge base. The agent might fetch a web page, read a local config, then issue a POST request. Individually each step looks benign, but together they can form a dangerous path: an untrusted web page influences planning, a local config leaks credentials, and a syntactically valid POST sends sensitive data outward.

Traditional applications place permission checks, transaction boundaries, and gateways around each step. Many agent systems, however, let the same language model decide both *what* to do and *when* to do it, adding only prompts, confirmation dialogs, or logs as after‑the‑fact safeguards.

High‑risk actions therefore lack an independent, deterministic control point before execution.

Prompts can express policy but are hard to enforce as hard boundaries.

Safety models can flag risk but do not have full visibility into data provenance.

Sandboxes limit process I/O but cannot infer the downstream intent of a piece of data.

Human confirmation handles critical decisions but suffers from fatigue when overused.

ArbiterOS aims to unify these mechanisms by providing a shared runtime context that records data sources, security attributes, and policy outcomes.

Separating Planning and Execution Rights

Following a real‑world call chain, responsibility is distributed across five layers:

Agent & Model – understand the task, decompose steps, choose tools, and can re‑plan after a block.

ArbiterOS – turn model output into Instruction, track provenance, run policies, and log a trace.

Tool Gateway – performs the actual file, database, browser, or API call.

Sandbox / IAM / Network Egress – enforce low‑level read/write and network restrictions.

Business System – ensures final consistency, approval, idempotence, monitoring, and rollback.

With this split, planning authority stays with the model, while execution authority is mediated by the governance layer and downstream hard‑enforcement mechanisms.

Data Flow Matters More Than Tool Names

ArbiterOS records each Instruction with rich metadata:

Tool name, arguments, and optional results.

Step relationships such as runtime_step, parent_id, source_message_id.

Security attributes: confidentiality, trust level, risk, reversibility.

Reference to upstream tool via reference_tool_id.

This enables policies to consider not only the tool but also where the data originated. For example, a low‑trust web snippet combined with a high‑confidentiality key should trigger a block even if the final POST target is whitelisted.

Control Points Must Precede Execution

A rule is only useful if it can intervene before the real action occurs. System prompts can discourage a model from choosing a risky path, but only sandbox or network policies can guarantee the process cannot read the prohibited file or open the forbidden socket.

ArbiterOS sits right before tool execution, allowing it to halt the action, log the reason, and optionally request human approval.

Traceability Requirements

ArbiterOS writes a JSON trace for each request under log/{trace_id}.json, capturing:

Input source.

Which policy rule fired.

Whether the action was actually performed.

This trace is essential for iterating policies: frequent rule hits may indicate an overly broad boundary, while many false blocks on a specific tool suggest missing context in the parser.

However, the trace only reflects what the governance layer observed; it cannot magically reconstruct side‑channel calls that bypass the layer.

Evaluation Numbers Have Limits

Using the AgentDojo and Agent‑SafetyBench benchmarks, the authors replayed 1,914 dangerous cases. With the native OpenClaw policy, the interception rate was 6.17% (118/1,914). After integrating Arbiter‑K, the rate rose to 92.95% (1,779/1,914).

For 312 benign cases, the pass‑through rate dropped from 92.95% (290/312) to 88.78% (277/312), showing a modest usability cost. Most false positives involved cross‑session delegation, calendar side‑effects, or external communication.

The authors caution that these numbers reflect a controlled replay protocol ( prior+current) and do not directly translate to production safety, where planning drift, plugin overrides, side‑channel calls, and varying network conditions exist.

Rollback Follows Fault Domains

After a policy allows an action, the system must still consider how to recover if something goes wrong. Different side‑effects belong to different fault domains:

Code changes – revert via discarding diffs or resetting commits.

Dependency updates – verify artifacts before acceptance.

Production config changes – rely on release platforms for versioned rollbacks.

Database migrations – may require compensating scripts.

Emails or external notifications – often cannot be fully undone.

Thus, governance must be coupled with appropriate rollback mechanisms for each domain.

Start with a Small Policy Table

Instead of building a massive "Agent Constitution," pick a single task chain with the highest potential side‑effects and write explicit rules for it. Example policy rows (summarized):

Read ordinary test logs – allow; trace ID, tool, and path are recorded.

Read credentials or production config – block; check call chain, data purpose, and policy version.

Write to test directory – allow; verify diff, file scope, and test command.

Delete files or data – require confirmation; evaluate target, impact, and reversibility.

Access external network – whitelist domains; inspect request parameters and data provenance.

Send email / close ticket – draft‑first; verify recipient, original input, and final state.

Production write or deploy – block or require higher‑level approval; check change‑request, version, and operator.

Running a pilot with this table yields richer metrics than a simple "blocked" count:

Tool coverage – proportion of file, network, DB, script calls that pass through the governance chain.

Block accuracy – which step stopped the over‑privileged task and why.

Benign pass‑through rate – frequency of unnecessary interruptions.

Trace completeness – ability to reconstruct input, dependencies, policy version, and confirmations.

Recovery time – how quickly the system can revert to a known good state after a mis‑step.

Tool coverage often reveals gaps earlier than block rates because many calls may bypass the governance layer entirely (e.g., direct scripts, MCP servers, host processes).

Practical Run‑Through

Read test‑environment logs and generate a summary; write it to an internal draft area, but never access credentials or send data outside the network.

Execute the task inside a sandbox without production credentials.

Route the model request through ArbiterOS; ensure tool calls are parsable and the trace links steps.

Configure four rule categories: sensitive paths, network whitelist, delete confirmation, remote‑write confirmation.

Run both a normal task and a deliberately over‑privileged variant; observe block points, false positives, and log readability.

Retain human approval and business rollback; verify both "policy‑allowed" and "action‑recoverable" outcomes.

After the trial, collect the metrics listed above to assess governance effectiveness before scaling to the full agent stack.

Conclusion

ArbiterOS demonstrates that inserting a runtime governance layer between model planning and tool execution can dramatically increase the interception of dangerous actions while keeping a manageable impact on benign workflows. However, production deployment still faces open challenges: handling side‑channel bypasses, managing policy versioning, binding identities, ensuring high availability, and defining graceful degradation when the governance service itself fails. In short, as agents acquire more tools, execution authority should reside outside the model, with intents turned into verifiable instructions, data provenance tracked, and final decisions delegated to permission systems, business logic, and humans.