Isolation
Cross-org isolation, end-user isolation, server-side-only keys.
Harnix is built multi-tenant from day one: every piece of business data (agents, knowledge bases, documents, conversations, runs, run history…) is tied to exactly one organization, and every read or write goes through a layer that enforces that scoping — it isn't a filter bolted on at the API afterward. Organization A cannot, through any public API or console path, read or modify organization B's data.
Cross-organization isolation
- Every admin request authenticates through your sign-in identity, and the organization named in the URL must match the one you belong to — otherwise it returns "not found" (404), not "forbidden" (403), so probing for another organization's id can't confirm whether it exists.
- A full isolation test suite runs against every route before a change ships — a new org-scoped route missing an isolation test case blocks the release; it isn't left to convention.
End-user isolation
Within the same organization, one end-user cannot read another end-user's conversations or runs. This holds for:
- Anonymous identity (publishable key only) — each browser session is its own end-user.
- Signed identity (
end-user-id+user-hash) — the end-user id your backend issues, verified by signature, never taken at face value. - Server-to-server calls with an API key — an API key from organization A can never reach a run or conversation belonging to organization B, even by guessing ids.
Keys and secrets stay server-side
API keys, the identity secret, an agent's LLM credential, and an MCP server's auth headers should only ever live on your backend — never in code that runs in a browser or a mobile app. The publishable key is the deliberate exception: it's safe to expose because it only opens token exchange, and only from the domains you allow (see Integration).
See Data for what is stored and how it's encrypted.