OpenClaw Architecture Part 5: Tools, Plugins, and Capability Boundaries

Original article: OpenClaw Architecture - Part 5: Tools, Plugins, and Capability Boundaries

Processed: 2026-03-23

Summary

Main Thesis

When an AI agent gains the ability to call tools, the important question shifts from "what did the model say?" to "what will the system do on its behalf?" OpenClaw's architecture makes capability boundaries explicit and distinct from mere prompt guidance — real enforcement lives in tool policy, approvals, sandboxing, and channel controls, not in the model's self-description.

Key Argument

The author frames tools as where "chat stops being chat and starts becoming action." A model produces text; a tool produces reality. This distinction underpins the entire analysis of how OpenClaw structures its capability surface.

Key Findings

Tool Profiles & Policy

OpenClaw provides named tool profiles: minimal, coding, messaging, and full
Further scoping via tools.allow and tools.deny — deny always wins
Disallowed tools are never sent to model providers at all

Capability Tiers (not a flat tool list)

Browser: Three distinct profiles with different inherited state and authority — openclaw (isolated, managed), user (attaches to a real signed-in Chrome session), chrome-relay (extension relay mode). Same tool label, very different consequences.
Exec: host=sandbox, host=gateway, host=node are different execution targets with escalating blast radius — not implementation details.
Session Tools: sessions_list, sessions_history, sessions_send, sessions_spawn are routing power. Session visibility scope is configurable: self, tree, agent, or all.
Nodes: Companion devices expose command families (canvas., camera., device., notifications., system.*) — extending the same agent loop to physical hardware.

Session Ownership vs Authorization

A sessionKey is for routing and context isolation — not per-user authorization
If multiple people steer one tool-enabled agent, they share one permission surface regardless of session isolation
Memory isolation helps with privacy, not with authorization

Plugins = Trusted Gateway Code

Plugins run in-process with the Gateway — not sandboxed
They can register tools, hooks, HTTP routes, Gateway methods, commands, services, context engines, skills, auto-reply commands
Installation and enablement are trust-sensitive operations
plugins.allow is useful, but id-based trust is not the same as provenance-based trust

Approvals as Interlocks, Not Absolution

Approvals slow down real-world actions at the edge where it matters
They do not turn a broad capability surface into a narrow one

Practical Takeaways

Start with the smallest tool profile that still works for your use case
Treat sessionKey and Memory isolation as routing and privacy boundaries — not authorization
Choose execution targets explicitly: managed browser vs. attached browser, sandbox vs. gateway host vs. node host
Keep broad control surfaces off untrusted inputs unless you really mean it
Treat plugins and skills as trusted Gateway code — not optional add-ons
Use approvals as interlocks, not substitutes for scoping
Put lifecycle events, hooks, and logs around capability use for auditability

The Four Boundary Questions

The author proposes a simple audit framework:

Who can talk to it? pairing, allowlists, group policy, shared tool surfaces
Where can it act? browser profile, execution host, node availability
What can it touch? tool profiles, deny rules, session visibility, node permissions
What code did I load? plugins, skills, route handlers, command handlers

This replaces generic checklists with architecture-mapped questions that reflect actual enforcement points.

Context in the Series

This is Part 5 of a multi-part OpenClaw architecture series. Part 1 covered why the agent feels "alive" (more inputs, durable state, loop). Part 5 is where the loop becomes consequential via tools. Part 6 (upcoming) covers observability, recovery, evaluation, and containment.