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 into credits, and records auditable context before any agent or completion reaches Foundry or a vaulted customer endpoint.

Most teams start by calling Azure OpenAI or Azure AI Foundry 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 Foundry project or shared shard.

Control plane versus execution plane on Azure

Providers remain the data plane where agents and models run (Foundry hosted, 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 pools, 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 pools; 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.

Implementation patterns for enterprise AI control planes

Teams succeed with enterprise AI control planes when they treat Kimss as the integration boundary: applications never hold provider secrets, every call includes workspace context, and operators review governed-request trends before expanding model access.

Start in a non-production workspace. Wire control-plane APIs against POST /v1/agents/run or POST /v1/models/completions using X-Kimss-Key or a bearer token. Validate streaming, tool invocation, and error paths your production clients rely on.

Document which Entra groups map to which workspace roles. Align governed-request allowances with monthly governed-request allowances so finance sees predictable units rather than surprise token spikes on the Azure invoice.

Publish an internal integration checklist: required headers, workspace identifiers, approved models, and escalation paths when governed-request allowances approach exhaustion.

Use /docs/architecture to confirm the APIM byo-proxy path for customer inference. Foundry ai-proxy is not the customer default.

When agent workloads spans multiple internal products, give each product its own API key or sub-workspace budget so attribution stays legible in usage aggregates and billing ledgers.

Common mistakes when rolling out enterprise AI control planes

The costliest errors are shared Foundry keys in microservices, skipping workspace headers on multi-tenant keys, and migrating user-facing flows before server-side credit enforcement is tested.

Embedding one project key in every service bypasses Kimss RBAC and makes revocation a company-wide fire drill. Issue workspace-scoped keys per service or per environment instead.

Assuming legacy /assistant_* behavior matches /v1 governance causes silent gaps in metering or identity. Inventory clients with /assistants-to-v1-migration and retire legacy paths deliberately.

Treating governed-request limits as cosmetic reporting rather than enforced allowances invites overrun. Configure exhaustion policies in staging and confirm blocked requests behave as product management expects.

Publishing internal runbooks that reference production Swagger instead of /docs/api_docs creates integration drift. The public API reference is the supported contract for external integrators.

Skipping staging verification for streaming and tool calls leads to production surprises. Exercise the same client libraries and timeouts you expect under peak load.

Next steps for enterprise AI control planes

Create a workspace, read /why-kimss for positioning, follow /python-sdk-mcp-quickstart for code, and engage /enterprise when contractual isolation, capacity, or onboarding differ from self-serve plans.

Self-serve teams typically progress: signup, first agent run via SDK, governed-request allowance configuration, Entra SSO for Studio users, then wider rollout to internal consumers or customer tenants.

For enterprise AI control planes, schedule a monthly review of usage aggregates, ledger entries, and agent inventory. Remove unused keys, archive obsolete agents, and adjust group budgets after major launches.

Customer-facing ISVs should pair Kimss workspace design with /multi-tenant-ai-security and /ai-rbac-and-identity so each end customer receives isolated agents, files, and usage rows.

Track product changes at /changelog and deeper narratives at /insights so your platform team does not miss SDK or API shifts that affect deployed clients.

Documentation and honest scope

Kimss documents the supported integration surface at /docs/api_docs and system design at /docs/architecture—avoid assuming every internal admin route is available in the public SDK or MCP server.

Platform engineers should bookmark /docs/api_docs as the contract for external integrators. When product management requests a feature, verify whether it exists on /v1, requires an admin API, or needs net-new development before committing customer timelines.

governed requests, Entra SSO, workspace RBAC, and PostgreSQL isolation are first-class product capabilities—not marketing adjectives. Validate them in your tenant with test workspaces and realistic agent workloads rather than slide-deck assumptions.

Optional Azure API Management integration remains documented as an advanced path. Production enablement should follow your organization's verification checklist for gateway telemetry and routing parity with direct Foundry execution.

When questions fall outside public documentation, enterprise customers can reach Kimss via /enterprise. Self-serve builders can use in-product support after signup.

Verify before you scale

Treat Kimss as production infrastructure: validate identity, governed-request caps, and routing in a staging workspace, read /docs/api_docs for the supported contract, and expand pools only after usage patterns are understood.

Platform teams should run monthly reviews of workspace keys, agent inventory, and ledger entries. Remove unused credentials, archive obsolete agents, and align governed-request allowances with teams that actually ship. Pair Kimss attribution with Azure Cost Management for infrastructure truth—Kimss meters governed requests on the control plane; Azure (or your provider) still bills underlying model consumption.

When you need help beyond public documentation, self-serve builders use in-product support after signup; enterprise buyers start at /enterprise for onboarding, capacity, and contractual questions. Product changes publish at /changelog so integrators can track SDK and API shifts over time.

Frequently asked questions