Secured Enterprise Agent Platform
Kimss is the control plane for governed AI agents: portable definitions, tenant isolation, audit-ready telemetry, and model routing on Azure AI Foundry - or your own OpenAI-compatible endpoint. Build your AI product on Kimss; the runtime is yours to choose.
Powered by secure Azure infrastructure — Managed Identity, no static credentials.
A two-and-a-half-minute walkthrough: Studio for agents, then the Admin Console that governs fleet, models, spend, audit, alerts, roles, and traffic — with one key for developers.
Manual routing, leaked API keys, no tenant quotas, missing RBAC, raw logs everywhere. Kimss collapses the tangle into one secure control plane — secure, multi-tenant, day one.
Kimss is a single control plane for model and agent traffic: operators govern workspaces, billing, and audit sinks while developers keep one API key from prototype through production. The same Python SDK and browser SPA you use for integration are backed by FastAPI, PostgreSQL row-level tenant isolation, optional Azure API Management for gateway telemetry, and Azure AI Foundry for model and agent execution. This section summarizes the three primary surface areas-SDK access, unified gateway routing, and enterprise controls-that most architecture reviews ask about first. CTO brief →
The Kimss Python SDK exposes chat and agent calls against Kimss-hosted endpoints so your application does not embed long-lived provider keys for Azure AI Foundry. Kimss performs tenant-aware routing, attaches metering metadata, and enforces subscription and credit state before traffic reaches model workers. Install once, configure a workspace API key, and call models and tools through the same client in CI, local development, and production; gateway policy and optional APIM diagnostics apply uniformly across environments.
Kimss multiplexes fast text-inference workloads and full agentic flows (tools, code interpreter, retrieval) through one authenticated edge. Clients select modality with parameters rather than provisioning separate vendor stacks. Routing targets Azure AI Foundry projects mapped per workspace; the gateway enforces model allow lists, spend limits, and trace identifiers used in usage exports. Switching between chat and agents is a configuration change on the same key, which reduces secret sprawl and keeps compliance boundaries identical for both patterns.
Workspaces carry billing profiles, Redis-backed credit pools, execution logs for SDK integrations, and optional export of gateway events to Log Analytics for immutable audit trails. Managed Identity is used for service-to-service access to Foundry and supporting Azure resources, reducing static secrets in application configuration. Operators can segment usage by tenant, enforce soft and hard spend caps, and correlate gateway logs with application-level request identifiers without building a separate metering plane.
Kimss maps product security claims to concrete Azure and data-layer mechanisms: Entra-issued tokens for the SPA and APIs, PostgreSQL schemas with tenant-scoped row access, Redis for credit enforcement, and optional Azure API Management for gateway logs and token metrics. The items below are the three primitives most security questionnaires isolate first-identity to Azure services, isolation at persistence, and prompt lifecycle-so each entry leads with a factual summary before shorthand configuration examples. Read Security & architecture →
Application and worker roles use Azure Managed Identity to obtain tokens for Azure AI Foundry, Key Vault references, and related control-plane APIs where configured. This removes static API keys from Kimss service configuration for the data plane path and aligns with zero-trust guidance for cloud-hosted AI gateways. Human access to the product uses Microsoft Entra ID; personal sign-in flows may use Entra External ID (CIAM) when enabled for a deployment.
Workspace identifiers and Entra tenant or subject keys partition rows in PostgreSQL so one customer cannot read another's agents, sessions, or billing artifacts through the API. ORM and SQL access paths are expected to carry tenant context from authenticated principals; pooled individual subscribers can be further partitioned by object id for wallets and telemetry when configured. Isolation is enforced server-side; browser storage holds only session UI state.
Kimss routes prompts and tool traffic to customer-scoped Foundry projects; it does not maintain a separate long-lived store of end-user prompt bodies for model inference beyond what Azure AI and your workspace configuration retain. Operational logs focus on metadata-tokens, latency, identifiers-suitable for billing and audit, not on retraining Kimss-owned foundation models from customer content. Exact retention for provider-side logs follows Microsoft Azure AI data handling for the regions you select.
Modern teams want AI that ships work — reviews code, fixes incidents, drafts content, triages support — with governance: one model gateway, auditable actions, and human approval where it matters.
worksfusion runs a production Digital Employee fleet headless on Azure: specialized agents orchestrated by LangGraph with Postgres checkpoints, cognition through KimssClient, and tools through a self-hosted MCP server — not IDE-bound assistants or scattered provider SDK keys.
Slack ingress, Kimss cognition, MCP tools, Airflow orchestration.
Command Hub routes natural language to the right LangGraph Digital Employee.
Reasoning via KimssClient; Git, GitHub, and telemetry via Entra-authenticated MCP.
PostgreSQL holds durable run state and handoffs; sensitive actions wait for Slack sign-off.
Agents, governed integrations, Developer Hub with live telemetry, plans and billing, and usage — in a single control plane.
Requests originate in browsers or SDK clients, authenticate to Kimss, and traverse an optional Azure API Management layer for policy and telemetry before reaching the FastAPI core. The core resolves workspace and tenant context in PostgreSQL, enforces Redis-backed credit pools, and forwards eligible traffic to the Azure AI Foundry project mapped to that workspace. Responses return through the same path so gateway logs, token metrics, and application audit hooks share identifiers. Use the interactive nodes below for component-level detail; this paragraph states the default production topology assumed by security documentation.
Azure Monitor and Log Analytics provide immutable, regulation-ready audit trails at the API gateway. Credit pools enforce spend limits per tenant in real time via Redis.
Kimss is architected on Azure-native compliance primitives you can cite in procurement questionnaires. This is our technical design posture — not legal advice; your counsel validates fit for your sector.
API Management diagnostic settings feed Log Analytics for gateway-level records. Token metrics use azure-openai-emit-token-metric with per-tenant dimensions for cost and governance dashboards.
Tenant slug maps to the correct Azure AI Foundry region via APIM backends and Named Values — no client-supplied region header. Project paths stay under /api/projects/{tenant}/… for a consistent data model.
Gateway backends authenticate to Foundry with Managed Identity — no long-lived API keys in APIM policies for model traffic. Optional SDK-side PII scrubbing before traffic reaches the gateway.
Equip your agents with custom, secure functions. Kimss strictly enforces access control, ensuring agents only call registered backend tools.
One Kimss key from your IDE to production — tenant isolation, audit-ready telemetry, and Managed Identity included from the first call.
Powered by secure Azure infrastructure.