Start Building

Foundry runs models.
Kimss runs your AI product.

Foundry gives you model access. Kimss gives you a product-ready AI platform: one API key for chat and agents, Entra SSO, tenant isolation, spend controls, and audit-ready gateway telemetry — all Azure-native.

Contact sales Architecture Azure Marketplace

You keep Azure AI Foundry. Kimss adds governance, billing, and a single developer surface — the secured multi-tenant control plane your platform team would otherwise build on top.

Comparison

Azure AI Foundry alone vs Foundry + Kimss

Kimss does not replace Microsoft infrastructure. It is the product layer that turns Foundry into a governed, multi-tenant AI platform.

Capability Azure AI Foundry alone Foundry + Kimss
Model & agent execution Native Foundry projects and deployments Same Foundry backend — Kimss routes per workspace
Multi-tenant workspaces Build and operate yourself Built-in PostgreSQL row-level isolation + workspace model
Identity (Entra SSO, SCIM) Wire Entra and provisioning yourself Entra SSO, admin consent, optional SCIM 2.0 (Identity & SSO)
One key: chat + agents Separate integration paths per modality One gateway, two playgrounds — same Kimss API key
Spend control Ad-hoc or per-project budgets Redis credit pools, soft and hard caps, Kimss Credits
Usage & chargeback Custom metering and exports Normalized credits, execution logs, per-tenant reporting
Audit trail for procurement You design the logging sink Optional APIM gateway logs to Log Analytics (compliance architecture)
Time to embed agents in product Weeks to months of orchestration work pip install kimss + workspace API key via SDK
Procurement Foundry billing only Azure Marketplace Kimss Enterprise PAYG + invoice options

Model & agent execution

Foundry alone
Native Foundry projects and deployments
With Kimss
Same Foundry backend — Kimss routes per workspace

Multi-tenant workspaces

Foundry alone
Build and operate yourself
With Kimss
Built-in PostgreSQL row-level isolation + workspace model

Identity (Entra SSO, SCIM)

Foundry alone
Wire Entra and provisioning yourself
With Kimss
Entra SSO, admin consent, optional SCIM 2.0

One key: chat + agents

Foundry alone
Separate integration paths per modality
With Kimss
One gateway, two playgrounds — same Kimss API key

Spend control & chargeback

Foundry alone
Ad-hoc budgets; custom metering
With Kimss
Credit pools, caps, normalized credits, execution logs

Audit & procurement

Foundry alone
You design the logging sink
With Kimss
Optional APIM → Log Analytics; Marketplace PAYG
Differentiators

What CTOs get with Kimss

Six reasons platform and security teams choose Kimss on top of Foundry — not instead of it.

The integration gap

Using AI to write code is not the same as shipping governed agents in your product. Kimss is the orchestration layer you would otherwise staff with platform engineers.

Flip the order

Do not prototype on raw APIs then scramble for identity, metering, and audit. Start with the control plane; ship features on a governed foundation.

One gateway

Chat inference and full agentic flows — tools, retrieval, code interpreter — on one Kimss key. Foundry routing per workspace, not separate vendor stacks.

Shadow agents & prompt ownership

Workspace visibility and execution logs answer “who changed that prompt?” without a crisis email. Govern agents like production software.

Audit-ready by design

Gateway logs to Log Analytics, admin audit trail, and security questionnaire evidence. Formal attestations available under NDA during procurement.

Azure-native, not another cloud

Managed Identity, Entra, dedicated Foundry mapping per tenant — the same stack your CISO already approved. Procure via Azure Marketplace.

Architecture

How the stack fits together

Kimss sits between your applications and Foundry — auth, credits, and routing before models run.

Client / SDK / SPA
Kimss Gateway (auth, credits, routing)
Optional APIM (audit, token metrics)
Azure AI Foundry (models + agents)

See the full interactive system spec: Kimss Architecture →

FAQ

Questions CTOs ask

We already pay for Foundry — why Kimss?
Foundry is the execution plane for models and agents. Kimss is the multi-tenant product layer: identity, billing, logs, SDK, and workspace governance. You keep Foundry; Kimss removes the platform engineering work to make it safe for every team and customer.
Can we build this ourselves?
Yes — budget platform engineering for orchestration, metering, audit sinks, and ongoing Foundry API churn. Kimss ships that layer as a managed product. Many teams underestimate months of work before the first governed agent ships in production.
Is this another vendor or cloud?
No. Kimss runs on Azure, uses Foundry as the AI runtime, Entra for identity, and Azure Marketplace for procurement. It is an Azure-native control plane — not a separate hyperscaler or shadow OpenAI stack.
What about security review?
Start with Security & architecture and Security & compliance architecture. Formal third-party attestations and certification specifics are provided under NDA as part of procurement; your order form and DPA remain the legal source of truth.
Does Kimss store our prompts?
Kimss is designed with zero prompt retention for model traffic where that policy applies to your deployment tier. See Trust & safety for data handling and retention details.
How do we buy it?
Three paths: Azure Marketplace Kimss Enterprise PAYG, Teams self-serve after Stripe checkout, or sales-led Enterprise contracts. See Plans & subscriptions and Enterprise for onboarding.
Customer proof

Every worker uses kimss.KimssClient for chat, agents, and vector stores. No direct OpenAI or Azure AI SDK calls in application code — a runtime guard enforces that policy.

— worksfusion multi-agent fleet on Kimss · Read the story →

Ready for the CTO brief conversation?

Share this page with your platform team, or dive into the full documentation.

Contact sales Subscribe on Marketplace Full documentation