# The Security Mistake I Found in My Self-Hosted OpenClaw Setup

I run OpenClaw on my own homelab.

The hardware is mine. The infrastructure is mine. The agents run on systems I control.

I still managed to leave a dangerous path into it open for months.

One of the agents in my OpenClaw setup is Flux, my engineering agent. It reviews code, works across repositories and helps with infrastructure. To do that job properly, it needs capabilities I would never give a normal chatbot, including shell access to the host.

That part was intentional.

The problem was where else Flux was listening.

## What I found

Flux was connected to four WhatsApp groups. Some of those groups had other people in them, and `requireMention` was disabled.

That meant Flux could react to ambient conversation. Nobody had to explicitly address it first.

Put those two facts together:

- An agent with shell access to my homelab
- Listening inside shared conversations without an explicit invocation requirement
That is not a theoretical prompt-injection problem. It is a configuration problem with a very real blast radius.

Someone could say something completely ordinary in the wrong context and cause the agent to interpret it as work. They would not need to compromise the model or find some clever exploit. The system was already giving conversation a path toward powerful tools.

I had built both ends of that path myself.

## Self-hosting did not make it safe

I self-host because I want control over my infrastructure and data. OpenClaw gives me that control.

But control is not the same as safety.

Owning the machine tells you where the agent runs. It does not tell you who can invoke it, which messages it will treat as instructions or what happens after it decides to act.

I had been thinking about the agent and the channel as separate configuration decisions.

Flux needs shell access. Fine.

The team could benefit from having Flux in a few groups. Also fine.

The dangerous part was the connection between them. What can every person in those groups cause this agent to do on the machine underneath it?

That is the question I had not asked.

## Three boundaries, not one

I now look at every agent through three separate boundaries.

The first is invocation: what causes the agent to respond?

A mention requirement is useful here. It stops an agent from treating every ambient message as a possible instruction. But it only proves that somebody addressed the agent. It does not prove that person was authorized to use its capabilities.

The second is authorization: who is allowed to invoke it?

That needs its own controls, such as sender allowlists, isolated channels or approval gates for sensitive actions. If everybody in a group can mention the agent, `requireMention: true` is not an authorization system.

The third is capability: what can the agent reach after it has been invoked?

Can it read files? Write them? Execute commands? Use API keys? Reach the host, or only a sandbox?

These controls solve different problems. None of them replaces the others.

An agent can require a mention and still give the wrong person too much power. It can accept messages only from trusted people and still have far more host access than its job requires. It can run in a sandbox and still damage everything available inside that sandbox.

The safe configuration depends on the job, but the questions stay the same:

1. What makes this agent act?
2. Who is allowed to make it act?
3. What can it touch when it does?
## What I changed

I enabled explicit invocation requirements for Flux in shared groups, then reviewed group membership and sender restrictions as a separate concern.

I kept the host access Flux genuinely needs. Sandboxing an engineering agent so tightly that it cannot do engineering work would make it useless. The answer was not to remove every capability. It was to make the path to those capabilities deliberate.

Then I checked the rest of my OpenClaw setup.

Scribe, my writing agent, had `sandbox.mode: "off"` overriding a container configuration that was already set up correctly. A writing agent does not need unrestricted host access. I removed the override and restored the sandbox.

My DevOps agent was present in a group with team members. I reviewed its invocation and permission boundaries using the same model.

Three fixes took roughly twenty minutes.

The unsafe assumptions behind them had survived for months.

## The part worth remembering

Self-hosting can make an agent system safer because you control every layer.

It also makes you responsible for every layer.

The model does not need to be compromised for the system to be unsafe. Ordinary messages combined with excessive permissions are enough. The attack surface includes the people, channels, trigger rules, agent configuration, tools and infrastructure behind them.

If you run agents on your own infrastructure, audit the complete path.

Do not just ask what the agent can do.

Ask who can trigger it, and what it can reach when they do.