Enterprise IT
Give internal teams a shared gateway
One internal gateway your departments share — isolated tenants per team, admin-controlled, no data crossover.
The problem
- Every team wants an AI assistant on your messaging stack, but you can't stand up (and secure) a separate deployment for each department.
- Different teams have different data-sensitivity — legal's assistant must not see engineering's session history, and vice versa.
- Security needs an auditable isolation story and a single place to rotate credentials and control what tools each team can run.
With OpenClawMU
- One gateway, one internal hostname, isolated tenants per team. Each team's sessions, memory, plugins, sandboxes and channel credentials live in their own directory, keyed by a token.
- Admin-only keys (LLM credentials, rate card, S3 config) live in the gateway config; a team can override its own model choice and allowed tools via a config overlay but cannot read or override platform secrets.
- Front the gateway with Tailscale Serve/Funnel, a Cloudflare Tunnel, or your own reverse proxy — TLS termination and the public hostname are your call.
How it works
Getting there, step by step.
- 1
Deploy one internal gateway
Install the gateway on a managed VM and bind it to 127.0.0.1; front it with your reverse proxy or Tailscale for internal access.
- 2
Create a tenant per team
Provision a tenant for legal, engineering, support, etc. Hand each team lead their token via your secret store.
- 3
Set per-team policy
Use tenant config overlays to set each team's model, max tokens, and allowed tools — while admin-only keys stay locked in the gateway config.
- 4
Rotate on schedule
Rotate a team's token with `openclaw tenants token rotate <team>` if it ever leaks — no gateway restart required.
# one gateway, many tenants
npm install -g openclaw@latest
openclaw onboard --install-daemon
# a tenant per customer / team
openclaw tenants create acme Frequently asked
FAQ — give internal teams a shared gateway
Every question here is also emitted as FAQPage JSON-LD — so Google AI Overviews, Perplexity, and ChatGPT browsing extract the answers cleanly. Crawler-friendly fallback below for screen readers and bots that don't run JS.
No path through the public API exposes another tenant's state. The dispatcher resolves the tenant from the token and routes to per-tenant directories; path-traversal escapes are rejected at the boundary.
No. Tenants can override their own model, max tokens, system prompt and allowed tools via a config overlay, but admin-only keys (API credentials, rate card, S3 config) are rejected at load time.
Related use cases
-
Ship a multi-tenant bot platform
The agent platform you're building needs isolation between customers without inventing it from scratch.
Read → -
Audit and back up every tenant
Snapshot, restore and account for every tenant — S3-portable backups and per-tenant usage reports.
Read → -
How isolation works
The load-bearing change vs. upstream — tokens, per-tenant directories, path-traversal hardening.
Read the deep dive →
EXFOLIATE!
Run your own gateway today.
Apache-2.0, self-hosted, no SaaS layer between you and your users. Install the CLI, create your first tenant, mint a token — you're routing traffic in 60 seconds.