Self-Hosted Personal AI Agent Security (OpenClaw)

Self-hosted personal AI agents such as OpenClaw run around the clock on a laptop, home server or cloud VM, hold the owner's email, chat, calendar and model API credentials, and can run shell commands on instruction from a chat message, which makes each one a privileged non-human identity that the security team usually does not know exists. OpenClaw (earlier named Clawdbot and Moltbot) went from around 1,000 to more than 21,000 internet-visible instances in under a week in January 2026, according to Censys, and around the same time a one-click remote code execution flaw and a malicious skills campaign came to light. This guide covers how this class of assistant is built, where it fails, how to configure it safely if you allow it, and how to find and govern it if you do not. It is for security architects, endpoint and identity teams, and the engineers who want to run one at work.

Key takeaways

It is an identity, not an app. A personal agent holds delegated tokens for messaging, email and model providers and acts with them unattended, so manage it like any other non-human identity with an owner, scope and rotation.
The gateway is the crown jewel. Whoever reaches the control plane with its token can change tool policy and run commands, so it must stay on loopback or behind authenticated private access.
Anyone who can message it shares its authority. The vendor's own trust model is one trust boundary per gateway; it is not designed to separate mutually untrusted users.
Prompt injection turns content into commands. Email, web pages and documents the agent reads can carry instructions; limit tools and sandbox execution rather than relying on the model to refuse.
Allow, contain or block deliberately. Banning outright drives use to personal devices; an approved, hardened pattern plus detection of unmanaged installs is usually more effective.

What makes this class of agent different

Most enterprise AI assistants are SaaS products with tenant administration, audit logs and a vendor security team. Self-hosted personal agents invert that model. The OpenClaw project describes itself as a personal assistant you run on your own devices that answers on the chat apps you already use, and the architecture reflects that:

Gateway: a long-running process that holds configuration, policy and credentials, serves a web Control UI and a WebSocket API, and by default listens on TCP 18789.
Channels: connectors to WhatsApp, Telegram, Slack, Discord, Signal and similar services, so the agent receives instructions from chat messages rather than a dedicated app. See the Discord and Telegram Bot Tokens Security Guide.
Tools: shell execution, file read and write, browser control, messaging and scheduling, plus third-party skills and plugins from a public registry.
Nodes: paired devices that the gateway can run commands on, which the documentation describes as operator-level remote execution.
Model providers: API keys for one or more LLM services, stored locally.

The OpenClaw documentation is unusually direct about its threat model: the assistant can execute arbitrary shell commands, read and write files, access network services and send messages to anyone it has channel access to, and most failures are not exotic exploits but someone messaging the bot and the bot doing what was asked. Its recommended order is identity first (who can talk to it), scope next (where it can act) and model last (assume the model can be manipulated).

The risk picture from 2026 incidents

Risk	What happened	Lesson
Internet exposure of the gateway	Censys counted 21,639 exposed instances on 31 January 2026, found by Control UI page titles on port 18789, though most still required a token	Users bypass the loopback default with port forwarding, LAN binds and cloud VMs; inventory and external scanning are needed
Token theft and one-click code execution	CVE-2026-25253 (MITRE ATLAS case study AML.CS0050): a malicious link ran script in the victim's browser, took the gateway token through the Control UI WebSocket, used cross-site WebSocket hijacking to reach the local gateway, disabled confirmation and escaped the container to run host commands	Loopback alone is not a boundary when a browser on the same host can be driven to connect; patch promptly and treat the token as a privileged credential
Indirect prompt injection to command and control	HiddenLayer showed a web page could make OpenClaw run a script that planted persistent instructions in future system prompts (ATLAS AML.CS0051)	Agents that read untrusted content and also have shell tools need sandboxing and approval gates
Malicious skills	The ClawHub Malicious Skills 2026 campaign published hundreds of fake skills with "prerequisite" steps that installed credential stealers	Third-party skills are code with the agent's privileges; allowlist them
Leaked agent keys at scale	The Moltbook Database Exposure 2026 left 1.5 million AI agent API keys readable in an open Supabase database	Credentials held by personal agents end up in places the owner did not plan for; scope and rotate them

These map to MITRE ATLAS techniques covered in depth elsewhere: AML.T0083 Credentials from AI Agent Configuration, AML.T0081 Modify AI Agent Configuration and AML.T0051.001 indirect prompt injection.

Trust boundaries you must get right

The OpenClaw trust model page states that it supports one trust boundary per gateway: a single operator or a mutually trusting team, preferably one OS user, host or VPS per boundary. Several defaults follow from that design and surprise enterprise reviewers:

