Operate AI agents with a real control plane

What an enterprise AI control plane must do

A control plane sits above model execution: it authenticates callers, maps them to workspaces, attaches RBAC decisions, meters usage as governed requests, and records auditable context before any agent or completion reaches your vaulted provider endpoint.

Most teams start by calling Azure OpenAI or Connected Infrastructure directly from application code. That works for a prototype, but production quickly needs consistent identity, spend limits, and tenant boundaries that a raw project key cannot express. Kimss provides that layer as a product: workspaces, API keys, Entra ID sign-in, PostgreSQL-backed isolation, and normalized governed requests.

Kimss is not a consumer chatbot. It is an integration framework your engineers embed in services, internal tools, and automation. The universal gateway exposes routes such as POST /v1/agents/run and POST /v1/models/completions so clients have one contract while the platform routes to the correct vaulted endpoint per workspace.

Control plane versus execution plane on Azure

Providers remain the data plane where agents and models run (vaulted CI (BYO OpenAI-compatible), or mixed). Kimss is the control plane that decides who may invoke which agent, under which budget, with which audit metadata—without replacing your runtime.

This split mirrors mature cloud patterns: Kubernetes schedules pods; your platform team defines namespaces and quotas. Similarly, your model provider executes inference; Kimss defines workspace membership, governed-request allowances, and routing tables that map authenticated tenants to vaulted endpoints.

Optional Azure API Management can sit in front of AI traffic for gateway diagnostics, but customer inference uses APIM byo-proxy. Architecture: /docs/architecture.

Developers still use familiar concepts—agents, tools, conversations—but those objects are scoped to a workspace. A support automation and a finance copilot can share one Azure subscription yet remain logically separated at the Kimss layer.

Zero-Trust gates and the Hermis pause

Identity-blind models never see your Entra groups. Kimss authenticates the scoped API key, then matches the SSO principal to iam.mcp_tool_grants before Hermis lets an internal MCP tool run.

Interactive diagrams: Zero-Trust AI architecture.

Governance primitives teams actually operate

Effective governance is operable: monthly workspace allowances, optional group budgets inside a workspace, RBAC roles, SCIM provisioning hooks, and usage attribution down to agent and billing key—not a PDF policy alone.

governed requests normalize heterogeneous model pricing into a unit product teams can allocate. Workspace administrators set monthly allowances; group budgets add a soft allocation layer for departments without changing the tenant-wide enforcement boundary. When consumption approaches limits, operators see it in product surfaces before Azure invoices arrive.

Identity flows through Microsoft Entra ID for interactive users and API keys for service accounts. Workspace isolation in PostgreSQL ensures one tenant’s agents, files, and ledgers do not leak into another’s queries. Public API documentation lives at /docs/api_docs—not production Swagger—to match the supported integration contract.

For regulated environments, pairing Kimss attribution with Azure Monitor, Log Analytics, or APIM GatewayLogs (when enabled) gives a defensible trail: who invoked what, when, and under which workspace budget.

Developer integration without losing the boundary

The published kimss Python package and optional MCP server expose the supported agent, model, file, and vector-store paths—while billing, SCIM, and backoffice routes stay on explicit admin APIs your platform team opts into.

New integrations should prefer /v1/agents/run over legacy /assistant_* routes. The Python SDK wraps the supported surface; MCP exposes a focused tool subset for IDE and agent workflows. Authentication uses X-Kimss-Key or bearer tokens, with X-Workspace-ID when a credential spans multiple workspaces.

Kimss deliberately does not wrap every administrative endpoint in the SDK. Treat the shipped SDK documentation and /docs/api_docs as the contract rather than assuming route parity with internal admin tools.

Frequently asked questions