OpenClaw AI

What You'll Learn

• What OpenClaw AI is, how its Gateway connects the moving parts and why it is different from a simple chat window.
• What the official security model assumes about operators, messages, tools, channels, plugins and shared access.
• How installation, onboarding, pairing, sandboxing, skills and plugins fit together in a practical deployment.
• Which checks to complete before an agent can read files, run commands, browse, send messages or act on your behalf.

What Is OpenClaw AI?

OpenClaw AI is a personal AI assistant designed to run on a user's devices and appear in the messaging channels that person already uses. The official project describes a single-operator model. Instead of treating the assistant as a website where a user sends one prompt at a time, OpenClaw connects models, tools, channels and optional companion apps through a Gateway.

That design changes the question from “Which chatbot gives the best answer?” to “Which systems can this agent reach, and under what rules?” A chat reply stays inside a conversation. An OpenClaw turn can be connected to a file tool, a browser, a shell command, a messaging channel, a device node or a plugin. The useful part is the connection. The risk lives there too.

The project supports hosted and local model providers. A model is one part of the system, not the whole system. The Gateway routes sessions and events. Tools add actions. Channels deliver messages. Skills provide instructions about when and how to use tools. Plugins add runtime surfaces such as channels, providers, tools, skills, media features and hooks.

This is why OpenClaw AI should not be described as a zero-configuration assistant. The official getting-started guide requires a model-provider API key and a Gateway onboarding process. A user must decide which channels to connect, which permissions to grant and which tools should remain unavailable.

Readers following the broader Technology category can compare this systems view with the Technology section. The practical lesson is simple. An agent is not only a model. It is a model plus a control plane, credentials, tools, data and policy.

What the OpenAI Connection Actually Means

Peter Steinberger's first-party statement, published on 14 February 2026, says that he was joining OpenAI to work on bringing agents to everyone. The same statement says OpenClaw would move to a foundation and stay open and independent. It also says OpenAI had made commitments to support his work and already sponsored the project.

That wording matters because online summaries have used stronger language. The creator's statement does not describe a conventional purchase of every OpenClaw project asset. A careful article should therefore say that the creator joined OpenAI while OpenClaw was moving toward a foundation structure and remaining open and independent.

The connection also does not mean that every OpenClaw installation automatically becomes an OpenAI product. The official OpenClaw README says the project works with hosted and local model providers. Provider choice, credentials and configuration remain deployment decisions.

It is useful to separate four claims. The creator's OpenAI move is supported by his own statement. The foundation and independence wording is also supported by that statement. OpenClaw's support for multiple model providers is documented in the project README. A claim that OpenAI acquired every project asset is not established by those primary sources.

For readers comparing technology announcements with actual product behavior, the source-first verification guide offers a similar habit. Keep the statement, the interpretation and the unsupported extension separate.

Why Does OpenClaw Use a Gateway?

The Gateway is OpenClaw's local control plane for sessions, tools, events and channel connections. It gives the system one place to route a conversation, load the relevant configuration and connect the agent to the surfaces it is allowed to use.

The official README identifies the Control UI, CLI and TUI as clients that connect to the Gateway. This arrangement is more useful than scattering separate integrations across many scripts. A single Gateway can coordinate a message arriving through a channel, the model response, a tool call and the eventual reply.

The Gateway also creates a clear security boundary for the operator to inspect. The question is not only whether a model can generate a command. The question is whether the Gateway policy permits that command, whether the execution host is the local machine or a sandbox, whether the channel sender is allowed and whether the resulting data can leave through a connected channel.

The official getting-started guide says the Gateway should be listening on port 18789 after setup. That number is a setup check, not a reason to expose the port publicly. Network binding, authentication and remote access must be reviewed against the security guide.

What Are Channels, Tools, Skills and Plugins?

