> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kowalah.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access and identity controls

> How users sign in, how role-based permissions work, and the controls that stop users doing more than they should on the Kowalah platform.

This page covers identity and access for the **platform** (`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](/security/data-and-access).

## Authentication

* **No anonymous access.** Every request is tied to a real, authenticated user. Identity is handled by [Clerk](https://clerk.com), 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.

| Role          | Can do                                                                                       |
| ------------- | -------------------------------------------------------------------------------------------- |
| **Admin**     | Full visibility across the organization's programme, plus create and manage work and members |
| **Core team** | Triage and submit work, see organization-wide views                                          |
| **Member**    | See their own relevant data and raise opportunities                                          |

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](/platform/organization/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.

<CardGroup cols={2}>
  <Card title="Server-side authorization" icon="shield-check">
    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.
  </Card>

  <Card title="Tenant scoping" icon="building-2">
    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.
  </Card>

  <Card title="Least-privilege AI tools" icon="lock">
    The AI surfaces expose a deliberately small tool set — mostly read, with no ability to edit or delete. See [least privilege](/security/data-and-access).
  </Card>

  <Card title="Input validation and rate limiting" icon="filter">
    Requests are validated, and sensitive and public endpoints are rate-limited to resist misuse and automated probing.
  </Card>
</CardGroup>

## Joiners and leavers

Access is enforced per user on every request, so deprovisioning takes effect immediately.

<Steps>
  <Step title="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.
  </Step>

  <Step title="Chat identities can be revoked centrally">
    For the [Kowalah Agent](/security/chat-platforms), a user's linked chat identity and per-user token can be revoked, and revoked or expired tokens are rejected immediately.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Info>
  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.
</Info>