thClaws
← back to blog

What is thClaws Enterprise Edition

· Panutat Techasen — CEO, ThaiGPT Co., Ltd. ·อ่านภาษาไทย

For the past few weeks, the same kind of message kept landing in our inbox.

“We love thClaws. Can it route every LLM call through our private gateway?”

“We need single sign-on through Okta before IT will approve it for our team.”

“Can we lock down which plugins users can install? Our security policy is strict.”

“We want our own logo and product name on the binary.”

Different companies, different industries — banking, healthcare, government contractors, consulting firms. But underneath the requests, the same four asks kept appearing:

  1. A managed gateway — every LLM request through their own LiteLLM, Portkey, or internal proxy. For cost control, audit logs, rate limits per user or department.
  2. Single sign-on — identity from the corporate identity provider (Okta, Azure AD, Google Workspace, Auth0), so audit logs show alice@acme.com not device-token-X.
  3. Locked-down extensions — only allow plugins, skills, and MCP servers from approved sources. Reject everything else.
  4. Custom branding — their name, their logo, their support contact baked into the binary.

We could have built these as a separate closed-source fork. Or as features behind a license check that phones home. We did neither. thClaws Enterprise Edition shipped this week in v0.6.0, and here’s the shape of it.

The architecture: same binary, different file

thClaws Enterprise Edition is the same binary as the open-source release. There is no separate codebase. No “EE features” hidden behind a paywall. The code is identical, MIT/Apache-licensed, on GitHub, free.

What turns it into an “enterprise client” is a single artifact: a signed organization policy file.

┌─────────────────────────────────────────────────────────┐
│         thClaws binary (open source, MIT/Apache)        │
│                                                         │
│              Policy file?                               │
│              /  No        Yes  \                        │
│             /                   \                       │
│        Today's UX           Org rules apply             │
│        (open-core)         (branding, allow-list,       │
│                             gateway, SSO)               │
└─────────────────────────────────────────────────────────┘

The policy file is JSON, signed with the organization’s Ed25519 private key, deployed to user machines via the IT team’s normal channels (MDM, Intune, JAMF, configmap, login script). The thClaws binary verifies the signature against a public key embedded at build time. If the policy is invalid, expired, or signed by the wrong key, the binary refuses to start. No silent fallback, no “I’ll just run open-core anyway” — fail closed by design.

If there’s no policy file at all, thClaws behaves exactly the way it does for the open-source community. Zero overhead, zero behavior change. That’s important. The same binary serves a developer running a personal Ollama setup AND a Fortune 500 deploying it through MDM with strict policy enforcement.

How the four controls work

When a verified policy is loaded, four sub-policies activate. Each is independent — the org can turn them on selectively.

Branding

The product name, logo, support email, and welcome banner all flip from “thClaws” defaults to whatever the organization defines. Even the model’s system prompt updates: when a user asks the agent “what are you?”, it introduces itself with the org’s product name, not ours.

For an enterprise rolling thClaws out internally as “ACME Agent” or “Bank Internal AI” or whatever they call it, the binary genuinely is their product. The thClaws origin is in the license file and the contributor list, not in the user-facing surface.

Extension allow-list

