OpenClaw connects chat channels, AI models, tools and skills through your own Gateway. A guide to architecture, use cases and security.
Roland Schellhorn
OpenClaw is an open-source AI assistant that runs on infrastructure you control and communicates through chat channels you already use. Rather than only answering in a web interface, it connects models, sessions, tools and automation through an always-on Gateway.
It can connect email, calendars, files, developer tools and internal systems. That ability to act is also its main security concern: an agent should only reach the data and actions required for its purpose.
The official description presents OpenClaw as a self-hosted assistant for individuals or mutually trusted teams. The Gateway is the persistent control plane connecting clients, channels and nodes.
OpenClaw is not a language model or an IDE replacement. It coordinates selectable models, tools and communication channels, allowing providers to change without rebuilding every integration.
According to the architecture documentation, a long-lived Gateway manages messaging connections, sessions and a typed WebSocket API. Web, CLI, desktop and mobile clients share Gateway-owned state. Remote access should favor a VPN or SSH tunnel.
Centralization simplifies synchronization but makes the Gateway a critical asset. Authentication, network boundaries, updates, logs and backups belong in the base design.
OpenClaw can connect Discord, Slack, Signal, Telegram, WhatsApp, iMessage, Mattermost, WebChat and other channels. Capabilities vary by channel and plugin. Allowed senders, groups, mentions and actions should be explicitly constrained.
Models reason and respond. Tools perform typed actions, skills describe repeatable workflows, and plugins add channels, providers and runtime capabilities. The official overview explains that visible tools are filtered through profiles, allow/deny policy, sandboxing and channel permissions.
Plugins execute inside the Gateway and must be treated as trusted code. Third-party skills can also contain risky instructions or installers. Review provenance, changes and requested permissions before enabling either.
The Gateway owns sessions, transcripts, routing and active runs, allowing multiple clients to use the same state. A Gateway is designed for one operator or a mutually trusted group—not adversarial tenants. Separate customers, public bots and internal assistants should use separate Gateways, OS users or hosts.
The tool-permission documentation recommends denying dangerous capabilities for untrusted content. Shell access, filesystem writes, browser actions, persistent jobs, Gateway administration and sub-agents require particular care.
Prompt injection remains relevant whenever an agent reads websites, messages or documents. A system prompt is not a security boundary; technical permissions and isolation must limit impact.
The official getting-started guide covers installation, model access, onboarding and the Gateway. Production also needs supervision, protected configuration, token rotation, logging, tested backups and controlled updates.
OpenClaw suits teams that want to operate a customizable assistant and carefully model its authority. A shared default installation is not appropriate for adversarial multi-tenancy, unreviewed plugins or unrestricted host access.
BIT62 supports architecture, self-hosting, model and channel integrations, skill development, sandbox and permission design, monitoring and secure operations.
One control plane connects chats and devices.
Connect interchangeable providers and local models.
Extend capabilities in modular, reviewable units.
Synchronize state across authorized clients.
Technically restrict access to what is required.
Plan updates, logs, backups and recovery.
BIT62 connects models, channels and tools with robust permissions and operations.