Skip to main content
The Komodor Agentic Operation Platform (KAOP) has two moving parts — the control plane and your agents — and they do not have to run in the same place. This page explains the choices, and what each one means for network access and data. Read it before planning a rollout, because it decides what your network and security teams have to approve.

​
The split

The control plane holds the registry, run lifecycle, evidence, identity, and storage. Agents are processes that do the work. Both are separate decisions: you can run agents yourself against a Komodor-hosted control plane, which is the common case, or run the whole platform yourself. Most of this page is about where agents run, because that is the choice almost everyone makes. Running the control plane yourself is covered in Self-hosting.
Running the control plane yourself is arranged with Komodor rather than started from the console. Every tier is delivered per agreement, so talk to your account team before you plan a rollout around it. Running your own agents against a Komodor-hosted control plane — the rest of this page — needs no such arrangement.

​
Komodor-hosted agents

The simplest path. You deploy an agent from the console and Komodor runs the worker for you. Nothing to install, no infrastructure to provide, and the agent is online as soon as it registers. Choose this when an agent’s work is reachable over APIs it can call with credentials you have connected — most investigation, review, and cost work.

​
Self-hosted agents

You run the worker in your own environment — a Kubernetes cluster, a VM, or a container platform — and it connects out to the control plane. Choose this when the agent needs something only reachable from inside your network: a private cluster’s API, an internal service, a database, or a tool with no public endpoint.
1

Build or take an agent

Author a worker with the SDK, or use one of ours that supports self-hosting. See Build from scratch.
2

Give it a credential and the workspace host

The worker authenticates to the control plane and identifies which agent it is running.
3

Run it where the work is

It registers on start and appears in your fleet. See Deploy an agent.

​
What the network needs

This is the part most reviews turn on:
  • An agent needs outbound access to the control plane — wherever that control plane runs. That is all.
  • Nothing needs to reach into your environment. Work is delivered over the connection the agent itself opened.
  • No inbound firewall rule, no public endpoint, and no VPN is required to run agents in a private network.
Because work arrives on an outbound connection, a self-hosted agent behind NAT or with egress-only networking runs exactly like a hosted one.

​
What this means for your data

A self-hosted agent keeps the reach inside your environment: it calls your internal systems directly, and its credentials for them never leave your network. What does travel to the control plane is the agent’s evidence — the run’s inputs, tool calls, reasoning, output, and usage — because that is the record the platform exists to keep. Secrets are delivered to a run in memory and are never written into that evidence. See Data handling & redaction.

​
Mixing both

Most teams do. The split is per agent, so a Komodor-hosted investigator can work alongside a self-hosted agent that reaches a private cluster, with one fleet, one set of permissions, and one evidence trail across both.

​
Next steps

Architecture

How the control plane and agents communicate.

Deploy an agent

Getting a worker running.

Network & egress control

Scoping what agent traffic may reach.

Agent isolation & tenancy

How workspaces stay separate.