☁️ Reviewing Cloud Security Group Rules With AI Before They Open the World

Almost every cloud breach I’ve read a postmortem for has the same quiet line in it: a security group allowed 0.0.0.0/0 on a port that should never have faced the internet. Database ports, admin panels, internal APIs, exposed because someone needed to test something at 2am, opened a rule “temporarily,” and the temporary rule outlived the person who created it. Cloud firewalls are deceptively easy to loosen and almost never tightened, because tightening risks breaking something and nobody knows exactly what depends on what.

Auditing security groups across AWS, GCP, and Azure is exactly the kind of large, repetitive, pattern-matching work that AI handles well. I use the model as a fast junior cloud engineer that reads the rules, flags the dangerous ones, and explains the exposure, while I verify every finding and own every change. This is defensive review only, and I never paste real account IDs, credentials, or live access keys into a prompt. I export rule definitions, sanitize identifiers, and reason about structure.

Pull the rules into a form you can review

You can’t audit what you can’t see all at once. I export the firewall rules to JSON, scrub account-specific identifiers, and hand the structure to the AI. On AWS:

aws ec2 describe-security-groups \
  --query 'SecurityGroups[].{Name:GroupName,Ingress:IpPermissions}' \
  --output json > sgs.json

GCP uses gcloud compute firewall-rules list --format=json and Azure uses az network nsg rule list. Whatever the provider, the goal is the same: a complete, structured dump. Then:

Here are sanitized firewall rules (identifiers redacted). List every rule that allows ingress from 0.0.0.0/0 or ::/0, and for each, name the port and what service typically runs there. Rank by risk. Defensive audit only.

The model is fast at spotting that an open 3306, 5432, 6379, 27017, or 9200 is a database or cache that should never face the internet, and that an open 22 or 3389 is remote administration that belongs behind a bastion or VPN.

Hunt the rules that should never exist

Some openings are categorically wrong regardless of context. I have the AI build that list first, because these are unambiguous:

• Any database or cache port open to the world
• SSH or RDP open to 0.0.0.0/0 instead of a known admin range
• Wide port ranges open broadly (a rule allowing 0-65535 is a non-rule)
• Rules referencing CIDR blocks far larger than the team that needs them

Pro Tip: a rule that allows a giant range like 1024-65535 to a broad source is functionally an open door even though it looks specific. Ask the AI to flag any rule whose port range spans more than a handful of ports, not just the literal all-ports rules. Attackers don’t care that you technically scoped it.

Trace whether an open rule is even reachable

Not every scary-looking rule is actually exploitable, and not every safe-looking one is actually safe. Reachability depends on the layers: the security group, the network ACL, whether the instance has a public IP, and the route table. I describe the topology to the AI and ask it to reason about effective exposure:

Given this sanitized rule allowing port 5432 from anywhere, and the fact that the instance sits in a private subnet with no public IP and no NAT ingress, is this actually reachable from the internet? Explain the path.

This matters because it separates “fix this now, it’s live” from “fix this soon, it’s latent.” The AI is good at walking the path, but I verify against the actual route tables and subnet config, because its reasoning is only as good as the topology I described, and a mistake in my description hides real exposure.

Tighten toward least privilege without breaking things

The dangerous part of any firewall cleanup is removing access something quietly relies on. Before I narrow a rule, I want to know who actually uses it. Flow logs answer that. I export a window of accepted connections to the rule’s port, sanitize source addresses, and ask the AI to characterize the real callers:

Here are sanitized source ranges that actually connected to this port over the last week. Propose the tightest CIDR allowlist that covers the legitimate callers, and flag any source that looks anomalous.

Then I replace the 0.0.0.0/0 with the specific ranges, or better, a security-group reference so the allow follows the source group rather than IP addresses. I stage the change and watch flow logs for denied connections before considering it done.

Catch the cross-account and peering surprises

In real estates, security groups reference each other, VPCs peer, and a rule that looks scoped to “this account” can be reachable from a peered network or a shared services account. I have the AI map the references and flag any rule whose effective source crosses a trust boundary I didn’t intend. The classic surprise is a security group that allows another security group which itself allows the world, so the “scoped” rule inherits global exposure two hops away. The model is good at chasing those chains, and each one it surfaces is a finding I confirm in the console.

Make it continuous, and keep humans on the change

A one-time audit decays the moment someone adds the next temporary rule. The durable practice is to run the audit on a schedule and to gate firewall changes through review. I keep the exported rules in version control where infrastructure-as-code defines them, and route changes through the code review dashboard so the AI’s exposure analysis lands as inline comments a human approves, never the model applying a firewall change itself. When an over-broad rule turns out to have been exploited, the response and timeline live in the incident response dashboard.

The reusable cloud-audit prompts live in our prompts library, with the security set bundled in the DevOps security prompt pack. For reading large rule dumps and reasoning about reachability I’ve leaned on Claude, which handles the volume and the structured JSON well.

The takeaway

Over-broad security group rules are the single most common cloud-exposure footgun, and they accumulate because tightening feels riskier than leaving them. An AI reviewer turns a sprawling, multi-account firewall audit into a fast, repeatable pass, acting as the junior cloud engineer that flags the dangerous rules and explains the exposure while you verify reachability, confirm the real callers from flow logs, and own every change. Keep it defensive, keep account credentials and real IDs out of the prompt, and treat any temporary rule as a leak until it’s gone. The rest of the security hardening category covers the IAM, networking, and secrets controls that surround your perimeter.