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: 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 12 tools: six read, six write. Every tool is scoped to the organizations the user belongs to. The writes are narrow, and none of them destroys anything.
The four save tools write to the same AI Operating Model records your team already maintains in the web platform. They are a second door onto data you own, not a new category of data collection, and they are additionally gated by the altitude rule below. The connector cannot:
  • Delete anything. No tool in the connector deletes a record of any kind
  • Edit or overwrite any project, deliverable, Expert Request, contract, or existing opportunity — these remain strictly read-only
  • 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. Kowalah-side ownership fields cannot be set by a client, even on records the client creates
  • See another person’s training record, the cohort roster, trainer notes, or anyone else’s scores and feedback
  • 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.

​
The altitude gate on operating-model writes

Reading the operating model is open to everyone in the organization. Writing is governed by where the user sits in your own org-unit tree, resolved on every call: Admins and core team are cross-cutting editors within their own organization only, and being an admin in one organization confers nothing in another. Creating a new root unit reshapes the top of the org chart and is restricted to admins and core team. Anything the rule refuses is not a dead end: it routes to propose a process change, which files an opportunity against the process for its owner to pick up. Nothing about the process is modified.
Two guards stack on every write, and scope always resolves first: applyOrgScope decides whether the user may see the record at all, and only then does the altitude rule decide whether they may change it. A record belonging to another tenant reads as “not found” — the error wording is deliberately identical to a record that does not exist, so it cannot be used to confirm another customer’s data.

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