Skip to main content
This blueprint describes a fully private Cognisafe deployment where no data-plane traffic traverses the public internet. Every Azure service Cognisafe depends on — Azure OpenAI, PostgreSQL Flexible Server, Key Vault, Container Registry, and Redis Cache — is accessed via Azure Private Endpoints with private DNS resolution. The Cognisafe proxy, API, and workers run inside AKS pods in a dedicated VNet. No public IPs are assigned to any data-plane component. This architecture satisfies:
  • Data residency requirements (all traffic stays within Azure in your chosen region)
  • PCI DSS / HIPAA / ISO 27001 network isolation controls
  • Zero-trust posture for AI workloads (no implicit outbound internet access)

Architecture

Terraform: VNet and subnets

Terraform: Private endpoint for Azure OpenAI

Terraform: Remaining private endpoints

Apply the same pattern for each dependent service. Key differences per service:

Private DNS zones reference

Every DNS zone must be linked to the VNet (registration_enabled = false). The private endpoint’s NIC IP is registered automatically by the private_dns_zone_group block — no manual A records needed.

Network Security Group rules

Define NSGs for each subnet. The rules below use the principle of least-privilege: only explicitly required flows are permitted.

proxy-subnet NSG

api-subnet NSG

NAT Gateway for controlled egress

The safety worker needs outbound internet access for PyPI (pip install during container build is fine; runtime pip calls are not). If your workers need to reach external services at runtime, route them through an Azure NAT Gateway with a static public IP — this gives you a known egress IP for allowlisting.

Required egress domains

If you deploy an egress firewall (Azure Firewall or third-party NVA) in front of the NAT Gateway, allowlist the following FQDNs. All traffic is HTTPS/443 unless noted.
pypi.org is needed only during container image builds in CI/CD, not at runtime. If your workers do not install packages at runtime, omit it from runtime egress rules. Pin all Python dependencies in requirements.txt and bake them into the image.
If OPENAI_API_KEY is set and SCORER_MODEL uses a non-Azure OpenAI endpoint, the safety worker will call api.openai.com at runtime. To keep scoring fully private, deploy a separate Azure OpenAI resource for scoring and set SCORER_MODEL to a deployment on that resource, pointing the worker at the private endpoint.

Azure Policy: enforce private endpoint usage

Assign built-in policies to prevent anyone from accidentally creating public-facing Azure OpenAI or PostgreSQL resources in this subscription.

Defender for Cloud integration

Enable Microsoft Defender for Cloud on the subscription to receive:
  • Defender for Containers — image vulnerability scanning, AKS runtime threat detection
  • Defender for Azure OpenAI — anomalous prompt detection, jailbreak alerts (complements Cognisafe scoring)
  • Defender for Databases — SQL injection detection on PostgreSQL, unusual access patterns

Compliance dashboard

After enabling Defender, navigate to Microsoft Defender for CloudRegulatory Compliance in the Azure Portal. Add the relevant standards:
  • NIST SP 800-53 Rev. 5 — network isolation, access control, audit logging
  • ISO 27001:2013 — information security management
  • PCI DSS v4 — if processing payment-adjacent data
Defender for Cloud will surface non-compliant resources (e.g., a subnet without an NSG, a Key Vault without purge protection) with direct remediation links.

Verify the private endpoint setup

Run these DNS and connectivity checks as part of your deployment pipeline smoke tests. A private endpoint misconfiguration (missing DNS zone link, wrong subresource name) will cause silent failures — the service resolves to the public IP and either times out (if outbound is blocked) or succeeds insecurely (if outbound is open). Catching this in CI prevents production incidents.