Plugins, skills, and MCP servers can only be installed from organization-approved sources. The patterns support github.com/acmecorp/* (only this org’s repos) or *.acme.example (only internal hosts). Skills that ship executable scripts can be rejected outright. Everything else — random GitHub repos, public registries, the wider open-source ecosystem — is blocked.

The use case is data-leak prevention. Organizations that handle regulated data (PII, PHI, financial records, classified material) can’t have employees pulling random skills from the internet that might exfiltrate data through a malicious script. The allow-list moves “what can run on this machine” from a per-employee judgment call to a centrally-managed policy.

Gateway enforcement

Every LLM call routes through the organization’s private gateway. The user’s per-provider API keys (their personal Anthropic key, their personal OpenAI key) are ignored. The gateway handles upstream auth, applies cost controls, captures audit logs.

From the model’s perspective, nothing changes — same prompt, same response. From IT’s perspective, every byte of LLM traffic is now auditable. From Finance’s perspective, costs are visible per-user, per-department, per-project, in a single pane of glass instead of scattered across a dozen vendor invoices.

Single sign-on

When a user starts thClaws, they’re prompted to sign in with the organization’s identity provider. Their browser opens, they authenticate however IT requires (password + MFA, hardware key, SSO chain — whatever Okta or Azure AD enforces), and a token comes back. That token tags every gateway request.

The audit log no longer shows device-token-X used claude-sonnet-4-6. It shows alice@acme.com used claude-sonnet-4-6, 1247 tokens in, 856 tokens out, 14:23 UTC.

When alice leaves the company, IT disables her account in the IdP. The next time her token tries to refresh, it fails. She can’t make any more LLM calls. No re-deployment of anything on the thClaws side. The IdP is the source of truth, as it should be.

The SSO mechanism works against any standards-compliant OIDC provider — Okta, Azure AD / Entra ID, Auth0, Keycloak, Google Workspace, AWS Cognito, Ping Identity. One implementation, all IdPs. Switching from Okta to Azure is a one-line policy change.

Why we built it this way

Three principles drove the design.

Open core, not closed fork

The cloud-first AI products — Cursor, Claude Code, GitHub Copilot — all have closed enterprise tiers. Their EE features are locked behind license checks, separate codebases, separate sales motions. That’s the conventional pattern, and we think it’s the wrong pattern for a tool whose primary value comes from being trustworthy infrastructure.

We chose the GitLab / Mattermost / Sentry pattern instead: open-core, commercial wrapper. The features themselves live in the public codebase — anyone can read them, audit them, contribute to them. What’s commercial is the packaging: signed policy bundles, customer-specific branded binaries, support contracts, deployment assistance.

If a security team wants to verify thClaws behaves as advertised, they can read every line. If a customer wants to fork it, they can. If a competitor wants to reuse the policy mechanism for their own product, they can. None of that hurts us. What we sell is the relationship, not the bytes.

Policy file as the trust boundary

Identity, authority, “who’s allowed to do what” — all of that lives outside the binary. We don’t try to phone home. We don’t validate against a license server. We don’t gate features at runtime based on some opaque check. The org’s policy file is the policy.

This matters in three ways:

  • The binary has no “phone home” requirement. Air-gapped enterprises (defense, finance, classified environments) work the same as connected ones.
  • The org’s IT team controls everything. They sign policies on their schedule, they distribute them via their existing channels, they revoke and rotate using the same channels. We’re not in their critical path.
  • We never see customer data. There is no “EE telemetry” pipeline because there’s nothing to telemeter — the binary doesn’t talk to us, full stop.

Operator UX is part of the security story

A perfectly-secure design that requires admins to distribute env vars to 100 employees gets bypassed in practice. Typos accumulate. Credentials get pasted into the wrong .env. Files get accidentally committed to public GitHub repos. The first compromise comes from the friction.

We built EE so that the typical deployment is a single signed file. IT signs once on a secure machine, MDM pushes the file to user laptops, and that’s it. Nothing for employees to manage, nothing to type, nothing to leak. Less friction equals less bypass equals more security.

What’s honestly not yet there

To be straight about scope:

  • Tool-call audit — what files the agent reads or writes, what shell commands it runs — happens through the user’s local OS, not the gateway. Gating those would require either a network firewall or a future thClaws-side audit hook. Not in v0.6.0.
  • Live tenant smoke tests — we’ve validated end-to-end against Google Workspace. Okta and Azure AD work in unit tests but haven’t been exercised against real corporate tenants yet. Early customers will surface tenant-specific quirks; we’ll fix them in v0.6.x point releases.
  • Frontend branding — a handful of “thClaws” string literals in the React UI still aren’t routed through the branding module. The Rust-side branding (banner, window title, system prompt) is fully active; the GUI strings are a planned follow-up.

Any one of these can become a v0.6.x point-release the moment a customer asks. We’ve shipped same-day on similar requests before — see issue #29 (Windows bash crash → v0.4.1) and issue #30 (context-window override → v0.4.2) for the pattern.

Where to learn more

If you’re an IT admin evaluating thClaws for your organization, every artifact you need is in the public repo. No call required, no NDA, no “demo first” gate.

Download the binary, generate your keypair, sign a policy, see how it deploys. We’re standing by if you have questions.

We built this for the kind of organization that asked us for it. If that’s you, the door is open.

🦞