> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Outposts
> A small relay you run inside your own network so agents can reach private services — outbound only, deny-by-default, with no inbound hole to open.
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. This page covers when you need one, how a call is routed, what it refuses to do, and how
it is enrolled.
## 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.
| Situation | Path |
| ---------------------------------------------------- | --------------------------------------------- |
| Agent hosted by Komodor, service private | agent → KAOP gateway → Outpost → your service |
| Agent running alongside the Outpost, service private | agent → local Outpost → your service |
| Service publicly reachable | agent → KAOP gateway → service, directly |
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.
## 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, and the cloud metadata address 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.**
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**, and that credential is the
Outpost's whole identity — it resolves to your workspace and that one Outpost. Store it before you
leave the screen, then run the install command with it.
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
The tool surface an Outpost carries calls to.
The wider network posture this fits into.
Where agents run, which decides which path applies.
Grouping the tool servers an agent may reach.