Network Policy Change Impact Analysis Prompt

Network security engineers and platform teams use this prompt to analyze firewall rule diffs, Kubernetes NetworkPolicy changes, or security group modifications before deployment. The core job-to-be-done is translating a low-level policy diff into a high-level service impact assessment. Instead of manually tracing every CIDR block, port, and label selector to understand which service-to-service communication paths are affected, the engineer provides the diff, a service inventory, and the change rationale. The prompt returns a structured analysis that maps each rule change to the specific service pairs impacted, identifies unintended exposure or isolation, flags egress rule gaps, and assigns a risk severity to each finding. This turns a pre-deployment review that might take hours of cross-referencing architecture diagrams into a consistent, repeatable analysis that surfaces hidden blast radius before the change is applied.

This prompt assumes you have three concrete inputs ready: the policy diff itself (whether from git diff, a firewall management console, or a Kubernetes manifest comparison), a service inventory or architecture map that defines known service identities and their expected communication patterns, and the intended change rationale (such as a ticket description or change request summary). Without these inputs, the model cannot ground its analysis in your actual architecture and will produce generic or misleading findings. The prompt is designed for pre-deployment review, not for analyzing already-deployed policies or for generating new policy rules from scratch. It also does not replace penetration testing, runtime network monitoring, or eBPF-based flow analysis—it operates purely on the static policy definitions you provide.

Do not use this prompt when the policy change is trivial and well-understood by the team, such as adding a single known IP to an existing allowlist with no architectural implications. Do not use it as a substitute for a security architect's judgment on complex zero-trust migrations or when the service inventory is stale or incomplete—garbage in, garbage out applies with full force here. Every finding marked critical or high severity must receive human review before the change is applied. The prompt's risk severity assignments are a starting point for triage, not an automated approval gate. Wire the output into your change management workflow so that high-severity findings block the deployment until a qualified engineer acknowledges them.

This prompt template is designed to be copied directly into your AI harness, LLM playground, or application code. It accepts a network policy diff, an inventory of affected services, and optional environment context, then produces a structured impact analysis. Every placeholder in square brackets must be replaced with actual data before the prompt is sent to the model. The template enforces a strict output schema so downstream systems can parse the results without custom post-processing.

textCopy
You are a network security reviewer analyzing a firewall or network policy change.

Your task is to map the rule changes in the provided diff to affected service communication paths, identify unintended exposure or isolation, flag egress rule gaps, and assign a risk severity to each finding.

## INPUT

**Network Policy Diff:**
[POLICY_DIFF]

**Service Inventory (name, IP/CIDR, port, protocol, role):**
[SERVICE_INVENTORY]

**Environment Context (e.g., production, staging, PCI scope, multi-account):**
[ENVIRONMENT_CONTEXT]

**Previous Policy Version (optional, for comparison):**
[PREVIOUS_POLICY]

## CONSTRAINTS

- Only report findings that are supported by specific rule changes in the diff.
- Do not speculate about services not listed in the service inventory.
- If a rule change affects multiple service pairs, list each pair separately.
- For each finding, cite the exact rule line or rule ID from the diff.
- If no high or critical findings exist, state that explicitly rather than inventing risks.
- Flag any egress rules that appear to allow traffic to `0.0.0.0/0` or broad CIDR ranges without documented justification.

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "analysis_summary": {
    "total_rules_changed": <integer>,
    "total_affected_service_pairs": <integer>,
    "highest_risk_level": "critical" | "high" | "medium" | "low" | "none",
    "requires_human_review": <boolean>
  },
  "findings": [
    {
      "finding_id": "string",
      "severity": "critical" | "high" | "medium" | "low",
      "rule_reference": "string (line number or rule ID from diff)",
      "change_type": "added" | "modified" | "removed",
      "affected_service_pair": {
        "source": "string (service name from inventory)",
        "destination": "string (service name or CIDR)",
        "protocol": "string",
        "port": "string or integer"
      },
      "impact_description": "string (what changed and why it matters)",
      "risk_rationale": "string (why this severity was assigned)",
      "unintended_exposure": <boolean>,
      "unintended_isolation": <boolean>,
      "egress_gap": <boolean>,
      "recommendation": "string (actionable fix or verification step)"
    }
  ],
  "egress_rule_gaps": [
    {
      "rule_reference": "string",
      "destination": "string",
      "gap_description": "string",
      "risk": "string"
    }
  ],
  "services_without_explicit_rules": [
    "string (service names from inventory not referenced in any rule)"
  ]
}

