OpenClaw is a personal AI assistant. The architecture reflects that clearly: one user, one workspace, one memory context, one set of API keys. That design is correct and deliberate. It's why OpenClaw works so well at the individual level — everything is optimized for a single-operator model.
But organizations are trying to deploy it at scale. Teams want shared access. Companies want SSO. IT departments want audit trails. Hackathon organizers want to provision hundreds of isolated environments. And the UNU Campus Computing Centre — which published a detailed write-up this week on their deployment journey — put the core problem clearly: "OpenClaw's default session mode collapses all conversations into a single shared context. In a shared deployment, User A's conversation history, files, and API keys become visible to User B."
That's not a bug. It's an architectural choice for single-user deployments. But it's a serious problem for multi-user ones.
The Security Risks at Organizational Scale
The gap between personal and organizational deployment isn't just about user management. There are concrete security failure modes that emerge when you scale without addressing the architecture:
Shared session context
Default OpenClaw collapses all users into one context. User A's files, API keys, conversation history, and workspace files become accessible to User B in a shared deployment.
Exposed gateway
Early 2026: 135,000+ instances found exposed to the internet. At organizational scale, the blast radius of a single exposed gateway is the entire organization's context and credentials.
Malicious skills
12% of community skills on ClawHub marketplace contained malicious code (per UNU research). In an org with shared skill installation, one bad skill affects everyone.
WebSocket hijack
A disclosed attack vector allowing full agent instance takeover via WebSocket. In a single-user deployment this affects one person. In a shared deployment, it can compromise the entire org.
The pattern: Every security risk that's manageable at individual scale becomes an organizational liability at team scale. The solution isn't hardening OpenClaw's code — it's adding an isolation infrastructure layer around it.
What the Infrastructure Layer Provides
Session isolation
Each user gets a fully isolated OpenClaw instance — separate workspace, separate memory, separate API keys. User A cannot access User B's context under any circumstances.
Corporate SSO
Sign in with your corporate identity (Google Workspace, Okta, Azure AD). No separate account management. Access control inherits from your existing identity infrastructure.
Audit trails
Every agent action logged with user attribution, timestamp, and tool call details. Compliance and security teams can review what agents did and who authorized it.
Network isolation
Each instance runs in its own network namespace. Cross-instance communication is explicitly prohibited. Compromise of one instance cannot propagate laterally.
Who Actually Needs This
-
🏢
Enterprise IT evaluating AI tooling
Need OpenClaw on approved infrastructure with corporate SSO, audit trails, and network controls. Can't deploy to production without these — IT won't approve it.
-
🎓
Universities and research institutions
UNU's use case: provisioning isolated workspaces for researchers, students, and hackathon participants. Need zero per-user configuration and isolation between participants.
-
👥
Small teams (2–20 people) sharing an agent
The most common case: a small business wants everyone on the team to have OpenClaw access without spinning up N separate instances and managing N separate configs. The infrastructure layer makes this tractable.
-
🔒
Regulated industries
Finance, healthcare, legal — industries where data separation between users isn't just good practice, it's compliance-required. Shared session context is a non-starter.
The Non-Developer Problem
UNU's team identified something important beyond the security architecture: the evaluation bottleneck. Organizations face a concrete problem when assessing AI agents — you can't evaluate what you can't try. And trying OpenClaw requires CLI familiarity, local installation, and developer time.
The people who make budget and strategy decisions — the ones who need to see the capability before approving it — often can't get through the setup. Proof-of-concept projects stall because the setup cost exceeds the evaluation budget. The gap between "I heard about this" and "I'm using it" kills adoption.
This is one reason ClawReady exists: reducing the setup barrier to the point where evaluation doesn't require a developer. But for organizational deployment at scale, you need more than setup help — you need the infrastructure layer.
Practical Approaches for Small Teams Right Now
If you're a team of 2–10 people trying to share OpenClaw access without a full Kubernetes infrastructure layer, there are pragmatic options:
Option 1: Separate instances per user (easiest)
Each team member runs their own OpenClaw instance on their own machine or a dedicated mini PC. Not truly "shared" access, but gives everyone their own properly isolated agent. Cost: ~$200/person one-time hardware + their own API costs. Management overhead is low once each instance is configured.
Option 2: Role-based channel routing (one instance, strict separation)
Run one OpenClaw instance. Configure strict channel routing so each team member only accesses their own designated channel (their private Telegram bot, their private Discord DM). Configure allowlists so each person can only reach their own context. Not perfect isolation, but significantly better than a fully open shared instance. Works for 2–5 person teams with some trust.
Option 3: Containerized instances per user
Run each user's OpenClaw instance in its own Docker container on a shared server. Full workspace isolation at the filesystem level. Requires more technical setup but gives genuine per-user isolation without the Kubernetes overhead. Suitable for 5–20 person teams with a technical administrator.
The honest answer for teams >20: You need purpose-built multi-tenant infrastructure. Running vanilla OpenClaw with workarounds at that scale creates technical debt that compounds quickly. The UNU approach — a proper isolation layer built on top of OpenClaw without forking the code — is the right architecture. It requires significant engineering investment, but it's the correct solution.
Skill Vetting: The Overlooked Risk
The 12% malicious skill finding from UNU's research deserves attention. At individual scale, a malicious skill affects one person who chose to install it. At team scale, a shared skill installation policy means one person installing a bad skill exposes everyone.
Org-level skill governance requires:
- Centralized skill approval: Only skills approved by an administrator can be installed
- Source verification: Only install skills from known, audited sources — not arbitrary ClawHub packages
- Regular audits: Review installed skills quarterly; check for new permissions declared in updates
- Sandboxed testing: Test new skills in an isolated instance before deploying to team instances
The Bottom Line for Teams
OpenClaw is powerful. At individual scale, properly configured, it's one of the most capable personal AI agents available. At team and organizational scale, the architecture requires supplementation — not modification of OpenClaw itself, but an infrastructure layer that provides what it doesn't ship with.
Small teams (2–5 people) can get reasonable results with per-user instances and strict channel routing. Medium teams (5–20) benefit from containerized deployment. Larger organizations need a purpose-built multi-tenant infrastructure layer.
The pattern holds regardless of scale: the gap between "OpenClaw installed" and "OpenClaw deployed correctly for your context" requires deliberate configuration decisions. For individuals, that's a weekend project. For teams, it's an infrastructure project.
Deploying OpenClaw for Your Team?
ClawReady's Business tier covers small team deployments — up to 5 users, containerized instances, channel routing configuration, shared skill governance, and security hardening. We handle the setup so your team is operational, not debugging configs.
See Business Setup Options →