> ## Documentation Index > Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Network & Firewall Requirements > Outbound allowlist for AI clients, the Runlayer CLI, the AI Watch agent, and the browser extension — plus TLS inspection, VPN/SASE, and self-hosted inbound guidance. This page lists everything a corporate firewall, secure web gateway (SWG), or SASE must permit so that managed devices can reach Runlayer. It is the answer to the common enterprise-review question: *"Which endpoints do we need to allowlist, and does Runlayer collide with our existing proxy/VPN?"* Runlayer is **not** a transparent network proxy. AI clients, the CLI, the AI Watch agent, and the browser extension each connect **outbound over HTTPS (TCP 443)** to a small set of known hostnames. There are no inbound connections to end-user devices and no re-routing of unrelated traffic. See [Connecting AI Clients](/connecting-clients) for how clients point at a Runlayer proxy endpoint. ## Outbound allowlist Allow **HTTPS / TCP 443** from managed devices (and any egress proxy) to the following hostnames. | Hostname | Used by | Purpose | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Your Runlayer host** — your assigned tenant hostname (for example, `.runlayer.com`) or your self-hosted domain (for example, `runlayer.yourcompany.com`) | AI clients, Runlayer CLI, AI Watch agent, browser extension, [Hooks SDK](/runlayer-hooks-sdk) | The platform API **and** every MCP proxy endpoint. All authentication, policy checks, ToolGuard scanning, session telemetry, audit logging, and CLI and AI Watch self-updates flow here. | | **`downloads.runlayer.com`** | Browser extension | Chrome's extension update manifest and package. The CLI and AI Watch agent do not connect here directly for self-updates; they download through your Runlayer host. | Runlayer-hosted endpoints sit behind AWS load balancers with rotating IPs. AWS does not publish a stable IP range for an individual tenant, so **allowlist the tenant hostname, not static IPs**. If your firewall supports only IP rules, contact [support@runlayer.com](mailto:support@runlayer.com). For a **self-hosted** deployment, the platform hostname is your own domain, which resolves to infrastructure you control. ### Conditional OAuth browser egress Interactive connector authentication redirects the user's browser beyond the Runlayer tenant hostname. If you use brokered OAuth, allow browser access to **`oauth.runlayer.com`**. Also allow the authorization hostname used by the configured provider or identity provider, such as its sign-in or consent domain. These provider domains vary by connector and tenant, so derive them from the connector's authorization URL rather than using a global Runlayer list. ### What clients do *not* need to reach directly * **Upstream SaaS / MCP servers and LLM providers during normal tool use.** For hosted connectors, Runlayer reaches upstream APIs from the **platform / gateway** side. The browser still needs the conditional OAuth access described above during authentication. [Local MCPs](/local-mcps) are another exception: they run through the CLI on the user's machine and connect to whatever that local server needs. * **Provider compliance APIs.** [Web-chat compliance imports](/platform-sessions#web-chat-and-compliance-imports) are polled by the Runlayer platform, not by the device. ## TLS inspection (SWG / SASE) If your SWG/SASE terminates and re-signs TLS, the CLI and AI Watch agent must trust the corporate root CA used by the inspection appliance: * This is honored automatically through the OS trust store (macOS Keychain, Windows certificate stores, Linux CA bundle) when the root is installed system-wide. * If it is not system-wide, use the `--ca-bundle` flag or the `RUNLAYER_CA_BUNDLE` / `SSL_CERT_FILE` / `REQUESTS_CA_BUNDLE` environment overrides. See [AI Watch Troubleshooting](/shadow-ai/troubleshooting) and the TLS-inspected-network note in [MCP Troubleshooting](/mcp-troubleshooting). * For **self-hosted** backends whose *own* outbound HTTPS passes through an enterprise proxy with a private CA, mount the CA per the [Helm — custom trusted CA bundle](/deployment/helm#custom-trusted-ca-bundle) guide. ## Coexistence with VPN / SASE Runlayer runs **alongside** Zscaler, Netskope, Cloudflare WARP, Palo Alto Prisma, and similar tools without competing for the network path — it operates at the application layer, installs no OS-level proxy or VPN, and does not change system proxy settings or split-tunnel rules. See the detailed answer in the [AI Watch FAQ](/shadow-ai/faq). ## Self-hosted: inbound allowlisting The allowlist above is **outbound** from devices. To restrict which **source** IPs may reach a self-hosted deployment (WAF IP allowlisting on ECS, or security-group restrictions on the load balancer / EKS), and for VPC peering / Transit Gateway to reach internal MCP servers, see [Networking → IP Allowlisting](/infrastructure/networking#ip-allowlisting) and the [Terraform deployment guide](/deployment/terraform). ## Troubleshooting egress If a user's activity never reaches Runlayer — for example **no audit-log entries for that user/time** — a firewall or SWG blocking egress to your Runlayer host is a common cause. Confirm the applicable hostnames above are allowlisted, then re-check. See the diagnostic decision tree in [MCP Troubleshooting](/mcp-troubleshooting#for-administrators). ## Related pages * [Connecting AI Clients](/connecting-clients) * [Networking](/infrastructure/networking) * [AI Watch FAQ](/shadow-ai/faq) * [MCP Troubleshooting](/mcp-troubleshooting)