Running OpenClaw securely for a team.

OpenClaw is built as a personal agent runtime: one install, one owner, one shared secret for the gateway. That design is exactly why it is so capable, and exactly why it gets risky the moment a second person starts using it. This guide covers what OpenClaw's own defaults already do well, what you should harden yourself, where the single-user design sets hard limits, and what a governance layer adds on top.

We build Pinchy, an open-source governance layer for OpenClaw, so we have skin in this game. The DIY section below stands on its own either way.

First, credit where it is due: the defaults are sane

OpenClaw binds its gateway to loopback (127.0.0.1) by default, requires authentication, and refuses to bind to a non-loopback interface without a configured secret. The widely reported exposure problem is not a default-settings problem. It is an opt-out problem: operators bind the gateway publicly for remote access, set gateway.controlUi.allowInsecureAuth: true, or pick trivial secrets. Bitsight's researchers put it bluntly: even something as trivial as "a" is accepted as a valid password.

The numbers show how common those opt-outs are. Bitsight observed more than 30,000 distinct exposed OpenClaw instances between January 27 and February 8, 2026, scanning port 18789 across the internet. SecurityScorecard's STRIKE team identified more than 40,000 exposed instances within the first day of scanning and flagged 35.4 percent of observed deployments as vulnerable at the time of their February 2026 report, with remote code execution among the most prevalent risks — and they track the live count on a public dashboard, declawed.io.

The core problem for teams: one secret means one identity

The gateway authenticates clients against a single shared secret (a token or password). Whoever has it can talk to every agent, trigger every enabled tool, and read every session. There is no concept of "who is calling": the colleague reviewing support tickets and the admin who configured the system look identical to the runtime. Three consequences follow:

1. No attribution. If an agent did something destructive, you cannot tell who asked it to.
2. All or nothing. You cannot give someone access to one agent but not another, or read access but not write.
3. One leak owns everything. A leaked secret is not one compromised account. It is the whole installation.

These are not bugs. They are properties of a single-user design, and the OpenClaw issue tracker documents the demand for more: multi-token authentication for team collaboration, per-user session isolation, permission guardrails between agents, audit logs for agent actions.

What you can and should harden yourself

1. Leave the gateway on loopback. That is the default; resist the temptation to bind it publicly for convenience. Remote access goes through a VPN, an SSH tunnel, or a reverse proxy you control. Never set allowInsecureAuth, and treat a weak gateway secret as no secret at all.

2. Contain the runtime. Run OpenClaw in a container or VM, not as root, with workspace-scoped filesystem mounts. The agent should be able to write to its workspace and nothing else. Keep host credentials (SSH keys, cloud credentials, browser profiles) out of reach.

3. Treat the gateway secret like a root password. Store it in a secrets manager or an env file with tight permissions, never in a repo or a chat message. Rotate it by updating the config and restarting; assume rotation will be disruptive, because every client needs the new secret.

4. Restrict outbound traffic. If the agent does not need to reach arbitrary hosts, give the container an explicit egress allowlist. This limits both prompt-injection blast radius and data exfiltration paths.

5. Split agents by purpose, not by convenience. A research agent with web access does not need the filesystem tools of your ops agent. Several narrow agents with minimal tool sets beat one agent with everything enabled.

6. Keep and review the logs you have. Session transcripts live as JSONL on disk and the gateway logs connections. Ship them somewhere append-only if you can. Be honest with yourself about what they are: useful for debugging, weak as evidence, because anyone with disk access can edit them after the fact.

7. For multiple users, use trusted-proxy mode, not secret sharing. OpenClaw supports gateway.auth.mode: "trusted-proxy", which delegates identity to a reverse proxy in front of the gateway. Combined with an SSO-capable proxy, this gets you per-user session isolation without handing everyone the shared secret. If your team shares one gateway today by passing the token around, this is the first thing to fix.

Where DIY stops

Trusted-proxy mode solves identity, not authorization. Even with a hardened runtime and an SSO proxy in front, you still do not have: roles (admin vs. member), per-agent access control (who may talk to which agent), per-tool permissions (what each agent may do, enforced per user), or an audit trail that can prove anything after the fact. Those are not hardening gaps you can configure away. They are a management layer that someone has to build.

You have three honest options:

• Stay single-user. Perfectly fine for a personal setup. Stop here.
• Build the layer yourself. A frontend that owns accounts and roles, maps users to isolated sessions, gates tools per agent, and writes signed audit records. This is real work, and you will be maintaining it against a fast-moving runtime.
• Use an existing layer.

What a governance layer adds

This is what we built Pinchy for, so the rest of this section is us describing our own product. Pinchy is open source (AGPL-3.0) and sits in front of OpenClaw as the only client that holds the gateway secret:

• Identity and roles: users sign in with their own accounts; admin and user roles are separate. The gateway secret never reaches a browser.
• Per-agent access: agents are personal or shared; shared agents are scoped to groups. Every user gets their own isolated conversation with an agent.
• Allow-list tool permissions: a new agent starts with zero tools. Admins enable each tool per agent, explicitly.
• Tamper-evident audit trail: every agent action is recorded with an individually signed (HMAC) entry, so after-the-fact edits are detectable. CSV exports include the signatures for independent verification.
• Self-hosted, like the runtime itself: one Docker Compose stack next to your OpenClaw, local models via Ollama supported.

If you would rather build than adopt, our architecture notes and the audit trail design are public; take what is useful. And if you try Pinchy and something does not hold up to this article, we want that issue report.