Network Segmentation Analysis Prompt for Architects

Infrastructure architects and security engineers use this prompt during design review gates to audit network segmentation before deployment. The prompt takes a description of VPCs, subnets, security groups, NACLs, and firewall rules—whether from a design document, a diagram described in text, or an infrastructure-as-code plan—and produces a structured segmentation audit. The audit identifies overly permissive rules, missing isolation between tiers, and blast-radius risks that violate least-privilege network access. This is a reasoning prompt, not a runtime configuration scanner. It works on design intent, not live state.

Use this prompt before Terraform apply, as part of a security architecture review board, or when evaluating a proposed network change. The prompt expects a detailed textual description of the network design, including CIDR ranges, security group rules, NACL entries, routing tables, and the intended communication paths between application tiers. It does not replace a cloud security posture management tool or a runtime policy engine. Instead, it helps architects catch design-level segmentation flaws—such as a database subnet that accepts traffic from a public load balancer or a management plane that trusts all VPC CIDRs—before those flaws become deployed infrastructure.

Do not use this prompt for real-time configuration auditing, compliance scanning, or incident response. It is not designed to parse live AWS Config output, CloudTrail logs, or firewall flow logs. The prompt reasons over the design as described; if the description is incomplete or inaccurate, the audit will be incomplete or inaccurate. Human review is required for every finding before it becomes a remediation ticket. The prompt can surface risks and suggest hardening steps, but an architect must validate each finding against the actual design intent, business requirements, and operational constraints. When the design is complex, break it into smaller scoped reviews—one per trust zone or one per application tier—to keep the analysis focused and actionable.

This prompt template is designed to be pasted directly into your AI harness or orchestration layer. It accepts a system architecture description and a set of constraints, then produces a structured segmentation audit. Every placeholder is enclosed in square brackets. Replace each one with real design data before execution. The prompt instructs the model to act as an infrastructure security architect, systematically evaluating isolation, rule scoping, and blast-radius risks against a least-privilege network access standard.

textCopy
You are an infrastructure security architect reviewing a network segmentation design. Your task is to produce a structured audit that identifies overly permissive rules, missing isolation boundaries, and blast-radius risks. Ground every finding in the provided design description. Do not invent components, CIDR ranges, or rules that are not present in the input.

## INPUT DESIGN
[DESIGN_DESCRIPTION]

## CONSTRAINTS
- Compliance framework: [COMPLIANCE_STANDARD]
- Trust zone definitions: [TRUST_ZONE_MAP]
- Data classification levels in scope: [DATA_CLASSIFICATIONS]
- Maximum acceptable blast radius (number of systems per segment): [BLAST_RADIUS_LIMIT]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "summary": "<One-paragraph executive summary of segmentation posture>",
  "findings": [
    {
      "id": "<F-001, F-002, ...>",
      "severity": "<CRITICAL | HIGH | MEDIUM | LOW>",
      "category": "<OVERLY_PERMISSIVE_RULE | MISSING_ISOLATION | BLAST_RADIUS | TRUST_ZONE_VIOLATION | COMPLIANCE_GAP>",
      "source_component": "<Component or CIDR from the design>",
      "destination_component": "<Component or CIDR from the design>",
      "rule_or_boundary": "<Specific rule, security group, firewall entry, or subnet boundary>",
      "finding": "<Clear description of the issue>",
      "risk": "<What an attacker or failure could achieve>",
      "recommendation": "<Specific, actionable remediation step>",
      "least_privilege_alternative": "<The minimum required access if the rule cannot be removed>"
    }
  ],
  "trust_zone_boundary_assessment": [
    {
      "zone_pair": "<Source Zone> -> <Destination Zone>",
      "intended_isolation": "<YES | NO>",
      "actual_isolation": "<YES | NO | PARTIAL>",
      "violations": ["<List of rule IDs or descriptions that breach this boundary>"]
    }
  ],
  "blast_radius_analysis": [
    {
      "segment": "<Segment name or CIDR>",
      "reachable_systems_count": <integer>,
      "exceeds_limit": <true | false>,
      "lateral_movement_paths": ["<Description of paths an attacker could take from this segment>"]
    }
  ],
  "compliance_gaps": [
    {
      "requirement": "<Specific control requirement from the compliance framework>",
      "status": "<MET | PARTIALLY_MET | NOT_MET>",
      "evidence": "<What in the design supports or contradicts compliance>"
    }
  ],
  "overall_risk_rating": "<CRITICAL | HIGH | MEDIUM | LOW>",
  "top_priority_actions": ["<Ordered list of the 3-5 most important remediations>"]
}

