Skip to main content

Kemble for enterprise

What an organization with a compliance function needs to know, stated plainly — including the parts that are not built yet.

What is in place today

Each of these is implemented and can be demonstrated.

Tenant isolation
Every organization is a separate tenant. Reads go through a database client bound to your organization, so the filter is applied by the data-access layer rather than written out by each endpoint — and the build refuses any query that opts out of it without a recorded reason.
Who can see a private channel
The people in it, and the owners and administrators of the space it belongs to. Space administrators reach any channel in their own space without joining it, which is how moderation and recovery work — and it is worth knowing before you put something in one.
Role-based access control
A closed permission catalogue, unlimited custom roles, grants at organization, space and channel scope, and per-channel allow and deny overwrites layered on top.
Audit trail
Consequential actions write an audit row naming the actor, the action, the target and the time. Readable by the organization with pagination and filters, and by platform staff separately.
Session control
Every live session is listed with its device and last-seen, and any of them can be ended. Suspending an organization revokes its sessions immediately rather than waiting for them to expire.
Transport and storage
HTTPS everywhere, credentials hashed with Argon2, object storage for uploads, and outbound integrations re-vetted against server-side request forgery on every delivery attempt.
Two-factor authentication
TOTP, against RFC 6238 rather than a library — the specification publishes test vectors, so "did we implement this correctly" has a mechanical answer. A correct password alone does not produce a session once it is on; the challenge is single-use and every failure is the same 401. Recovery codes are hashed, consumed in one conditional write, and cleared when 2FA is turned off, because somebody disabling it may be doing so BECAUSE they were compromised.
Single sign-on (OpenID Connect)
An organization points Kemble at its identity provider and its people sign in there. Routing is by verified email domain — a TXT record proves ownership before an address is sent anywhere, because without that one tenant could claim a public domain and receive everybody else's sign-in. A connection stays off until somebody enables it, so a typo in the issuer cannot lock a tenant out of the product they just configured. State, nonce and PKCE on every flow; identity keyed on the provider's stable subject rather than on an email address, which is reassignable.
Shared channels
Invite somebody outside your organization into one channel and nothing else. They see that room and no other — not the rest of the space, not in search, not in their inbox — because the invitation names the channel and the membership it creates is confined to it. Guests invited to a whole space keep the reach they had; the rule applies only to memberships a channel invitation made, which is what let it ship without changing anybody's existing access.
Directory provisioning (SCIM 2.0)
Your identity provider adds and removes people automatically. Removing somebody ends their live sessions in the same operation rather than when a token happens to expire, which is the difference between an offboarding control and a member list that merely looks right. Deactivation, not deletion: losing access does not mean a year of somebody's messages disappears from other people's conversations. Group sync is refused outright rather than accepted and ignored — roles are decided in Kemble, and a 200 that does nothing is how an administrator comes to believe otherwise.
Passkeys
WebAuthn, with usernameless sign-in where the device supports it. A passkey is possession of a device plus a local biometric or PIN, so it does not then ask for a six-digit code — it already is multi-factor, and phishing-resistant in a way a code is not. An account holds up to twenty, because losing one device should not lock anybody out, and the challenge behind each sign-in is single-use, purpose-bound and stored where a cache outage cannot silently accept a replay.
Retention and legal hold
An organization sets how long messages are kept and the rest are deleted on a schedule, permanently. A legal hold suspends that entirely — and it is a precondition on running a sweep rather than a filter applied to one, so a held organization is skipped before its cutoff is even computed. Releasing a hold keeps the record of who placed it and why; the row is never deleted, because what was held and when it was let go is the part somebody asks for afterwards.
Enforced quotas
Per-plan ceilings on members, spaces, storage, file size, request rate and AI spend — enforced on the request path, not reported after the fact.

What is not built yet

A trust page that lists only strengths is not a trust page. These are on the roadmap and are not available today:

  • SAML. OpenID Connect and SCIM are built — see above — and SAML is not.
  • Compliance export. Retention and legal hold are built — see above — and a signed export bundle is not.
  • Formal SOC 2 and ISO 27001 certification. The controls are being built toward them; the audits have not been done.
  • Regional data residency. There is one region.
Talk to us