KOSMOY · ENTERPRISE AI CONTROL PLANE
One inventory, one policy layer and one evidence trail for every model, agent, MCP server and tool. Observe quality and cost, enforce runtime controls, and contain agent actions in your own Kubernetes.
Or email sales@kosmoy.com.
An enterprise AI control plane is the shared management layer that records what AI exists, defines who and what may use it, applies policy and budgets to live model and agent traffic, and retains the traces, evaluations, cost and incident evidence needed to improve those controls. The term describes an architecture, not a formal standard — the market often sells the same layer as an AI management platform. In Kosmoy it spans inventory, observability, gateway enforcement and agent containment.
This continuous loop follows the logic of the NIST AI Risk Management Framework: Govern, Map, Measure and Manage. The framework does not prescribe a software control plane.
The management layer sets intent. The execution path enforces it. Observability, evaluations, red teaming and AI FinOps return evidence for the next policy decision.
Control plane
Execution plane
Evidence loop
Traces, evaluations, red-team findings and cost signals update the policy, budget, model or release gate. The control plane is a loop, not a dashboard.
A gateway alone brokers traffic. A control plane must connect runtime enforcement to ownership, evidence, economics and response across models, agents and tools.
| Capability | Buyer question | Evidence to request |
|---|---|---|
| Inventory and ownership | What AI exists, where does it run, and who is accountable? | Live system, model, agent and tool records with owner, use case and risk tier. |
| Identity and scoped access | Which person, service or agent may call which model or tool? | Identity-bound policy decisions, role mappings and short-lived credentials. |
| Runtime enforcement | Can policy stop, route or cap a request before an action occurs? | Gateway logs showing authentication, guardrail, routing and budget decisions. |
| Observability and evaluation | What happened, why did it happen, and did the system meet its quality bar? | Replayable traces joined to datasets, evaluator versions, scores and human review. |
| AI FinOps and outcomes | Who spent what, on which workflow, and what useful result did it produce? | Cost per model, agent, team, workflow and accepted outcome with budget variance. |
| Containment and response | Can operators limit or stop an agent that takes an unsafe action? | Tool scopes, egress controls, incident history, revocation and a tested kill path. |
Some AI you can only register. Some you observe. Some you govern. Some you contain. One platform — one identity, one policy, one audit trail.
AI INVENTORY
You can’t govern what you can’t see. Every AI system, model, agent and MCP server gets a state, an owner and an audit trail — including agents on Foundry, Bedrock and other external platforms. Each entry is classified under the EU AI Act and feeds the dossier as it evolves.
Modules
AI MONITORING & OBSERVABILITY
The operational half — observability and AI FinOps. Kosmoy records LLM, MCP and agent calls with the model, latency, cost, feedback and guardrail decision needed to investigate behavior and allocate spend. Cost, usage, user feedback and guardrail alerts roll up by app, team, model and time; gateway budgets and routing policies can act on those signals in the request path.
The evaluation half — proving what your AI does. Twenty evaluators score quality, groundedness, tool use and safety offline and online, and red teaming establishes what the system can be made to do. This is the slice Gartner names AI evaluation and observability; Kosmoy's layer is broader, pairing it with the FinOps and operational monitoring above.
Modules
AI GOVERNANCE
One policy point between your apps and every AI they call — LLMs, MCP servers, A2A agents. Guardrails, RBAC, routing and logging configured once and applied on every call. Approved models exposed through a private OpenAI-compatible API, so existing code keeps working.
AI ACTION CONTROL
When an agent stops just answering and starts calling tools, writing to systems of record or moving money, the runtime needs containment. Each Action Capsule is a Kubernetes-native container plus in-container sandbox; Mission Control supervises the fleet — pre-flight authorisation, JIT credentials, kill switch.
Horizontal tools that span the four layers — used to build, ship and supervise governed AI inside the Kosmoy platform.
Kosmoy Chat
Kosmoy Chat is the human surface for every governed AI interaction. Use it to build chatbots and assistants on top of the Gateway, and to keep humans in the loop when agents run inside Capsules — clarifications, approvals, stop and rerun.
RAG-in-a-Box
Pre-built ingestion pipelines and retrievers so the AI team builds high-performance RAG systems quickly. Connect sources, chunk, embed, retrieve, govern — without rebuilding the same plumbing for every project.
Kosmoy deploys as standard Helm charts into your own Kubernetes cluster. No host changes, no node patches, no custom container runtime. Cloud-portable: Azure, AWS, GCP, or on-prem. Air-gapped deployments supported. Single-tenant by default — your data, your cluster, your network.
Models
External AI
Enterprise systems
Communication
Pre-built connectors. New ones added each release. Custom integrations via the Kosmoy API.
The EU AI Act asks for evidence: Article 9 risk management, Article 11 documentation, Article 12 record keeping, Article 14 human oversight, Article 17 quality management, Article 50 transparency.
Most companies build it by hand — logs from one tool, screenshots from another, exported tickets, attached emails. By the time the auditor asks, the team has spent a quarter rebuilding the trail.
Kosmoy builds the dossier as a side effect of running. Every guardrail decision, approval and override is an event — timestamp, actor, system, outcome. When the auditor asks, the dossier is already there.
| Article | What it requires |
|---|---|
| Article 9 | Risk management |
| Article 11 | Technical documentation |
| Article 12 | Record keeping |
| Article 14 | Human oversight |
| Article 17 | Quality management |
| Article 50 | Transparency |
The capability map
Running AI at scale takes ten capabilities, from inventory to containment. AI gateways, observability platforms, governance suites and security tools each cover two or three — and every seam between them is where risk hides. The four layers exist to cover the whole map on one identity model, one policy layer and one audit trail.
An enterprise AI control plane is the shared management layer for all the AI an organization runs. It records systems, models, agents and tools; defines identity, policy, budgets and approvals; applies those controls to live traffic; and retains observability, evaluation, cost and incident evidence. The term describes an architecture rather than a formal standard. Kosmoy implements it across inventory, monitoring, gateway policy and agent containment in the enterprise's own Kubernetes.
In practice, largely yes. AI control plane describes the architecture — the shared layer of record, policy, enforcement and evidence around enterprise AI — while AI management platform is the product category name the market most often uses for software that implements it. Kosmoy is both: an AI management platform that functions as the enterprise's AI control plane, deployed in its own Kubernetes.
A control layer is the narrower runtime slice: the gateway, guardrails, access policy, budgets and containment applied while a model or agent request runs. A control plane connects that runtime layer to the wider operating system: inventory, owners, risk classification, evaluation datasets, approvals, observability, AI FinOps and audit evidence. A team can use a standalone control-layer tool inside a broader control plane.
The control plane stores and changes intent: inventories, identities, policies, budgets, evaluator configurations, approvals and response rules. The data or execution plane is where work happens: prompts, retrieval, model calls, MCP tool calls, agent actions, outputs and telemetry. A strong design keeps policy decisions outside the model, applies them deterministically on the execution path and sends evidence back to the control plane.
No. An AI gateway is an important enforcement point inside the control plane. It can authenticate, inspect, route, rate-limit and log model or agent traffic. A full enterprise AI control plane also needs system and agent inventory, ownership, risk records, evaluation and red-team evidence, AI FinOps, approvals, incident response and containment. If a product only brokers model calls, it is a gateway rather than the whole control plane.
Not necessarily. Specialist tools may remain deeper on tracing, experiment workflow, offensive testing or cloud-cost optimization. The control plane should connect their evidence to shared system identities, owners, policies and release or runtime decisions. Kosmoy can provide connected capabilities itself and emit structured events to existing enterprise observability and security stacks.
AI governance — policy, guardrails, access control, audit — is one layer of AI management. An AI management platform also covers the inventory underneath it, the observability around it, and the runtime control beyond it. In Kosmoy, the governance layer is the AI Gateway; the other three layers make what it governs visible, measurable and containable.
They share one identity model, one policy model and one audit trail. RBAC defined in Inventory applies at the Gateway and inside Action Capsules. A guardrail configured at the Gateway runs at the Capsule boundary too. Every event from any layer lands in the Insights Dashboard and the AI Act dossier. The layers are different control surfaces, not different products.
Yes. The Agent Registry includes external agents — agents that live on someone else's platform. Kosmoy registers them, classifies their risk under the EU AI Act, and where the platform exposes the right APIs, monitors their activity. You can't always govern an external agent at runtime, but you can always inventory it and capture audit evidence.
The Gateway is policy enforcement at the API boundary. The Capsule is containment at the runtime boundary. The Gateway assumes apps cooperate by routing through it. The Capsule assumes the runtime can't reach anything except through Kosmoy. They share the same control surface — the Action Plane — and the same policy library. You add the Capsule when an agent acts on systems of record, not just generates text.
Standard OIDC and SAML. Tested with Okta, Microsoft Entra ID and Auth0. Group-to-role mapping flows from the IdP into Kosmoy RBAC. Service accounts are issued just-in-time credentials for inter-service calls.
A Helm chart with a small set of services: registries, gateway, action plane, monitoring backend, web console. Stateless services scale horizontally. State is held in a small set of databases — Postgres-compatible — that you provide or the chart can install. Resource footprint scales with traffic; a typical mid-sized enterprise install is in the tens of cores.
Yes. The platform was designed for regulated environments where outbound traffic to vendor cloud is not permitted. All control-plane and data-plane traffic stays inside your network. Updates are applied by your team from a private registry.
Kosmoy Chat is the end-user interface — the chat window your employees actually use. Behind the chat, every conversation is routed to one or more agents built in the Kosmoy Agent Builder, or to external agents registered in the platform. Kosmoy Chat is one front-end. The platform supports any front-end you build.
TLS in transit, end-to-end. Encryption at rest using your KMS provider — AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. Customer data never leaves the cluster.
Kosmoy emits structured events that ship to your existing log and metrics pipeline. The Insights Dashboard is the AI-native view; your APM stack still gets every event for cross-correlation with the rest of your infrastructure.
Versioned Helm chart. Upgrades are controlled by your team — Kosmoy does not push updates into your cluster. Minor versions ship every two to four weeks; major versions every quarter or so. Backwards compatibility is maintained on the Kosmoy API across minor versions.
Or email sales@kosmoy.com.