Skip to main content
Some of the systems your agents need are not reachable from the internet, and opening a way in is not on the table. An Outpost solves that: a small proxy you run inside your own network that dials out to the Komodor Agentic Operation Platform (KAOP) and carries calls back down that connection.

​
It never accepts an inbound connection

The Outpost opens a connection outward and holds it open. Calls travel down that existing connection, so from your firewall’s point of view there is nothing to allow — it is the same outbound access your CI already has. No inbound rule, no exposed port, no address of yours to publish.

​
Which path a call takes

Three paths, and the one that applies depends on where the agent runs, not on a negotiation at call time. The middle row is the one worth getting right: when the agent and the service are on the same network, the call should not leave that network. You choose per agent, on the deploy wizard’s MCP step — the platform does not infer it, because the only location signal an agent gives is a name the process declares about itself, and guessing a routing decision from that would be worse than asking.
The local listener that makes the middle row possible is off by default. You enable it in the Outpost’s own deployment values, which also sets the in-cluster network policy that governs which agents may reach it. Until it is enabled, a colocated agent’s calls take the first row — out to the KAOP gateway and back down the tunnel — instead of staying on your network.

​
It is built to refuse

The Outpost holds network access its callers do not have, so it starts from deny.
  • Deny-by-default allowlist, on scheme, host, port, and an optional path prefix. An empty allowlist allows nothing.
  • Host matching is exact, or one leading wildcard label, compared label by label — never a substring or suffix. A suffix match on internal.example.com would also be satisfied by internal.example.com.attacker.test.
  • A path prefix matches on segment boundaries, so /mcp does not admit /mcp-admin.
  • Addresses are checked after DNS resolves, because the resolver is yours and a name can resolve anywhere. Loopback, link-local, multicast, and cloud metadata endpoints — IPv4 and IPv6 — are refused outright.
  • A redirect off the allowlist is not followed. The relay re-checks its own rules on every hop.
  • Caller credentials are never passed upstream.

​
Every call is bounded

Beyond the allowlist, each call the Outpost forwards runs inside fixed limits.
  • Only ordinary HTTP methods are forwarded — GET, HEAD, POST, PUT, PATCH, DELETE, and OPTIONS. CONNECT and any other verb are refused, so the tunnel cannot be turned into a raw TCP proxy.
  • Request and response bodies are size-capped, and the number of headers is capped. A body over the limit is rejected rather than streamed.
  • Every call has a timeout, and the number of concurrent calls per Outpost is capped. Calls beyond the cap are shed rather than queued indefinitely.
  • Connection-scoped headers are stripped, and the relay never routes through a forward proxy — it opens every socket itself, so the address checks above always apply.
A call an agent makes to a service it can already reach on its own does not pass through any of this. The Outpost governs the traffic routed through it — which is the argument for routing everything through it or the built-in integrations rather than letting an agent reach out on a path of its own.

​
Enrolling one

Creating an Outpost issues a long-lived credential, shown once at creation, and that credential is the Outpost’s whole identity — it resolves to your account and that one Outpost. Store it before you leave the screen, then run the install command with it. Rotating the credential later issues a replacement, shown the same one time. The credential is never written to a log, a trace, or an audit record’s detail.
Rotating the credential drops the live connection. The Outpost stays down until you redeploy it with the new value, so rotation is a planned action rather than a safe click — which is why it is a separate permission from editing an Outpost.
Labels on an Outpost scope who can see and manage it, the same way labels scope other resources.

​
Next steps

MCP Gateway

The tool surface an Outpost carries calls to.

Network & egress control

The wider network posture this fits into.

Deployment methods

Where agents run, which decides which path applies.

Integration groups

Grouping the tool servers an agent may reach.