OpenClaw uses several extension concepts, and mixing them together makes configuration harder to audit. Channels are message transports. Tools are capabilities the agent can call. Skills are Markdown instruction files that teach the agent how and when to use tools. Plugins are runtime extensions that can add channels, model providers, tools, skills, media capabilities, hooks and other surfaces.

The official channel overview lists Telegram, WhatsApp, Slack, Discord, Signal, iMessage, Google Chat, Microsoft Teams, Matrix, Feishu and other services. WebChat is included in core. Some channels are bundled, some are official plugins and some are external plugins. Availability depends on the current project documentation, credentials and host requirements.

A skill is not the same as a permission. A skill can explain how to use a tool, but the tool policy still decides whether the capability is available. The skills documentation says agent allowlists control which skills an agent sees, but an allowlist is not a host shell authorization boundary. If the same agent can use unrestricted exec, a skill allowlist alone does not protect the host.

A plugin should be treated like code. The official plugin guide recommends trusted sources, pinned versions for reproducible installs, Gateway restart after code changes and runtime inspection after loading. A plugin can own a channel or register a tool, so installing one changes the system's reachable surface.

Readers who want a separate explanation of agent capability claims can review the Technology section and the agent security guide. The same rule applies in both cases: capability is not authorization.

How Do Sessions and Messages Move Through the System?

A typical turn begins when a message reaches a connected channel. The Gateway identifies the channel and session, applies the access policy and sends the permitted context to the agent. The model may answer directly or request a tool. The tool result returns through the Gateway, after which the agent can produce a reply or take another permitted step.

The message sender is only one part of the trust decision. The official security guide separates trigger authorization from context visibility. A person may be allowed to trigger a turn, while quoted text, forwarded content, attachments or fetched pages still need to be treated as untrusted material inside that turn.

Session routing also does not equal authorization. The security guide says `sessionKey` is a routing selector, not an authorization token. This distinction matters when several devices or channels share a Gateway. A session label can tell the system where to route context. It cannot prove that a person should receive host-level access.

For multiple people, the official guide recommends deliberate DM isolation. The documented `session.dmScope` option can separate sessions by channel and peer instead of sending all direct messages into one main session. This is a routing and context control. It is not a substitute for separate Gateways and separate hosts when users are mutually adversarial.

Channel pairing is another layer. DM-capable channels use pairing by default for unknown senders according to the official README. Group conversations need group allowlists and mention gating where appropriate. A public room with a powerful tool-enabled agent is not equivalent to a private chat with one trusted operator.

What Does the OpenClaw Security Model Assume?

The official security guide is direct about its trust model. It assumes one trusted operator boundary per Gateway. It does not present one shared Gateway as a hostile multi-tenant boundary for mutually untrusted users. If several adversarial users can message one tool-enabled agent, they share the delegated authority of that agent.

This is not a minor deployment detail. An AI assistant that can execute shell commands, read files, access network services or send messages has a meaningful blast radius. A malicious message does not need to exploit a memory corruption bug. It can try to persuade the model to read a secret, run a command or send a message to the wrong person.

The official threat model puts identity first, scope next and model last. Identity means deciding who can talk to the bot. Scope means deciding where the bot can act through tools, channels, files and devices. Model choice matters, but a capable model still needs hard controls around it.

Prompt injection can arrive through public messages, but it can also arrive through web pages, email, documents, attachments, pasted logs, search results and fetched content. The material may look like an instruction. It remains data unless the operator has deliberately authorized the requested action.

The official audit commands are `openclaw security audit`, `openclaw security audit --deep`, `openclaw security audit --fix` and `openclaw security audit --json`. The fix mode is described as narrow. It can tighten allowlists and permissions, but an operator still needs to understand the remaining findings.

How Does Sandboxing Reduce Tool Risk?

Sandboxing moves selected tool execution away from the Gateway host. The official guide says the Gateway itself remains on the host and that sandboxing is off by default. When enabled, tools such as exec, read, write, edit, apply_patch and process can run inside a sandbox backend.

