> ## Documentation Index
> Fetch the complete documentation index at: https://executioncontrolprotocol.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ECP vs OpenClaw: Execution Control Protocol compared

> A technical comparison of ECP (Execution Control Protocol) and OpenClaw: execution boundaries, host security mirror, tool gates, secret namespaces, and operational risk.

# ECP (Execution Control Protocol) vs OpenClaw

Agent frameworks like OpenClaw make it easier to build systems that **plan and act**: long-running agents, tool use, and autonomous execution.

**ECP (Execution Control Protocol)** focuses on something slightly less exciting, but usually more important in production: **what is allowed to execute, under what constraints, and how that is enforced**.

## What OpenClaw does well

OpenClaw (and similar agent frameworks) are strong when you need:

* **Persistent agents** that can keep state and operate over time
* **Tooling and environment access** to get work done
* **Dynamic planning** based on intermediate results

## Where execution risk concentrates

Once an agent can take actions, errors stop being “wrong answers” and start being “real consequences.”

### Side effects are the hard boundary

Common failure modes for execution-heavy agents include:

* Calling APIs with the right schema but the wrong intent
* Making repeated or escalating tool calls
* Writing to files or systems in ways you didn’t anticipate

### Guardrails can be bypassable

If enforcement depends on prompts or agent behavior, it can drift over time (or be manipulated). Production systems typically need guardrails that are **consistent and non-bypassable**.

## What ECP adds

ECP (Execution Control Protocol) treats execution as a first-class boundary by defining:

* **Explicit, structured action requests**
* **Centralized policy enforcement** (default-deny, allowlists, budgets)
* **Write controls** and approval requirements
* **Auditable execution** (traces you can review after the fact)

ECP doesn’t try to replace an agent framework. It gives you a control layer you can put *around* the parts that actually touch the world.

## Where ECP’s security model differs (and why it matters next to OpenClaw)

Frameworks like OpenClaw excel at **agent behavior**: prompts, tools, memory, and planning loops. Production risk, though, usually shows up in **what the process is allowed to wire and call**, not only in what the prompt says. ECP adds a **host-level contract** that is intentionally separate from the agent runtime:

* **`ecp.config.yaml` and the `security` mirror (v0.5+)** — Wiring (models, MCP servers, loggers, secrets providers, …) lives next to a parallel **`security`** tree that only contains **allow-lists and defaults**. Even if a Context or a planner “wants” a provider or server, the host can refuse to enable it. That is policy in configuration and loaders, not a suggestion the model might ignore or negotiate.
* **Two-stage tool exposure** — Context **`policies.toolAccess`** applies default-deny and fine-grained tool allowlists **per executor**. **`security.tools.allowServers`** (and configured **`tools.servers`**) caps which MCP server **names** may exist on the machine. A portable manifest cannot conjure a server the operator never installed or allow-listed.
* **Explicit secret namespaces** — Credentials resolve from named providers (`process.env`, `dot.env`, `os.secrets`, …). Loading a `.env` file for **`dot.env`** does **not** merge into the global process environment, which avoids the common foot-gun of “one file accidentally expanded the blast radius for every child process.”
* **Extension surface control** — **`security.plugins`** can restrict **plugin kinds** (including **`tool`** for MCP-governed servers), **sources**, and **ids**. You can run deployments that disallow entire classes of integration without changing the agent framework.
* **Traces as an operational artifact** — Runs can emit structured traces (`ecp trace`, optional graph view) so security and platform teams can review what was attempted, not only final natural-language output.

OpenClaw (and peers) can still own **how** the agent thinks and plans; ECP is aimed at **what the execution host permits**, in a way that is reviewable, versioned, and aligned with how operators already govern services.

## Typical architecture with both

* **OpenClaw**: planning, reasoning, task decomposition, agent runtime behavior
* **ECP**: execution environment definition, host allow-lists, per-executor policies, constraints, audit trail

## When to reach for ECP

ECP is especially useful when:

* You need **consistent policies** across many tools and services.
* You want to limit blast radius with budgets and explicit permissions.
* You’re operating with sensitive data or regulated workflows.
* You want a clean separation: “decide what to do” vs “decide what is allowed.”

## Next steps

* Read [Core concepts](/learn/concepts) for Contexts, mounts, and policies.
* See how ECP complements tool calling in [Relationship to MCP](/learn/relationship-to-mcp).
* For the host `security` mirror, secret namespaces, and full **`ecp.config.yaml`** spec, read [Security](/learn/security), the [Schema reference](/reference/schema#system-configuration) section on system config, and the [SPEC.md host section](https://github.com/executioncontrolprotocol/executioncontrolprotocol/blob/main/SPEC.md#L623) on GitHub.