> ## 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.

# Data and access control

> How Kowalah authenticates users, isolates each organization's data, enforces role-based permissions, and limits what the connector can do.

This page explains how access is authenticated and authorized, how one organization's data is kept separate from another's, and how data is handled once a request is made.

## Authentication

There is no anonymous access. Every request is tied to a real, authenticated user.

<Tabs>
  <Tab title="Claude Connector">
    Users authenticate through **OAuth** using their Kowalah account, handled by [Clerk](https://clerk.com) (our identity provider). A workspace admin adds the connector once; each user then signs in individually on first use.

    Each request to the MCP server carries a signed token that the server verifies cryptographically (against Clerk's published keys) before doing anything. The server is **stateless** — every request is independently authenticated and scoped, and nothing is cached on Claude's side.
  </Tab>

  <Tab title="Kowalah Agent">
    A user links their Slack or Teams identity to their Kowalah account once (see [chat platform security](/security/chat-platforms)). After linking, Kowalah issues a **per-user access token** that maps that person to their Kowalah identity and organization.

    The raw token is stored only in [Anthropic's secure vault](https://www.anthropic.com); Kowalah stores only a one-way SHA-256 **hash** of it, never the token itself. On each request, the token resolves to the same authenticated user context as the Connector — so the Agent sees exactly what that user would see in Claude Desktop, and nothing more.
  </Tab>
</Tabs>

## Tenant isolation

This is the question security teams care about most: *can one customer ever see another customer's data?* No.

* Every database query the connector runs passes through a **single shared function** (`applyOrgScope`) that filters results to the organizations the requesting user belongs to.
* A user's organizations are resolved from accepted memberships only — pending or revoked invitations grant no access.
* Clients are **never** run in an unrestricted mode. The unrestricted path exists only for Kowalah's separate internal systems, which customers never connect to.
* This boundary is covered by automated tests, precisely because a regression here is the kind that would otherwise be invisible.

<Warning>
  The connector reads from Kowalah's customer database schema only. It has **no access** to Kowalah's internal/admin systems, employee data, or any other organization's records.
</Warning>

## Role-based permissions

Within your own organization, what a user can see and do depends on their role — the same three-tier model as the [platform](/platform/organization/roles-and-permissions):

| Role          | Can do                                                                           |
| ------------- | -------------------------------------------------------------------------------- |
| **Admin**     | Full visibility across the organization's programme, plus create and manage work |
| **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 — a user who is an admin in one organization is not automatically an admin in another.

## Least privilege: what the connector can and can't do

The connector exposes exactly **three tools**, and the most powerful thing any of them does is create a new opportunity for Kowalah to review.

<CardGroup cols={3}>
  <Card title="Get an update" icon="clipboard-list">
    **Read only.** Returns programme status scoped to your organization and role.
  </Card>

  <Card title="Find an accelerator" icon="rocket">
    **Read only.** Searches the Kowalah library and your organization's private accelerators.
  </Card>

  <Card title="Raise an opportunity" icon="lightbulb">
    **Create only.** Adds a new idea to your triage queue. Non-destructive.
  </Card>
</CardGroup>

The connector **cannot**:

* Edit, overwrite, or delete any existing project, deliverable, Expert Request, or opportunity
* Read tasks, risks, or decisions that haven't been explicitly marked client-visible
* See internal fields such as contract values, payment amounts, or assigned Kowalah staff — these are stripped from every response at the query level
* Access organization settings, member management, billing, or any administrative function
* Reach any data outside the organizations the user belongs to

These limits are structural, not policy — the code to do these things is not present in the connector.

## Data handling and retention

* **In transit:** all traffic is encrypted with TLS between every hop — your client, Anthropic, the Kowalah MCP server, and the database.
* **At rest:** the Kowalah database and supporting infrastructure are managed services that encrypt data at rest.
* **On demand, not bulk:** data is fetched for a single request and returned. The connector does not copy, mirror, or warehouse your data, and it does not scan or ingest your chat history.
* **Stateless connector:** the MCP server keeps no per-user session. The Agent caches short-lived conversation context to maintain a thread, which expires automatically.
* **Model handling:** see [subprocessors and compliance](/security/subprocessors) for how Anthropic handles inputs — in short, your data is not used to train models.

<Info>
  Specific data residency, retention windows, and deletion timelines are documented in the [Data Processing Agreement](/security/subprocessors), available to customers on request.
</Info>