The guide also states that sandboxing is not a perfect security boundary. It materially limits filesystem and process access when the model behaves badly, but it does not turn an agent into a risk-free system. Native plugins remain in process with the Gateway, and tools explicitly allowed through privileged mode can bypass the sandbox.

OpenClaw documents three sandbox modes: off, non-main and all. The scope can be agent, session or shared. The backends include Docker, Podman, SSH and OpenShell. These choices answer different operational questions, so a setting copied from one deployment may be wrong for another.

The Docker example in the official guide uses a read-only root, no network, dropped capabilities and no-new-privileges controls. Workspace access can be none, read-only or read-write. A read-only workspace is a stronger starting point for a reader or research agent than giving every turn write access to the main project.

Privileged tools need special attention. The guide says privileged execution can bypass sandboxing and run on the configured escape path. If a policy permits privileged actions, the operator should treat those actions as host-level authority and constrain who can trigger them.

For a related view of containment and operational controls, read the security controls article. The useful comparison is not “sandbox equals safe.” It is “sandbox reduces one class of blast radius while other controls still matter.”

How Do You Install and Verify OpenClaw?

The official getting-started guide requires a supported Node.js runtime and an API key from a model provider. The current guide lists Node.js 22.22.3+, 24.15+ or 25.9+ and says Node 26 is the recommended runtime. The GitHub README also documents the supported direct package versions.

For macOS and Linux, the official installation path uses the shell installer at openclaw.ai. Windows users have a PowerShell installer. The project also documents Docker, Nix and direct package installation. An installer is code execution. Use the official domain, read the current instructions and understand what the command is going to install.

After installation, onboarding chooses a model provider, sets the API key and configures the Gateway. A direct package installation can run `openclaw onboard --install-daemon`. The verification sequence in the official guide is practical: check `openclaw gateway status`, open `openclaw dashboard` and send a test message through the Control UI.

The guide says the Gateway should listen on port 18789 after setup. A listening port does not mean it should be exposed to the public internet. Bind address, authentication, reverse proxies, Tailscale settings, channel pairing and firewall rules need separate review.

Readers documenting technical setup can also see the fact-checking workflow guide. The Markets section also shows why a dated source and a live check should stay separate. Identify the source, verify the live state and do not mistake a successful command for a secure deployment.

Which Channels and Companion Apps Can It Use?

OpenClaw connects channels through the Gateway. The official channel overview lists Telegram, WhatsApp, Slack, Discord, Signal, iMessage, Google Chat, Microsoft Teams, Matrix, Feishu, LINE, IRC, Mattermost, Nostr, SMS, Twitch, WebChat, Zalo and other options. The list changes with bundled, official plugin and external plugin status, so the current documentation should control a deployment decision.

Telegram is often the fastest first channel because the official getting-started guide describes a bot token path. WhatsApp uses QR pairing and stores more state on disk. That difference affects both setup time and operational hygiene.

Companion apps and nodes can add voice, Canvas, camera, screen and device-local actions on supported platforms. These are not just interface decorations. A camera, screen or device action increases the information and control surface available to the agent.

Channels can run at the same time and route per chat. That convenience is useful for a personal assistant, but it makes identity and context checks more important. The operator should know which channel can trigger which agent, whether groups require a mention and whether a reply can reach a wider audience than the original message.

Channel pairing is a safety control, not a complete authorization system. The agent still needs a restricted tool profile, file policy and execution boundary. A paired sender with full host exec is a different risk from a paired sender with a read-only research tool.

For a broader look at how digital systems expose capabilities through interfaces, see the Technology section. In OpenClaw, every added interface should have an owner, an access policy and a reason to exist.

How Should You Evaluate Skills and Plugins?

The official skills guide says a skill is a Markdown instruction file with a `SKILL.md` file and frontmatter. Skills can load from workspace, project, personal, managed, bundled and extra directories. When names collide, higher-precedence sources win. That precedence is convenient, but it also means a local override can change what an agent reads.

