Outbound Egress Security

Host allowlist

The backend accepts built-in vendor and local service hosts. Additional exact hostnames must be supplied by the operator through:

The value is a comma-separated list of hostnames. Wildcards and arbitrary suffix matching are not supported. A URL with credentials, a fragment, a non-HTTP(S) scheme, or a hostname outside the allowlist is rejected before the network client is opened and returns a retryable 503.

Development may use the built-in localhost, litellm, and ollama service names. In production those names are also resolved and must be covered by the configured internal-network allowlist; loopback addresses remain blocked.

Protected application paths

The policy is applied before requests to:

• LiteLLM and OpenAI-compatible chat endpoints

• OpenAI and Ollama embedding endpoints

• Reranking providers

• Provider and model verification requests from the administration API

• Ingestion strategy providers

• Langfuse tracing

The existing connector SSRF layer remains responsible for tenant-controlled connector URLs. It validates every DNS result, pins the validated address, and revalidates manual redirects. See Connectors.

Network and deployment requirements

The application policy is an application-layer control, not a replacement for network egress controls. In production:

1. Keep M8TY_RAGTY_EGRESS_ALLOWED_HOSTS under operator control; never expose it as tenant configuration.

2. Add every approved private provider hostname explicitly and configure its private CIDR through the existing crawler/internal-network policy where applicable.

3. Restrict outbound traffic with Kubernetes NetworkPolicy, a firewall, or a service-mesh egress gateway.

4. Treat a 503 with error egress_denied as a configuration or policy failure, not as permission to bypass the check.

Related configuration

See Configuration and Deployment for the complete environment-variable reference and LLM and Model Providers for provider setup.