docs: clarify BYO inference networking for self-hosted factories

src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx

@@ -74,7 +74,7 @@ Configure team providers from the [Admin Panel](/enterprise/team-management/admi
 The team's enabled models appear in members' model pickers when their team settings refresh.
 
 :::note
-A team endpoint's base URL must be reachable from Warp's hosted services. Use a public HTTPS URL by default, or [connect a private LLM gateway through private networking](/enterprise/enterprise-features/private-networking/).
+A team endpoint's base URL must be reachable from Warp's hosted services, even with self-hosted workers. See [Networking for BYO inference endpoints](https://docs.warp.dev/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for IP allowlisting, or [connect a private LLM gateway through private networking](/enterprise/enterprise-features/private-networking/).
 :::
 
 ### Keep inference on your team's providers

src/content/docs/factories/infrastructure-and-security.mdx

@@ -85,6 +85,23 @@ Factory agents execute as cloud agents. For runs using the Warp Agent, support v
 
 Personal BYOK and personal custom inference endpoints are stored on a member's device and don't apply to factory runs. With team-managed keys and endpoints, select a specific provider model or endpoint. Auto continues to use Warp-managed inference. Your provider's retention follows your account and contract. Warp can't enforce ZDR for that provider.
 
+### Networking for BYO inference endpoints
+
+For factory runs using the Warp Agent and a team-managed inference endpoint, model requests originate from Warp's hosted backend, not your self-hosted worker or VPC. Your workers execute checkout, tools, builds, and commands.
+
+Your inference gateway must accept connections from Warp's backend, even if your workers can already reach it. For example, a TrueFoundry gateway on AWS needs a separate ingress path for Warp's inference requests.
+
+For a public HTTPS gateway, allowlist both fixed outbound IP addresses in your gateway's ingress rules:
+
+{/* VERIFY: Confirm that all current production team-managed inference requests use only these two fixed outbound IPs. */}
+
+* `34.181.225.186`
+* `35.245.132.55`
+
+These addresses identify Warp's hosted backend, not worker execution traffic. The worker's outbound connection to Warp doesn't require inbound ports on the worker.
+
+If your gateway can't be exposed publicly, contact your Warp account team to confirm whether [private networking](https://docs.warp.dev/enterprise/enterprise-features/private-networking/) is available for your deployment. A private endpoint must be registered with Warp and reachable from Warp's hosted backend; self-hosting a worker doesn't establish this connection.
+
 ## Credential boundaries
 
 A factory handles four kinds of credentials, each with its own boundary:

src/content/docs/factories/self-hosting/index.mdx

@@ -149,6 +149,8 @@ Use unmanaged execution for an existing CI pipeline, Kubernetes Job, VM, or deve
 
 Repository clones and execution workspaces stay on your infrastructure. Agent context and model requests still travel through Warp's services. See the [self-hosted execution flow](/platform/architecture/#self-hosted-execution-flow) for the architecture and [Security and networking](/platform/execution-security/) for data boundaries, ZDR, and BYOLLM.
 
+For a factory using a team-managed inference gateway, see [Networking for BYO inference endpoints](/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for gateway ingress requirements, source IPs, and private connectivity options.
+
 View managed and unmanaged runs in the <a href={VARS.WEB_APP_URL}>{VARS.DASHBOARD}</a>. Managed workers can also export OpenTelemetry metrics; see [Monitoring](/factories/self-hosting/monitoring/).
 
 ## Related pages

src/content/docs/platform/execution-security.mdx

@@ -32,7 +32,7 @@ Repositories are cloned and stored only on your infrastructure, but code content
 
 ## Network requirements
 
-Self-hosted agents **do not require any network ingress**. They require outbound (egress) access to the following services:
+Self-hosted workers **do not require network ingress for their connection to Warp**. They require outbound (egress) access to the following services:
 
 ![Self-hosted worker network egress diagram showing outbound-only connections from customer infrastructure to Warp backend endpoints, Docker Hub, Google Cloud Storage, and GitHub](../../../assets/agent-platform/self-hosted-network-egress.png)
 
@@ -58,9 +58,9 @@ Tasks use the following Docker images:
 
 **Linux distribution-specific package repositories** — only with the managed architecture, when using a Warp environment whose base image does not have Git pre-installed. The exact repositories depend on the package manager configuration in the environment's base image.
 
-All traffic uses HTTPS (port 443). No inbound ports need to be opened.
+All traffic uses HTTPS (port 443). No inbound ports need to be opened on the worker for its connection to Warp.
 
-[Team-managed inference endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) and URL-backed MCP servers that you host must be reachable from Warp's servers.
+[Team-managed inference endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) and URL-backed MCP servers that you host must be reachable from Warp's servers. The worker's outbound-only connection doesn't provide ingress to your inference gateway; see [Networking for BYO inference endpoints](https://docs.warp.dev/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for gateway allowlisting and private connectivity options.
 
 ---