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

# Network & egress control

> A worker dials out and nothing dials in — and what an agent can reach on the way out is decided by its tool surface, not by its network.

Two questions come up in every network review: what has to be open for this to work, and what can an
agent reach once it is running. This page answers both — the connection model first, then the
controls that narrow what an agent's traffic can touch.

## The connection model

A worker you run lives in your environment and is **outbound-only**: it dials the control plane over
TLS, and nothing dials into it. There is no inbound listener to expose, no port to open toward your
cluster, and no ingress rule to write for the platform's benefit.

That has a practical consequence worth stating: an agent can work inside a private network that
accepts no inbound traffic at all, because the connection is always established from your side.

<Note>
  Inbound *events* — something in your estate telling an agent that a thing happened — arrive at an
  endpoint on the platform side that your system posts to, under **Integrations → Endpoints**. Your
  network still only makes outbound connections.
</Note>

## What an agent can reach on the way out

An agent's reach is decided by its tool surface as well as by its network, and the tool surface is
the part that surprises people: an agent's capabilities are governed centrally, so a firewall rule
alone does not narrow what it may do. The two work together — platform controls govern the supported
tool paths, and network policy constrains the destinations the worker can reach at all.

Two paths are governed — a built-in integration, or the
[MCP Gateway](/manage-your-agents/build/mcp-gateway) — and these are the controls over them:

| Control                 | What it narrows                                                                                                       |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Credential bindings** | Which agents can use which credentials at all.                                                                        |
| **Server groups**       | Which upstream servers an agent's gateway traffic may reach, with allow and deny patterns over the tools inside them. |
| **Per-request scope**   | A single request can be narrowed to named servers and named tools, without changing any stored configuration.         |
| **Guardrails**          | A rule at the tool-call gate can refuse or rewrite a specific call before it leaves.                                  |

<Warning>
  These controls apply to traffic that goes through the platform's gateways. An agent that reaches an
  external system by some other path — its own network calls, its own provider key — is outside them.
  Routing tool access through the integration catalog or the MCP Gateway is what makes the governance
  real rather than nominal.
</Warning>

## What crosses the wire

Outbound from the worker: the run ledger and the evidence an agent produces — its inputs, tool
calls, reasoning, outputs, and cost — with run-scoped secrets masked before they leave. See
[Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction)
for what that covers and what it does not.

Inbound to the worker: work to do, and the credentials for the run doing it. Nothing else, and
nothing unsolicited.

## Next steps

<CardGroup cols={2}>
  <Card title="MCP Gateway" href="/manage-your-agents/build/mcp-gateway">
    The governed path for your own tools.
  </Card>

  <Card title="Data handling & redaction" href="/security-and-governance/architecture-considerations/data-handling-redaction">
    What is in the traffic that does leave.
  </Card>

  <Card title="Agent isolation & tenancy" href="/security-and-governance/architecture-considerations/agent-isolation-tenancy">
    The boundary the connection lands inside.
  </Card>

  <Card title="Standards & Guardrails" href="/security-and-governance/controls/standards-guardrails">
    Refusing a call before it leaves.
  </Card>
</CardGroup>


## Related topics

- [Outposts](/manage-your-agents/build/outposts.md)
- [Deployment methods](/get-started/deployment-methods.md)
- [Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction.md)
- [Agent isolation & tenancy](/security-and-governance/architecture-considerations/agent-isolation-tenancy.md)
- [Architecture](/get-started/architecture.md)