Tailscale ACLs narrow OpenClaw access. They do not replace authentication or channel policy.

Published June 24, 2026. Sources checked September 13, 2026.

Putting an OpenClaw Gateway on a private Tailscale network removes one common problem: random internet traffic no longer has a direct route to the service. It does not remove the other security questions.

You still need to know which application credential or trusted identity the Gateway accepts. You still need to decide which person, room, or channel may create an agent session. And you still need to limit what an accepted request can do.

That distinction is easy to lose because the words sound similar. Tailscale access control, OpenClaw Gateway authentication, and OpenClaw channel policy all use the language of access. They operate on different inputs and make different decisions.

Start by naming the gate

This table combines documented product scopes with a straightforward inference: a control cannot enforce a condition it does not receive as input. Tailscale documents ACL entries in terms of sources, destinations, and ports. OpenClaw documents Gateway authentication and channel rules separately. The boundaries should therefore be tested separately.

What a Tailscale ACL contributes

Tailscale’s ACL documentation describes rules that let selected users or devices reach selected destinations and ports. A conceptual rule might allow an operator group to reach the machine and port used by OpenClaw while denying other tailnet sources.

That is a useful outer gate. It can keep a Gateway port off the path of devices that have no reason to administer it. Tailscale also says ACL enforcement is local to the devices and that ACLs do not affect traffic on a device’s local network. The latter detail matters: a tailnet rule is not a universal host firewall, and it does not control every same-machine route.

There is an operational caveat as well. Tailscale now recommends grants for new policy files, while ACLs remain supported. The syntax may change, but the relevant boundary does not. The network policy decides which tailnet sources can connect to which network destinations.

That policy has no field for a Telegram sender ID, a Discord room, an OpenClaw DM mode, or a tool name. If two people reach the same Gateway through one permitted device or one permitted connector, the ACL has no way to distinguish their messages. That is not a defect in the ACL. It is outside its job.

Also check the effective policy rather than assuming that the presence of Tailscale means deny-by-default. Tailscale documents deny-by-default behavior for an explicit policy, but it also documents a default allow-all policy when no access-control policies are defined. A missing or overly broad rule can make a private network much less private than its name suggests.

Why Gateway authentication remains separate

OpenClaw’s network exposure guidance says the regular Gateway binds to loopback by default. A LAN, tailnet, or custom bind expands the attack surface and should use Gateway authentication together with a real firewall.

For a direct tailnet bind, the current OpenClaw Tailscale documentation shows a configuration with an OpenClaw token:

{
  gateway: {
    bind: 'tailnet',
    auth: { mode: 'token', token: '<managed-secret>' }
  }
}

The network rule and the token now have different failure modes. A device outside the Tailscale policy should fail before it reaches the port. A permitted device with no valid Gateway credential should still fail at the application handshake. That second check protects against an overbroad policy, a compromised permitted device, a local process, or a later change that creates another route to the service.

OpenClaw also supports a different shape: loopback plus managed Tailscale Serve. Serve keeps the Gateway on loopback while Tailscale provides the HTTPS route. When the documented managed Serve conditions are present and gateway.auth.allowTailscale is enabled, OpenClaw can verify Tailscale identity headers for the Control UI WebSocket surface.

