Firewall and Egress
Restrictive outbound networking requires an explicit inventory of destinations the platform, deployment pipeline, model provider, identity provider, and enabled integrations must reach.
Build the Allowlist by Category
Maintain customer-specific destinations for:
- Azure identity and token endpoints,
- container and package registries used by the approved build process,
- Azure control-plane and service endpoints required by the architecture,
- model inference, embeddings, safety, and document-processing services,
- customer-approved collaboration and business integrations,
- email, webhook, and notification destinations,
- monitoring, status, certificate, and time dependencies,
- software update and vulnerability metadata sources where required.
Do not enable every potential integration destination. Add optional destinations only when the corresponding product capability is approved and enabled.
Inventory Fields
For each rule, record destination or service tag, protocol and port, source workload, purpose, owner, priority, environment, approval date, and validation evidence. Prefer Azure service tags or private endpoints where they meet the design; use exact host rules when required by customer policy.
Change Procedure
- A feature owner requests the destination and explains the data flow.
- Security reviews classification, processing location, authentication, and necessity.
- Operations applies the narrowest rule in a non-production environment.
- The team tests success and verifies that unrelated traffic remains blocked.
- The rule, evidence, owner, and removal condition are recorded.
- Unused rules are removed during periodic review.
The complete production allowlist is customer-controlled information and should not be published in public documentation.