Add networking rules
Your deployment runs in your own cloud, so outbound (egress) access to everything your agents, MCP servers, and integrations reach is controlled by your network. As you add new capabilities over time, you'll need to open egress to new destinations.
When you need to add rules
Add outbound HTTPS (443) rules whenever you introduce something new:
| You added… | Allow egress to… | More |
|---|---|---|
| A new LLM provider | The provider's API endpoints (OpenAI, Bedrock, Azure OpenAI, Google) | Configure LLMs |
| A new MCP server | The endpoints that MCP (gallery, vendor, or custom) calls upstream | MCP servers, MCP orchestration |
| A new OAuth provider for MCPs | The provider's OAuth and API endpoints (Google, Microsoft Graph) | Set up OAuth for MCPs |
| A new observability vendor | The vendor's OTLP ingest endpoint | Set up Observability |
| A new data connection (database) | The database host, on that database's port (not necessarily 443) | Databases use their own ports |
Databases use their own ports
Most egress is plain HTTPS on port 443, but data connections are the exception. When a new use case adds a connection to a database, allow egress to that database's host on its own port — which is usually not 443. Common defaults:
| Database | Default port |
|---|---|
| PostgreSQL | 5432 |
| MySQL | 3306 |
| Amazon Redshift | 5439 |
| Snowflake | 443 |
| Google BigQuery | 443 |
| Databricks | 443 |
Check the actual port your database listens on — it may be customized. Cloud warehouses like Snowflake, BigQuery, and Databricks use HTTPS (443), while self-managed engines like PostgreSQL, MySQL, and Redshift use their native database ports.
Where egress is configured
- On AWS: security group outbound rules and network ACLs, with a NAT gateway (or VPC routes) for public destinations — or VPC interface endpoints / PrivateLink for same-cloud services to avoid public egress entirely.
- On Azure: network security group (NSG) outbound rules and any Azure Firewall / user-defined routes — or Private Endpoints for same-cloud services.
Inbound reachability
Some integrations also need to be reachable rather than just reachable-from:
- OAuth callbacks — after a user consents, the provider redirects their browser to your deployment's callback URL, so that endpoint must be reachable from where users sign in.
- Custom MCP servers on private ingress — the platform must have network line of sight to the MCP's URL. See Set up MCP orchestration.
A quick way to catch a missing egress rule: most integrations have a Test button. If a test fails with otherwise-valid credentials, suspect blocked egress or DNS resolution first.