Skip to main content
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 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.
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. 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 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 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 and the TLS-inspected-network note in 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 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.

​
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 and the Terraform deployment guide.

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