Delegated authority is shared: everyone who can message a tool-enabled agent shares that agent's tool authority. In a shared Slack workspace, any allowed sender can induce shell, browser or file actions within the agent's policy.
Cross-session reach is on by default: tools.sessions.visibility defaults to all and tools.agentToAgent.enabled defaults to true, so an unsandboxed tool-enabled agent can read other agents' session transcripts on the same gateway.
Host execution is trusted by default: for the single-operator case, host exec runs with security="full" and ask="off", meaning no approval prompts. The vendor calls this intentional, not a bug.
Config access equals operator access: anyone who can modify ~/.openclaw or openclaw.json is a trusted operator.
Session keys are not authorisation: sessionKey is a routing selector, not an access token.

The practical consequence for an enterprise is simple: one person, one gateway, one dedicated OS user or VM. Do not deploy a single shared personal agent for a team that includes contractors, customers or anyone you would not give a shell to.

Hardened configuration baseline

The project publishes a hardened baseline. The settings below come from its documentation; check them against the version you deploy, as configuration keys change between releases.

Area	Setting	Hardened value	Why
Network	`gateway.bind`	`loopback`	Keeps the control plane off the network; container images default to an exposed bind and need auth
Authentication	`gateway.auth.mode` and token	`token` with a long random value (for example from `openssl rand -hex 32`)	Startup rejects blank and placeholder tokens; the audit warns below 24 characters
Inbound access	`dmPolicy` per channel	`pairing` (or allowlist), never open	Unknown senders get a pairing code instead of being processed
Groups	`groups."*".requireMention`	`true`	Limits what group chatter can trigger
Sessions	`session.dmScope`; `tools.sessions.visibility`	`per-channel-peer`; `agent`	Isolates DMs and stops cross-session reads
Agent to agent	`tools.agentToAgent.enabled`	`false`	Removes default cross-agent messaging
Tool profile	`tools.profile` and `tools.deny`	`messaging`; deny `group:automation`, `group:runtime`, `group:fs`	Starts from no control-plane or runtime tools, then re-enable per trusted agent
Execution	`tools.exec`; `tools.elevated.enabled`	`security: "deny"`, `ask: "always"`; `false`	No silent shell execution
Files	`tools.fs.workspaceOnly`; sandbox `workspaceAccess`	`true`; `ro` or `none`	Confines file actions
Discovery	Bonjour plugin	Disabled	mDNS adverts (`_openclaw-gw._tcp`) reveal install path and SSH port on the LAN
Disk	`~/.openclaw` permissions	`700` directories, `600` files, full-disk encryption	Holds channel credentials, auth profiles and transcripts

Remote access

The documentation's rule of thumb is to prefer an authenticated overlay such as Tailscale Serve, which keeps the gateway on loopback, over LAN binds; if a LAN bind is unavoidable, firewall the port to a tight source allowlist; and never expose the gateway unauthenticated on 0.0.0.0. Public tunnelling features (Tailscale Funnel or equivalent) should be off for corporate use. See the Mesh VPN Security Guide.

Credentials and data the agent holds

Treat everything under ~/.openclaw as secret. The documentation lists channel credentials (for example WhatsApp creds.json), legacy OAuth imports, per-agent SQLite stores holding model auth profiles, MCP OAuth sessions and pairing allowlists. Session transcripts, tool arguments and tool results keep their original text, including any credentials that passed through them. That maps directly to ATT&CK T1552.001 Credentials In Files.

Use dedicated accounts: a separate phone number for WhatsApp or Signal (the vendor suggests this), a separate mailbox or a delegated mailbox scope, and a dedicated model API key with a spend cap.
Scope OAuth grants: read-only calendar and mail where possible; avoid tenant-wide consent. See the Agent Identity and Access Guide.
Keep provider keys out of workspaces: OpenClaw blocks provider keys in workspace .env files; keep them in the gateway environment or a secret manager reference.
Rotate on any doubt: gateway token, remote client tokens, channel tokens and model keys, in that order.

Enterprise decision: allow, contain or block

Stance	When it fits	What it requires
Block	Regulated environments, high-value data on endpoints, no capacity to support another agent platform	Application allowlisting, EDR detection of the runtime and port, CASB or proxy rules for registry and Control UI traffic, clear policy
Contain (approved pattern)	Engineering-heavy organisations where staff will run agents anyway	Dedicated VM per user, hardened baseline enforced by config management, dedicated accounts and keys, skill allowlist, logging to SIEM
Allow personal use only	Small organisations, personal devices	Policy that corporate credentials, data and SSO accounts may not be connected; detection of corporate tokens appearing on unmanaged hosts

For small organisations, the policy line plus model key spend caps covers most of the risk. Large organisations should offer the contained pattern, because an outright ban without an alternative tends to push installs onto personal devices that still hold corporate chat and mail sessions. See the AI Usage Control and Shadow AI buyer's guide for tooling.

