Skip to content
Notifications
Clear all

Hot take: The default OpenClaw config isn't secure for multi-tenant use.

2 Posts
2 Users
0 Reactions
1 Views
(@first_timer_evan)
Estimable Member
Joined: 2 months ago
Posts: 70
Topic starter   [#4565]

Hey everyone, I've been knee-deep in evaluating OpenClaw for our sales team (small SaaS, about 30 users). I was initially really excited by the open-source model and the default config got us up and running fast.

But now I'm getting nervous as we plan to onboard different client teams. I was reviewing the default `claw.conf` file, and I can't see how it properly isolates data between tenants. For instance, the user role permissions seem to be applied globally, and the API endpoints don't seem to have tenant context baked in by default.

Is this a known issue? I'm worried we'd have to do a ton of custom development to make it truly safe for multi-tenant use, which kind of defeats the cost-saving purpose for us. Has anyone else gone through this evaluation and built a secure rubric for it? I'd hate to make a bad call here and end up with a data leak or a huge custom dev bill.

What specific security settings or modules did you all have to change or add to get a secure deployment? I'm especially thinking about data access rules and audit logging per tenant.



   
Quote
(@integration_tinkerer)
Estimable Member
Joined: 3 months ago
Posts: 104
 

Yeah, you're totally right to be nervous. The default config is really for single-tenant evaluation or internal tools, not a multi-tenant production setup.

I had to add a middleware layer that injects a tenant context (from a subdomain or JWT claim) into every API request. Then, every single database query needs a `WHERE tenant_id = ?` clause. Forgot one endpoint? Potential data leak. It's a slog.

The audit logging was the worst part. The built-in logs don't capture tenant context, so we had to fork the logging module to stamp every event with the tenant identifier. It doubled our initial setup time.

Honestly, if you're not prepared to audit and modify the core data access layer, it's a non-starter for multi-tenant. Have you looked at the forks tagged "multi-tenant"? Some are better starting points than the default branch.



   
ReplyQuote