Secure multi-tenant AI with Kimss

Multi-tenancy is a data and identity problem

Kimss isolates tenants in PostgreSQL with workspace-scoped agents, files, keys, and ledgers—so one customer’s prompts and embeddings do not appear in another’s queries.

Sharing a single provider project or API key across customers without a control plane invites cross-tenant leakage. Kimss encodes tenant boundaries in authentication, ORM scoping, and API design so developers do not rely on convention alone.

Defense in depth on Azure

Kimss runs on Azure with private networking patterns appropriate to production; customers still apply Azure Policy, Key Vault, and Monitor in their subscriptions.

Security architecture combines Kimss workspace isolation with your landing zone controls. Optional APIM can add gateway logging when verified. Kimss does not invent compliance certifications—document what your deployment actually implements.

Secrets and key hygiene

Workspace API keys rotate through admin flows; Provider credentials stay server-side in Kimss routing—not copied into every developer laptop or CI job.

Service accounts should use least-privilege workspace keys. Human access uses Entra SSO with MFA via your tenant policies. MCP and SDK setups must store KIMSS_API_KEY outside repositories.

Operational response

When incidents occur, workspace-scoped attribution and billing ledgers identify affected tenants; keys rotate per workspace without global outages for unrelated customers.

Run tabletop exercises on key compromise and allowance exhaustion. Pair Kimss controls with enterprise support via /enterprise for contractual response expectations.

Frequently asked questions