Skills can be filtered by operating system, binary availability, environment variables and configuration. Agent allowlists control which skills are visible to an agent. The documentation warns that an allowlist is not a host shell authorization boundary. A skill may be hidden while another route still gives the agent powerful tools.

Third-party skills are treated as untrusted code in the official warning. Read the files before enabling them. Check the dependencies, commands, network behavior, secret use and scope of any environment injection. The docs say skill environment and API-key injection is scoped to the host agent run, not the sandbox, so secrets need separate handling.

Plugins extend the runtime with channels, model providers, agent harnesses, tools, skills, media functions, web fetch, web search and hooks. The plugin guide says installs should use a trusted source and that pinned versions are better for reproducible production setups. After a code change, the Gateway may need a restart.

The documented plugin checks include `plugins.allow`, `plugins.deny`, per-plugin enablement and runtime inspection with `openclaw plugins inspect --runtime --json`. A plugin that is present in a cold manifest is not necessarily registered in the running Gateway. Runtime proof matters.

Readers can compare this supply-chain approach with the evidence and source-boundary guide. A package name or skill description is a starting point. Read the code and inspect the active runtime before granting trust.

Who Should Use OpenClaw AI

OpenClaw AI may suit a technically confident user who wants a personal assistant connected to local devices, messaging channels and selected tools. That user should be comfortable with API keys, Gateway configuration, channel pairing, permissions, logs, updates and recovery steps.

It may also suit a developer who wants a local control plane for agent workflows. The official project exposes a plugin and skill model that can be extended, but extension work creates maintenance and supply-chain responsibilities. A developer should be ready to inspect dependencies, pin versions and remove a capability when its behavior is unclear.

OpenClaw may not suit someone seeking a zero-configuration assistant that can be given broad access without review. The official setup needs a model provider, a Gateway and configuration choices. A user who does not want to manage those choices should prefer a narrower product with fewer host-level permissions.

It is a poor fit for one shared, tool-enabled Gateway serving mutually adversarial users. The official security guide recommends separate Gateways and ideally separate OS users or hosts for that situation. A group chat is not automatically a safe multi-tenant boundary.

OpenClaw is also not a substitute for an incident-response plan. A deployment should have a way to revoke channel access, rotate provider keys, disable plugins, review logs, restore configuration and stop the Gateway. The best design is the one that can be shut down cleanly when a trust assumption changes.

For readers comparing personal automation choices, the security controls guide and the status-check guide both reinforce the same principle: define what is verified, what is permitted and what remains unknown.

What Is the Practical OpenClaw AI Checklist?

Start with identity. Keep DM-capable channels on pairing or a narrow allowlist. Use group allowlists and mention requirements where a room contains people who should not automatically trigger the agent. If the deployment has several users with different trust levels, split the Gateway boundary rather than relying on a session label.

Then reduce scope. Enable only the tools the workflow needs. A reader agent does not need shell execution. A message assistant does not need unrestricted filesystem access. A browser-enabled agent should not automatically receive the same credentials and workspace as the primary operator.

Set the execution boundary explicitly. If sandboxing is off, understand that host execution may be used. If sandboxing is on, check its mode, scope, backend, workspace access and network behavior. Review privileged tools because they can bypass the sandbox.

Review the supply chain. Read skills before enabling them. Pin plugin versions where reproducibility matters. Configure plugin allowlists. Restart and inspect the active Gateway after changes. Keep secrets out of prompts and logs, and treat fetched material as untrusted input.

Run the security audit after meaningful configuration changes. The result is a diagnostic, not a guarantee. Read each finding, decide whether it matches the deployment's threat model and record the decision. If a public exposure or open policy is not intentional, fix it before connecting more channels.

The final answer is balanced. OpenClaw AI is a capable personal-agent framework with a Gateway, model providers, tools, channels, skills, plugins and optional device actions. Its value comes from connecting systems. Its safety depends on controlling those connections. The official docs do not support calling it safe by default or treating a model response as an authorization decision.