## RISK SEVERITY DEFINITIONS

- **critical**: Unrestricted exposure of sensitive services to public or untrusted networks; removal of isolation for PCI/PII-scoped services; egress to `0.0.0.0/0` from high-privilege services.
- **high**: Broadening of access to internal services beyond documented requirements; removal of egress restrictions for services with sensitive data access.
- **medium**: Rule modifications that expand port ranges or protocol access without clear justification; stale rules that should be audited.
- **low**: Cosmetic changes, rule reordering, comment updates, or changes that do not alter traffic flow.

## EXAMPLES

[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS

1. Parse the policy diff and identify every added, modified, or removed rule.
2. For each rule change, determine which service pairs from the inventory are affected.
3. Assess whether the change introduces unintended exposure, unintended isolation, or an egress gap.
4. Assign a severity based on the definitions above.
5. Populate the output JSON completely. Do not omit fields.
6. If the diff is empty or contains no rule changes, return an empty findings array with `highest_risk_level: "none"`.

To adapt this template for your environment, replace [SERVICE_INVENTORY] with a structured list of your services including their network identifiers, roles, and data classification levels. The [ENVIRONMENT_CONTEXT] placeholder should include whether the change targets production, PCI-scoped networks, or multi-account deployments, as this directly affects severity assignment. The optional [FEW_SHOT_EXAMPLES] placeholder can contain one or two example input-output pairs showing correct severity calibration for your organization's risk tolerance. If your policy management system uses rule IDs rather than line numbers, adjust the rule_reference field description accordingly. For high-risk environments, wire the requires_human_review flag into your deployment pipeline so any analysis returning true blocks the apply step until a human approves.

This prompt is designed to run as a gating step in a CI/CD pipeline when network policy manifests (e.g., Kubernetes NetworkPolicy, Calico, Cilium, or cloud firewall rules) are modified in a pull request. The implementation harness should extract the diff of the changed policy files, assemble the required context (current policy state, service dependency map, and organizational security constraints), and invoke the model. The output must be parsed into a structured risk report that downstream systems can act on: blocking the PR, creating Jira tickets, or notifying the security team. Because network policy misconfigurations can cause both security breaches and production outages, the harness must treat this as a high-risk workflow with mandatory human review for any finding rated CRITICAL or HIGH severity.

Integration pattern: Use a webhook or CI plugin that triggers on changes to paths like **/network-policies/**, **/firewall/**, or **/security-groups/**. The harness should: (1) extract the policy diff using git diff against the base branch; (2) retrieve the current service-to-service communication map from a service mesh control plane API, CMDB, or a pre-built dependency graph file in the repository; (3) inject the organizational security constraints from a policy-as-code repository (e.g., "no egress to 0.0.0.0/0", "all inter-namespace traffic requires explicit allow rules"); (4) call the model with the assembled prompt; (5) parse the JSON output and validate it against the expected schema using a JSON Schema validator; (6) on parse failure, retry once with a repair prompt that includes the validation error; (7) route CRITICAL and HIGH findings to a human approval queue (e.g., a GitHub Review or ServiceNow change request) and auto-approve LOW and informational findings with a comment on the PR.

Model choice and latency budget: Use a model with strong structured output and reasoning capabilities, such as Claude 3.5 Sonnet or GPT-4o, with the response_format set to json_schema or the equivalent structured output mode. Set a timeout of 30 seconds and a token budget of 4000 output tokens. For large policy sets, split the diff into chunks of no more than 10 rule changes per invocation and merge the results. Logging and audit trail: Log the full prompt, raw model response, parsed output, and validation result to an immutable audit store. This is critical for compliance and post-incident review. Include the diff SHA, PR number, and timestamp in the log metadata. Eval gate: Before deploying this harness to production, run it against a golden dataset of 20 known policy changes (10 safe, 10 risky) and measure precision and recall on CRITICAL/HIGH findings. Require 100% recall on known breaking changes before enabling the blocking gate. What to avoid: Do not auto-apply remediation suggestions. Do not run this prompt on every commit if policy files haven't changed. Do not skip the service dependency map injection—without it, the model cannot accurately assess blast radius and will produce generic, low-value output.