app.kowalah.com): how people sign in, what their role lets them do, and the controls that prevent a user from doing more than they’re entitled to. For access through the AI surfaces specifically, see data and access control.
Authentication
- No anonymous access. Every request is tied to a real, authenticated user. Identity is handled by Clerk, a dedicated identity provider.
- Separate identity for internal systems. The customer platform uses a different authentication configuration from Kowalah’s internal/admin systems, so the two are isolated.
- MFA supported. Multi-factor authentication is available through Clerk.
- Enterprise SSO supported. Your team can sign in through your own identity provider (for example, Microsoft Entra ID or Okta) via Clerk. Talk to your Kowalah team to enable SSO for your organization.
Role-based permissions
Within your organization, what a user can see and do depends on their role — a three-tier model applied consistently across the platform and the AI surfaces.
Roles are resolved per organization on every request — being an admin in one organization grants nothing in another. Full detail is on the platform roles and permissions page.
Limiting what a user can do
Authorization is enforced server-side, on every request, not in the interface. A user cannot gain access simply by manipulating the client.Server-side authorization
Every API request is authenticated and checked against the user’s role and organization before it does anything. The check does not rely on the client.
Tenant scoping
Queries are scoped to the organizations the user is an accepted member of, so a user cannot reach another organization’s data by changing an identifier.
Least-privilege AI tools
The AI surfaces expose a deliberately small tool set — mostly read, with no ability to edit or delete. See least privilege.
Input validation and rate limiting
Requests are validated, and sensitive and public endpoints are rate-limited to resist misuse and automated probing.
Joiners and leavers
Access is enforced per user on every request, so deprovisioning takes effect immediately.1
Removing a user ends their access
Disabling or removing a user in your identity provider, or in Kowalah, ends their access on the next request. There is no long-lived session that outlives the account.
2
Chat identities can be revoked centrally
For the Kowalah Agent, a user’s linked chat identity and per-user token can be revoked, and revoked or expired tokens are rejected immediately.
3
Admins govern who can use what
Your organization admins manage members and roles, and your normal joiner/leaver process governs platform access alongside your other tools.
If your review needs specific controls confirmed — session timeouts, MFA enforcement policy, or SCIM provisioning — send the requirement to your Kowalah team and we’ll confirm what applies to your contract.