v2.4.0 | Report Errata
docs security docs security

Dedicated VPC with Segmentation

The AI system’s infrastructure should be deployed within a dedicated Virtual Private Cloud (VPC) or equivalent network isolation boundary, separate from the organisation’s general-purpose infrastructure. Network segmentation within the VPC isolates different system components (data ingestion, feature engineering, model serving, human oversight interface, logging) into distinct subnets with controlled communication paths.

Segmentation reduces the blast radius of a compromise. If an attacker gains access to the data ingestion subnet, segmentation prevents lateral movement to the model serving infrastructure, the model artefact store, or the logging backend. The security team defines network policies as allowlists: traffic not explicitly permitted is denied by default. Security groups, network ACLs, and Kubernetes NetworkPolicies provide the enforcement mechanisms.

The VPC configuration is documented as infrastructure-as-code and subject to version control and security scanning. Cloud security posture management (CSPM) tools continuously verify that the deployed network configuration matches the declared baseline. Drift from the baseline triggers automated alerts. The VPC architecture, segmentation policy, and CSPM configuration are documented in Module 9.

Key outputs

  • Dedicated VPC with subnet segmentation per system component
  • Allowlist-based network policies (security groups, NetworkPolicies)
  • CSPM continuous verification against the declared baseline
  • Module 9 AISDP documentation

Ingress/Egress Restriction & WAF

Ingress restrictions control which external traffic can reach the AI system’s components. Only the inference API endpoint and the human oversight interface should be accessible from outside the VPC; all other components (data pipelines, model registry, logging infrastructure, administrative interfaces) should be internal only. A Web Application Firewall (WAF) sits in front of internet-facing endpoints and filters common attack patterns (SQL injection, XSS, request smuggling).

Egress restrictions control which external destinations the AI system’s components can reach. The model serving infrastructure should have no outbound internet access unless it needs to call a third-party API (such as a cloud-hosted LLM). Egress restrictions prevent data exfiltration: even if an attacker compromises an internal component, they cannot transmit data to an external destination if egress is blocked.

Both ingress and egress rules are defined as infrastructure-as-code and enforced at the VPC level. The WAF configuration should be tuned to the AI system’s specific traffic patterns to minimise false positives that could block legitimate inference requests. WAF logs are integrated with the SIEM for correlation and alerting. The ingress/egress configuration and WAF rules are documented in Module 9.

Key outputs

  • Ingress restrictions limiting external access to inference API and oversight interface
  • Egress restrictions preventing unauthorised outbound connections
  • WAF configuration tuned to AI system traffic patterns
  • Module 9 AISDP documentation

DDoS Protection

Distributed denial-of-service attacks target the availability of internet-facing endpoints. For high-risk AI systems, unavailability may have compliance implications: if the system is required to process decisions within defined timeframes (for example, credit decisions, employment screening), prolonged unavailability may constitute a failure to meet the system’s intended purpose.

Cloud-native DDoS protection services (AWS Shield, Azure DDoS Protection, Google Cloud Armor) provide volumetric attack mitigation at the network edge. These services absorb traffic floods before they reach the AI system’s infrastructure. Application-layer DDoS protection combines the rate limiting described in with traffic analysis that distinguishes legitimate inference requests from attack traffic.

The DDoS protection configuration should be documented in Module 9, including the protection tier (basic or advanced), the traffic thresholds that trigger mitigation, the expected behaviour during an attack (partial degradation, queueing, or rejection of excess requests), and the integration with the incident response plan. The system’s behaviour during DDoS attacks should be tested periodically through controlled load testing.

Key outputs

  • Cloud-native DDoS protection configuration
  • Application-layer rate limiting integration
  • Expected system behaviour during DDoS events
  • Module 9 AISDP documentation
On This Page