Self-hosted AI agent security: what OpenClaw keeps under your control

A self-hosted AI agent gives you control of the gateway, files, channel credentials, and access policy. It does not automatically make every part of an agent private or safe. If the agent calls a cloud model, the prompt and tool results sent for inference still leave your machine. If an untrusted person can message a tool-enabled agent, self-hosting does not stop them from trying to steer those tools.

That distinction matters when you run OpenClaw on a home server, Mac Mini, or VPS. The practical goal is simple: keep the gateway private, decide who can reach it, and give each agent only the permissions its work requires.

In this guide

• What self-hosted AI agent hosting controls
• Start with one trust boundary
• Keep the Gateway private first
• Restrict chat access before adding powerful tools
• Run the audit after every meaningful change
• Choose your inference boundary deliberately

What self-hosted AI agent hosting controls

OpenClaw’s Gateway is the local control plane. It owns sessions, auth profiles, channels, and state, while clients connect to it. You choose the machine, operating system account, disk location, network path, and backup policy.

That is meaningful control, but it is not a blanket guarantee. This table separates the parts people often group together.

Layer	What self-hosting gives you	What still needs a decision
Gateway and state	You choose the host, file permissions, logs, transcripts, and backups	Who has shell or config access to that host
Model inference	You can select a local or remote provider	Cloud-model prompts and tool output are sent to that provider when used
Messaging channels	You choose which bot accounts connect	Who can DM the bot, which groups are allowed, and when it responds
Tools	You decide which tools an agent can call	Whether a prompt can trigger file, browser, shell, or network actions
Remote access	You can keep the control UI off the public internet	Whether VPN, SSH, proxy, and gateway authentication are configured correctly

For an overview of host choices, start with the site’s self-hosting page. If you are still deciding whether an always-on agent is the right fit, what OpenClaw is and how it works covers the runtime model.

Start with one trust boundary

The safest default is one trusted operator per gateway. OpenClaw’s security documentation is direct about this: a shared gateway is not a multi-tenant security boundary. People who can modify the host state or openclaw.json are trusted operators; a session key only selects routing context and is not an authorization token.

If two people do not trust each other, give them separate gateways. In practice, that usually means separate OS users, containers, or hosts, plus separate channel accounts and credentials. Do not try to turn one broad personal-assistant configuration into an adversarial multi-user service by adding more chat sessions.

This also makes incident response less miserable. A compromised channel token or careless plugin has a smaller blast radius when it belongs to one gateway cell rather than every user and automation job.

Keep the Gateway private first

OpenClaw documents a loopback-only Gateway as the default. That is a good default for a self-hosted AI agent because it keeps the service off the LAN and public internet until you deliberately add a remote path.

For remote use, prefer an SSH tunnel or Tailscale Serve over publishing a raw Gateway port. The official remote-access guide describes the SSH fallback as forwarding local port 18789 to the gateway host:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

If you use a non-loopback bind for a trusted LAN or tailnet, configure Gateway authentication as well. A token, password, or identity-aware proxy answers a different question from network reachability: it proves who is calling the Gateway.

A Docker deployment can still follow the same model. The older Docker deployment guide is useful for persistent storage and restart policy, but do not publish a port merely because the container supports one. Decide first whether the UI needs remote access at all.

Restrict chat access before adding powerful tools

Most bad outcomes start with a simple sequence: a stranger reaches a bot, the bot has tools, and the bot follows a malicious instruction. The technical exploit is often less interesting than the access policy that made the conversation possible.

Use restrictive DM and group policies. For a one-owner Telegram bot, the official channel guide recommends an allowlist with your numeric Telegram user ID and explicit allowed group IDs. Keep requireMention: true in groups unless the agent genuinely needs to react to every message.

Then limit tool authority. A research or calendar agent does not need shell access. A coding agent may need a workspace, but it should not inherit unrestricted access to every directory or every channel. OpenClaw’s security audit calls out the risky combinations: open DMs or groups plus enabled tools, public network exposure, broad execution settings, and plugins loading without an explicit allowlist.

The OpenClaw guardrails guide is a useful companion when you are deciding which actions should require confirmation.

Run the audit after every meaningful change

Do not treat initial setup as the only security event. New channels, a remote proxy, a new skill, or a looser execution policy can change the risk profile.

Run the built-in audit after configuration changes and before exposing any network surface:

openclaw security audit
openclaw security audit --deep

The audit checks inbound access, tool blast radius, file-permission drift, execution approval settings, Gateway bind and auth, browser exposure, plugins, and unsafe policy combinations. --fix can apply a narrow set of safe remediations, but read the findings before assuming it has redesigned your setup.

A short recurring review is more useful than a huge annual checklist:

1. Confirm the Gateway is loopback-only unless you intentionally use a private remote path.
2. Review DM and group allowlists, especially after adding a channel account.
3. Check which agents can use execution, filesystem, browser, and message-sending tools.
4. Confirm config, auth profiles, and backup locations are not group- or world-readable.
5. Review plugin provenance and remove tools you are no longer using.

Choose your inference boundary deliberately

A self-hosted agent runtime can use cloud models, local models, or both. Those choices have different privacy, cost, and capability tradeoffs.

If a task goes to a remote provider, treat the task prompt and relevant tool output as data leaving the host. If that is not acceptable for a workflow, route it to a local model or redesign the workflow so the sensitive material is not included. Self-hosting the Gateway still helps because local state, credentials, channel routing, and tool policy remain under your control, but it does not erase the model-provider boundary.

This is why a useful setup document names both boundaries separately: where the agent runs and where inference runs. Mixing them produces false confidence.

A safer baseline for a personal agent

A reasonable first deployment is deliberately boring:

• One Gateway on a machine you control.
• Loopback binding with token authentication.
• Remote access through SSH or a tailnet, not an open public port.
• Paired or allowlisted DMs, and mention-gated groups.
• Minimal tools for non-owner conversations.
• Explicitly trusted plugins only.
• A security audit after configuration changes.

You can relax individual controls when a workflow needs it. The point is to know what you relaxed and why. That is the advantage of running a self-hosted AI agent: the policy belongs to you, along with the responsibility to maintain it.

FAQ

Does self-hosting OpenClaw mean my prompts never leave my machine?

No. The Gateway, local state, and channel credentials can remain on your host, but prompts and tool results sent to a cloud model provider leave the machine for inference. Use a local model or reduce what the workflow sends when that boundary matters.

Is a session ID an access-control mechanism?

No. OpenClaw documents sessionKey as a routing selector, not an authorization token. Use gateway authentication, channel pairing or allowlists, and tool policy for access control.

Should I expose the Gateway directly to the internet?

Usually no. Keep it loopback-only and use SSH tunneling or a private tailnet path when you need remote access. If you deliberately use a non-loopback bind, configure strong Gateway authentication and review the exposure runbook first.

What should I check before installing a new skill or plugin?

Check the source, what permissions or tools it needs, and whether it expands the agent’s access to files, shell commands, browsers, or messaging. Then run openclaw security audit after the configuration change.

Sources: OpenClaw Gateway security documentation · OpenClaw remote access documentation · OpenClaw installation documentation · OpenClaw Telegram access-control documentation