Skip to main content
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.
Users authenticate through OAuth using their Kowalah account, handled by Clerk (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.

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

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:
RoleCan do
AdminFull visibility across the organization’s programme, plus create and manage work
Core teamTriage and submit work, see organization-wide views
MemberSee 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.

Get an update

Read only. Returns programme status scoped to your organization and role.

Find an accelerator

Read only. Searches the Kowalah library and your organization’s private accelerators.

Raise an opportunity

Create only. Adds a new idea to your triage queue. Non-destructive.
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 for how Anthropic handles inputs — in short, your data is not used to train models.
Specific data residency, retention windows, and deletion timelines are documented in the Data Processing Agreement, available to customers on request.