That feature needs careful wording. It is an OpenClaw integration with a verified Tailscale Serve path, not proof that an ACL by itself authenticated every OpenClaw request. The same documentation limits the identity-header path to Control UI WebSocket authentication and read-only avatar requests. Endpoints such as /v1/*, /tools/invoke, and /api/channels/* continue to use the Gateway’s normal HTTP authentication mode.

The managed identity path also assumes the Gateway host is trusted. If untrusted local code may run there, OpenClaw says to disable the Tailscale identity-header shortcut and require token or password authentication. A tailnet identity can tell OpenClaw which device arrived. It does not make a hostile process on that host trustworthy.

Do not share a Gateway token with everyone who can reach the port. OpenClaw’s security guidance treats Gateway bearer credentials as operator access for the Gateway APIs, rather than as narrow per-channel permissions. A token is an application credential, not a replacement for sender policy.

Channel policy sits inside the connection

OpenClaw’s access-control documentation gives direct messages their own policy choices. With dmPolicy: pairing, an unknown sender receives a pairing code and the message is not processed until approval. An allowlist blocks unknown senders without a pairing exchange. An open policy is an explicit public choice that requires a wildcard allow entry. Disabled DMs are ignored.

Those decisions use information that Tailscale does not see. OpenClaw can evaluate the channel account, sender identity, group or room, and message activation. A Tailscale ACL sees the network source that reached the destination. The two identities may be related, but they are not interchangeable.

Groups add another layer. OpenClaw documents separate group allowlists and group policies, followed by mention or reply activation. A room can be reachable through an allowed bot connection while still refusing messages from an unapproved group member. Conversely, a broad group policy can admit more people than the operator intended even when the Gateway is reachable only from one private device.

Pairing does not turn a sender into a separate host security boundary. It approves that sender to trigger the bot. The exposure runbook recommends pairing or strict allowlists for DMs, mention requirements for less controlled groups, and minimal tools for shared channels.

Session scope is part of the same decision. OpenClaw documents main as the default DM scope, where DMs share one session. When several people can message the bot, per-channel-peer gives each channel-and-sender pair an isolated DM context. The documentation is explicit that this is a messaging-context boundary, not host-admin isolation.

That last qualification matters. Separating conversations can reduce accidental context mixing. It does not make mutually adversarial users safe to place on one Gateway. For that case, the OpenClaw trust model recommends separate Gateways and, ideally, separate operating-system users or hosts.

Choose the exposure pattern before writing rules

The Gateway exposure runbook frames the decision in the right order: who can reach the Gateway, how they authenticate, which agents they can trigger, and which tools those agents can use. A Tailscale ACL answers only the first part.

A small baseline for a review

Before changing remote access, write down the Gateway host, bind mode, port, authentication mode, every enabled channel, reachable agents, tool profile, sandbox mode, external credentials, and rollback location. This inventory prevents a successful connection from becoming the only evidence that was collected.

For a direct tailnet connection, verify all of the following:

• The Tailscale policy names the intended source and exact Gateway destination and port.
• The effective policy is not silently using a default allow-all configuration.
• The Gateway uses token, password, or a deliberately configured trusted-proxy mode.
• Channel DMs use pairing or an allowlist, and groups have explicit membership and mention decisions.
• Shared or multi-user DMs use an isolated session scope.
• Agents exposed to shared channels have minimal tools, no unnecessary personal credentials, and no unreviewed write or execution capability.

OpenClaw’s runbook lists openclaw doctor, openclaw security audit, openclaw security audit --deep, and openclaw health as baseline checks. Those commands can show configuration and runtime findings. They do not prove that a Tailscale rule expresses the intended business identity, so retain the tailnet policy review as a separate record.

Proposed tests, not claimed hands-on results

The following matrix is a proposed operator test plan. No OpenClaw installation or tailnet was tested for this article. Run the checks with disposable data and no real outbound action.

Keep the result of each test with the exact Gateway version, route, channel account, sender or room, and effective policy. A failed request alone is not enough to identify which gate rejected it.

Failure paths that expose the wrong assumption

The ACL is narrow, but the service has another route

Check loopback listeners, host firewalls, container port publishing, reverse proxies, public forwarding, and stale Serve or Funnel routes. Tailscale policy may protect one path while another path reaches the same process. OpenClaw specifically advises against unauthenticated non-loopback exposure and direct public port forwarding.

The Control UI works, but an API call fails

This may be the expected result rather than a broken ACL. Managed Tailscale identity headers have a documented narrow scope. Check the endpoint’s normal Gateway authentication requirements before widening network access or adding a proxy exception.

The Gateway is private, but the bot responds to the wrong people

This is a channel-policy problem. Review DM policy, pairing state, group allowlists, mention gating, command authorization, and session scope. Adding more Tailscale rules cannot express a missing sender or room condition.

A permitted device is lost

Remove the device or user from the tailnet policy, rotate the Gateway credential if it may have been exposed, and revoke channel credentials or browser sessions separately. Device removal is not application-secret rotation.

A shared Gateway is being mistaken for tenant isolation

OpenClaw’s trust model says authenticated operator access is a trusted control-plane role, not a hostile multi-user tenant boundary. If users do not trust one another, a cleaner ACL cannot repair the architecture. Separate the Gateway trust cells.

Bottom line

Tailscale ACLs are useful because they reduce who can reach the OpenClaw service. Keep that outer restriction narrow, and remember that an absent or broad tailnet policy may provide less protection than expected.

For direct tailnet binds, keep OpenClaw authentication. For managed Serve, understand the limited scope of verified Tailscale identity headers. In both cases, keep channel policy for the message itself: pairing, allowlists, group membership, mentions, command authorization, and session scope.

The final question is always four questions: who can reach the host, who can authenticate to the Gateway, which messages can create work, and what that work can do. Tailscale answers the first. OpenClaw must answer the rest.

Sources

• Manage permissions using ACLs · Tailscale Docs — ACL and grants scope, source/destination/port rules, default policy behavior, local enforcement, and the fact that ACLs do not affect local network traffic.
• Tailscale · OpenClaw — Serve and direct tailnet modes, Gateway authentication, verified Tailscale identity headers, their limited endpoint scope, and host-trust assumptions.
• Network exposure · OpenClaw — bind modes, Gateway authentication, firewall requirements, WebSocket authentication, and non-loopback exposure limits.
• Gateway exposure runbook · OpenClaw — exposure patterns, baseline checks, DM and group guidance, tool restrictions, rollback, and post-change validation.
• Access control and allowlists · OpenClaw — DM policies, pairing, group allowlists, mention gating, session scope, and command authorization.
• Security trust model · OpenClaw — one trust boundary per Gateway, shared delegated authority, and the limits of multi-user isolation.