Last updated: October 3, 2026
What changed
Kimss used to help customers stand up Azure AI Foundry capacity. That path is gone. New customers vault their own OpenAI-compatible, Azure OpenAI, or native Anthropic endpoints. Kimss is the control plane in front of them.
- Retired
- Per-customer Foundry provisioning, hosted Foundry pool, Kimss Credits as the sellable meter.
- Current product
- Invisible Proxy (
https://api.kimss.ai), write-only Provider Vault, Guardrails including Authority Boundary, Agent Discovery + kill switch, governed-request metering, gateway-verified audit. - Your data plane
- Any vaulted LLM provider — not a Kimss-hosted model runtime.
Why a control plane instead of another model host
Enterprises already pay OpenAI, Azure, Anthropic, or a compatible gateway. The gap is identity, policy, and an authoritative kill switch on every agent request — across providers, not inside one cloud’s studio.
Point your existing SDK at Kimss: OpenAI base_url=https://api.kimss.ai/v1, Anthropic base_url=https://api.kimss.ai, send X-Kimss-Agent-Id. Guardrails run before tools execute. Disable an agent once; attributed traffic returns 403. That is the kill-switch drill — no laptop agent, no always-on red-team product.
Frequently asked questions
Does Kimss provision Azure AI Foundry?
No. That offering is retired. Kimss does not create or host a Foundry project for you.
What is Kimss AI now?
A secured, model-agnostic control-plane proxy with Guardrails and audit for production agents — in front of the LLM providers you already use.
Does Kimss host models?
No. Inference stays on your vaulted endpoints.