> ## 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.

## 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.**

<Warning>
  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.
</Warning>

## 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 account 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.

<Note>
  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.
</Note>

Labels on an Outpost scope who can see and manage it, the same way labels scope other resources.

## Next steps

<CardGroup cols={2}>
  <Card title="MCP Gateway" href="/security-and-governance/architecture-considerations/mcp-gateway">
    The tool surface an Outpost carries calls to.
  </Card>

  <Card title="Network & egress control" href="/security-and-governance/architecture-considerations/network-egress-control">
    The wider network posture this fits into.
  </Card>

  <Card title="Deployment methods" href="/get-started/deployment-methods">
    Where agents run, which decides which path applies.
  </Card>

  <Card title="Integration groups" href="/manage-your-agents/build/integration-groups">
    Grouping the tool servers an agent may reach.
  </Card>
</CardGroup>