How to implement

Find what is already running. Query EDR for the gateway process and listeners on TCP 18789, search proxy logs for registry and model API traffic from unexpected hosts, and scan your external ranges and cloud accounts for the Control UI page titles Censys used.
Decide the stance using the table above and publish it in the acceptable use policy, including which corporate accounts may never be connected.
Build the approved image. One VM or dedicated OS user per person, the hardened baseline in configuration management, sandbox mode: "all" for any agent that reads untrusted content, and Bonjour off.
Issue scoped identities. Dedicated model keys with spend limits, scoped OAuth grants and a named human owner recorded in your NHI inventory.
Pilot in audit mode. Run openclaw security audit --deep and --json on pilot hosts, feed the findings to your SIEM, and fix in the vendor's triage order: open access with tools, public exposure, remote browser control, file permissions, plugins.
Roll out with rollback. Widen the pilot only when audit findings stay clean; roll back by stopping the gateway and setting gateway.bind: "loopback" and dmPolicy: "disabled", which is the vendor's own containment step.
Prepare incident response. The vendor's runbook is contain (stop, close exposure, freeze DMs), rotate (gateway auth, remote tokens, provider and channel credentials), then audit (logs under /tmp/openclaw/, transcripts under ~/.openclaw/agents/<agentId>/sessions/, recent config changes). Add it to the Compromised Developer Workstation Playbook.

Detection and measurement

Endpoint: new listeners on 18789, the gateway process spawning shells, and writes to ~/.openclaw by other processes.
Network: inbound connections to the gateway port from outside loopback, mDNS adverts for _openclaw-gw._tcp, and tunnelling services on hosts that run the gateway.
Identity: corporate OAuth grants to unfamiliar client applications, model API keys used from residential or unexpected cloud IPs, and chat bot tokens tied to personal numbers.
Configuration: audit check IDs such as gateway.bind_no_auth and tools.exec.security_full_configured treated as alerts.

Metrics:

Known personal agent instances, and the share found by detection rather than self-declared.
Percentage of approved instances with zero critical audit findings.
Internet-exposed gateways on your ranges (target zero).
Percentage of agent credentials with a named owner and rotation in the last 90 days.
Third-party skills in use that are on the allowlist (target 100%).
Median time from a gateway security release to patched approved instances.

Common failure patterns

Port forwarding for convenience. Users expose the Control UI to reach it from a phone, as the tens of thousands of internet-visible instances in early 2026 show.
Running in a container with defaults. Container images bind to an exposed address by default; without a token and firewall the control plane is public. Exposed Docker hosts are already hunted for AI keys, as the Carbonato Botnet 2026 shows.
One agent for the whole team. A shared gateway in a busy Slack workspace gives every member, and every injected message, the owner's shell.
Installing skills by popularity. Download counts were gamed in the ClawHub campaign; see the Agent Skills Security Guide.
Connecting the primary corporate identity. Full mailbox and drive access through the user's own SSO account turns any prompt injection into a data breach.
Slow patching. Personal installs sit outside patch management, so fixes such as the one for CVE-2026-25253 never arrive.

Framework mapping

Framework	Reference	Application
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory	Inventory personal agent instances and their owners
NIST SP 800-53 Rev. 5	CM-7 Least Functionality; AC-6 Least Privilege	Tool profiles, denied tool groups, scoped OAuth grants
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection	Loopback bind, authenticated overlay, firewall
NIST SP 800-53 Rev. 5	SR-3 Supply Chain Controls and Processes	Skill and plugin allowlists
NIST CSF 2.0	ID.AM-02; PR.AA-05; PR.PS-01	Software inventory, least-privilege access, configuration management
MITRE ATT&CK	T1190 Exploit Public-Facing Application; T1552.001 Credentials In Files	Exposed gateways; credentials on disk
MITRE ATLAS	AML.T0083; AML.T0081; AML.T0051.001; case studies AML.CS0050 and AML.CS0051	Agent configuration credential theft and tampering, indirect prompt injection

Practitioner checklist

Hunt for gateway processes and port 18789 listeners across endpoints and cloud.
Scan external ranges for exposed agent Control UIs.
Publish an allow, contain or block decision with named prohibited account types.
Enforce loopback bind, token auth, DM pairing and mention gating on approved instances.
Turn off cross-session visibility, agent-to-agent messaging and silent host exec.
Sandbox every agent that reads email, web pages or documents.
Issue dedicated, scoped, spend-capped credentials with a named owner.
Allowlist skills and plugins; block the public registry otherwise.
Run the vendor security audit on a schedule and alert on critical findings.
Add the contain, rotate, audit runbook to incident response.

Self-Hosted Personal AI Agent Security Guide: OpenClaw-Class Assistants in the Enterprise