Last updated: October 3, 2026
The short answer
Kimss does not provision Azure AI Foundry. Pair them only if you already own Foundry: it remains your execution plane; Kimss is the secured control-plane proxy — Guardrails, identity, kill switch, governed requests — in front of Foundry or any other LLM provider. Kimss does not host models.
Provider projects hold models, agents, and Azure-native tooling. What a provider project alone does not automatically provide is a SaaS-style multi-tenant product layer: per-customer isolation, productized RBAC, finance-friendly usage units, and a single developer key that embeds governed agents into many codebases.
Kimss fills that gap for ISVs, internal platform teams, and enterprises shipping AI into products. Each workspace maps members, API keys, agent definitions, and vaulted endpoints—while routing selects the customer’s vaulted endpoint or OpenAI-compatible backend.
Capability comparison
Use this table in architecture reviews. Columns contrast Azure AI Foundry alone with Foundry plus Kimss—not Kimss as a competing model runtime.
| Capability | Azure AI Foundry alone | Foundry + Kimss |
|---|---|---|
| Model & agent execution | Native Foundry projects | Your vaulted Connected Infrastructure endpoint — Kimss does not host models |
| Multi-tenant workspaces | Build yourself | PostgreSQL workspace isolation |
| Identity (Entra SSO, SCIM on Scale and Enterprise) | Wire yourself | Productized Entra + workspace RBAC |
| One key: chat + agents | Separate integration paths | Universal /v1 gateway |
| Spend control | Ad-hoc / per-project | Governed-request caps + FinOps estimated spend |
| Usage & chargeback | Custom metering | Trust-labeled meters (self-reported vs gateway-verified) |
| Audit trail | You design the sink | Optional APIM → Log Analytics |
| Procurement | Provider billing only | Marketplace PAYG + invoice options |
When to choose Foundry alone
A single team with one provider project, no multi-tenant product surface, and no need for productized governed-request metering may stay on Foundry alone—especially for early prototypes.
If you are exploring models inside Azure without embedding agents into customer-facing applications, Foundry Studio and project-level controls may be enough. Governance can live in runbooks and Azure Cost Management until you productize.
The tipping point is usually the second tenant, the first finance review that asks for chargeback, or the first security questionnaire that asks who can change prompts and which key can call production agents.
When to add Kimss
Add Kimss when you need many teams or customers on shared Azure AI infrastructure with enforceable identity, budgets, and audit-friendly metadata—without staffing a permanent internal control-plane team.
Platform teams use Kimss so internal products share provider capacity safely. ISVs map each customer tenant to workspace-scoped agents, files, and usage rows. Builders keep POST /v1/agents/run and the Python SDK; operators configure policy once per workspace.
Optional Azure API Management logging can supplement Kimss-side attribution—verify with /docs/security_compliance before enabling gateway-only modes in production. Audit log of administrative actions and governed requests, with configurable retention.
Related AI governance reading
Deepen the governance story with dedicated authority pages and the CTO brief.
Read /ai-governance-for-enterprises for workspace-boundary patterns, /ai-gateway for gateway positioning, and /docs/why_kimss for the executive narrative used in sales and architecture reviews.
Frequently asked questions
Does Kimss provision Azure AI Foundry?
No. That offering is retired. Kimss does not create or host a Foundry project. Vault the endpoint you already pay for.
Is Kimss an Azure AI Foundry alternative?
Kimss does not replace Foundry as a model host. Foundry (or any OpenAI-compatible endpoint) remains your data plane; Kimss is the multi-tenant control plane.
We already pay for Foundry—why Kimss?
You keep Foundry. Kimss adds identity, kill switch, governed-request meters, and SDK so every team can embed agents safely. Kimss does not host models.
Can we build the control plane ourselves?
Yes—budget platform engineering for orchestration, metering, audit, and ongoing API churn. Kimss ships that layer as a managed product.
Does Kimss host our models?
No. Inference stays on your Foundry project or vaulted OpenAI-compatible endpoint. Kimss stores agent definitions and meters governed requests.
Where should engineers start?
Create a workspace, vault a model, and follow /docs/route_traffic. Coding agents fetch the kimss-control-plane contract. New Python agents use Kimss Forge.