Operate AI agents with a real control plane

Definitions and verified context

Bottom line: a Secure Enterprise Agent Control Plane authenticates callers, maps them to workspaces, meters governed requests, and records audit context before inference reaches your vaulted providers.

Control plane

Identity, RBAC, routing, spend governance, and audit above model execution — not a second model host.

Execution / data plane

Your Connected Infrastructure (BYO OpenAI-compatible or Anthropic endpoints) where completions actually run.

Governed request

Kimss product meter for control-plane traffic (Developer 25k / Production 100k / Scale 1M included monthly).

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: /trust.

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, matches the SSO principal to iam.mcp_tool_grants, then validates optional iam.tool_argument_policies before Hermis lets an internal MCP tool run.

See the Trust Center for security posture.

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

Keep the OpenAI or Anthropic client you already ship, or start from Kimss Forge. Billing, SCIM, and backoffice routes stay on the admin APIs your platform team opts into.

New integrations follow /docs/route_traffic: Gateway key, vaulted model alias, and X-Kimss-Agent-Id. Do not install the kimss control-plane package to connect. Coding agents fetch github.com/kimss-ai/kimss-control-plane.

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