Last updated: August 16, 2026
Identity is the enforcement point
Kimss validates Entra-backed sessions and workspace API keys on every request, then applies RBAC roles before agent runs, key rotation, or usage views are allowed.
Enterprise AI fails open when a single shared key lives in environment variables. Kimss binds callers to workspaces: human users via Microsoft Entra ID, services via kimss_* API keys with server-side permission checks.
Multi-workspace keys include X-Workspace-ID so one automation account can address multiple tenants without blending data.
RBAC inside the workspace
Roles separate administrators, builders, and viewers so least privilege is default—only operators who must rotate keys or change allowances can do so.
RBAC complements Entra groups: directory membership gets users into the product; workspace roles define what they can change. SCIM-oriented flows help keep membership aligned as organizations scale.
Consult /docs/architecture for how RBAC interacts with agent creation, billing visibility, and admin APIs.
Internal MCP tools add a second gate: after the scoped API key is valid, Kimss matches the Entra/SSO payload to iam.mcp_tool_grants. See Zero-Trust AI architecture.
Entra ID and SSO for Studio
Interactive access to Kimss Studio and admin experiences flows through Entra SSO—meeting enterprise expectations for MFA, conditional access, and offboarding via directory disables.
Service integrations remain on API keys with explicit rotation and audit. This split matches how teams secure human consoles versus machine credentials elsewhere in Azure.
Designing identity for multi-tenant products
ISVs map each customer organization to a Kimss workspace (or hierarchy) so RBAC, governed requests, and provider routing stay isolated while you maintain one Azure footprint.
Pair workspace design with /multi-tenant-ai-security guidance and governed-request allowances from /ai-spend-caps-and-credits so customer A never inherits customer B’s agents or ledgers.