OpenClaw Architecture and Trust Boundaries

Overview

This series explains how OpenClaw’s Gateway keeps channels, sessions, runtimes, tools, memory, automations, and nodes under one control plane. It follows a message from admission through execution and delivery, then examines extension contracts, durable memory, future work, and layered trust controls. The result is a practical way to judge when centralized continuity fits and when separate boundaries are required.

Learning outcomes

OpenClaw’s Gateway is the durable owner of channels, sessions, tools, events, credentials, and policy.
Admission, routing, queueing, execution, persistence, and delivery are separate facts in one controlled turn.
Plugins extend capabilities through contracts, but native plugins run in the Gateway process and are not sandboxed.
Memory, standing intents, automations, and task records preserve different kinds of state rather than one undifferentiated history.
OpenClaw fits a trusted personal operator or mutually trusting team; adversarial tenants require separate Gateway boundaries.

Keywords

OpenClawGatewaySessionsRoutingPluginsToolsMemoryAutomationsSandboxingPairing

Chapters

OpenClaw Gateway Control Plane

Why one owner can unify channels, devices, and state

8 min · Why one owner can unify channels, devices, and state

8 min

OpenClaw Routing, Sessions, and Agent Loops

How admission and queueing shape each stateful turn

11 min · How admission and queueing shape each stateful turn

11 min

OpenClaw Plugins, Tools, and Skills

How extensions declare ownership before runtime code runs

11 min · How extensions declare ownership before runtime code runs

11 min

OpenClaw Memory, Intents, and Automations

How provenance gates recall and schedules trigger future work

13 min · How provenance gates recall and schedules trigger future work

13 min

OpenClaw Security Boundaries and Sandboxing

How identity, tools, placement, approvals, and secrets differ

13 min · How identity, tools, placement, approvals, and secrets differ

13 min

Operating OpenClaw as Bounded Infrastructure

How trust, capability, state, and recovery shape deployment

10 min · How trust, capability, state, and recovery shape deployment

10 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-6 Premium

FAQ

What is OpenClaw’s Gateway?

OpenClaw’s Gateway is the long-lived control plane that owns channels, sessions, tools, events, credentials, configuration, and delivery. Clients, nodes, runtimes, and plugins connect through it rather than becoming competing state owners.

How does OpenClaw turn a message into an action?

OpenClaw turns a message into an action by admitting the sender and conversation, selecting an agent and session, queueing a run, executing tools under policy, and persisting and delivering the result. Execution, persistence, and delivery can still fail independently.

How does OpenClaw memory differ from automation?

OpenClaw memory preserves selected past knowledge, while automations and standing intents preserve authority for future time- or event-based work. Memory uses staged, provenance-aware recall; scheduled runs and intents have explicit lifecycle and delivery records.

Is OpenClaw isolated by default?

No. OpenClaw’s native plugins run in the Gateway process, and sandboxing is off by default; tool policy, placement, approvals, and SecretRefs address different exposure paths. One Gateway is documented as a trust domain for one operator or mutually trusting team, not hostile tenants.