## RULES
1. Every finding must reference a specific component, rule, or boundary from [DESIGN_DESCRIPTION].
2. If a trust zone boundary is not defined in [TRUST_ZONE_MAP], flag it as a MISSING_ISOLATION finding.
3. For any rule that allows access broader than a single port and source, classify it as OVERLY_PERMISSIVE_RULE.
4. If the design does not contain enough information to assess a category, set its array to empty and note the gap in the summary.
5. Do not recommend removing a rule without providing a least_privilege_alternative.
6. If [COMPLIANCE_STANDARD] is provided, map every compliance_gap to a specific control ID or requirement text.

After pasting this template, replace each placeholder with concrete data from your architecture review. The [DESIGN_DESCRIPTION] should include VPC layouts, subnet CIDRs, security group rules, firewall policies, NACLs, and any peering or transit gateway configurations. The [TRUST_ZONE_MAP] must explicitly label which subnets or CIDRs belong to which trust tier (e.g., public, DMZ, application, data, management). If your compliance framework does not apply, set [COMPLIANCE_STANDARD] to "none" and the model will skip compliance-gap analysis. Always run the output through a JSON schema validator before ingesting it into your downstream systems. For high-risk production environments, route CRITICAL and HIGH severity findings to a human security architect for review before accepting remediation recommendations.

This prompt is designed to operate as a stateless analysis step within a broader security review workflow. It expects a structured architectural description as input and returns a structured audit report. The implementation harness must enforce input schema validation before the prompt is called, validate the output schema after the model responds, and route findings to the appropriate review queue based on severity. Because network segmentation errors can create direct paths to production data, the harness should never automatically apply remediation suggestions—only flag them for human review.

Input Validation: Before calling the model, validate that the [NETWORK_DESIGN] input conforms to a minimum schema. At a minimum, require a list of security groups or firewall rules with source, destination, port, and protocol fields. Reject inputs that are purely narrative without structured rule data. Model Selection: Use a model with strong reasoning capabilities and large context windows (e.g., Claude 3.5 Sonnet, GPT-4o) because the analysis requires holding many rules in memory and reasoning about transitive access paths. Avoid smaller or older models that will hallucinate rule relationships. Output Validation: Parse the model's JSON output and validate that every finding includes a rule_reference field that maps back to a specific input rule. If a finding lacks a source reference, discard it or flag it for human review as ungrounded. Retry Logic: If the model returns malformed JSON, retry once with a simplified instruction that asks for valid JSON only. If the second attempt fails, log the raw output and escalate to a human reviewer rather than retrying indefinitely.

Tool Integration: For production use, wire this prompt into a pipeline that first extracts network rules from infrastructure-as-code (Terraform, CloudFormation, Pulumi) or cloud API exports. Do not rely on architects manually typing rules into the prompt. A pre-processing step should normalize rule formats into the expected [NETWORK_DESIGN] schema. Logging and Audit Trail: Log every prompt invocation with the input hash, model version, output hash, and reviewer decision. This creates an audit trail for compliance reviews and allows regression testing when the prompt or model changes. Human Approval Gate: Route findings with severity: critical or blast_radius: high to a mandatory human review queue. Findings with severity: low and a clear remediation suggestion can be auto-filed as tickets. Never auto-close findings without human acknowledgment. Eval Harness: Before deploying a new prompt version, run it against a golden dataset of known network designs with labeled vulnerabilities. Measure precision (did it flag real issues?), recall (did it miss known issues?), and hallucination rate (did it invent rules not present in the input?). Gate deployment on recall >= 0.90 and hallucination rate <= 0.05.