SOC 2 & PCI require a current network diagram. An AI agent can generate one in 90 seconds.

Series: AI Agents as a Security Force Multiplier. Post 3. Originally published on LinkedIn.

PCI DSS Requirement 1.2.3 requires a current network diagram showing all connections between the cardholder data environment and other networks, including wireless networks. SOC 2 auditors expect architecture documentation to reflect the current state of the environment under the availability and security trust service criteria.

In practice, most teams maintain a diagram that was accurate at the time it was created and has not been updated since. Engineers add subnets, replace gateways, and modify security groups without updating documentation. The diagram in the audit package does not match the environment the auditor is reviewing.

An AI agent with read-only AWS CLI access generates the diagram directly from the live environment. It runs AWS API calls across your accounts and regions, parses the JSON output, identifies relationships between resources, and produces a diagram that reflects current infrastructure state.

---

What the Agent Runs

Step 1: Enumerate VPCs and subnets

aws ec2 describe-vpcs --output json
aws ec2 describe-subnets --output json
aws ec2 describe-availability-zones --output json

Step 2: Map internet entry and exit points

aws ec2 describe-internet-gateways --output json
aws ec2 describe-nat-gateways --output json
aws ec2 describe-egress-only-internet-gateways --output json

Step 3: Pull routing layer

aws ec2 describe-route-tables --output json
aws ec2 describe-network-acls --output json

Step 4: Security group rules

aws ec2 describe-security-groups --output json
aws ec2 describe-security-group-rules --output json

Step 5: Cross-VPC connectivity

aws ec2 describe-vpc-peering-connections --output json
aws ec2 describe-transit-gateways --output json
aws ec2 describe-transit-gateway-attachments --output json
aws ec2 describe-vpn-connections --output json
aws ec2 describe-vpn-gateways --output json

Step 6: Load balancers and public IP assignments

aws elbv2 describe-load-balancers --output json
aws elbv2 describe-target-groups --output json
aws ec2 describe-addresses --output json  # Elastic IPs

Step 7: VPC endpoints

aws ec2 describe-vpc-endpoints --output json

Step 8: Compute placement

aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Subnet:SubnetId,VPC:VpcId,SG:SecurityGroups,PublicIP:PublicIpAddress,Tags:Tags}' \
  --output json
aws rds describe-db-instances --output json
aws lambda list-functions --output json
aws ecs list-clusters --output json

The agent determines whether a subnet is public or private by checking its route table associations. A subnet with a route to an Internet Gateway (0.0.0.0/0 pointing to igw-*) is public. All others are private. It then maps security group rules to identify which traffic paths are permitted between tiers.

---

What Comes Out

The output is a Mermaid diagram: plain text that renders as a visual in GitHub, Confluence, or any documentation tool that supports Mermaid.

Here is an example output for a standard 3-tier architecture:

graph TD
    Internet["🌐 Internet"]

    subgraph VPC ["VPC: 10.0.0.0/16 (prod)"]
        subgraph PublicSubnets ["Public Subnets (us-east-1a/b)"]
            IGW["Internet Gateway"]
            ALB["ALB (public)\n0.0.0.0/0:443"]
            NAT["NAT Gateway"]
        end

        subgraph AppSubnets ["Private App Subnets (us-east-1a/b)"]
            EC2_App["EC2: app-server-01\nSG: sg-app\n:8080 from ALB only"]
            EC2_App2["EC2: app-server-02\nSG: sg-app\n:8080 from ALB only"]
        end

        subgraph DataSubnets ["Private Data Subnets (us-east-1a/b)"]
            RDS["RDS: prod-postgres\nSG: sg-db\n:5432 from App SG only"]
        end
    end

    Internet --> IGW
    IGW --> ALB
    ALB --> EC2_App
    ALB --> EC2_App2
    EC2_App --> RDS
    EC2_App2 --> RDS
    EC2_App --> NAT
    EC2_App2 --> NAT
    NAT --> Internet

For CDE-scoped environments, the agent adds annotations identifying which subnets are in-scope, which security group rules permit cardholder data flows, and which resources have no route to the internet. PCI Req 1.3 requires you to demonstrate CDE isolation from untrusted networks. The agent derives that assertion from route table data rather than from a manually maintained diagram.

When I ran this against our CDE accounts, the output confirmed 22 servers across three AWS accounts with zero internet-reachable instances. A QSA has to take that claim on faith from a static diagram. The agent derives it from route tables.

---

What the Agent Finds That a Static Diagram Cannot

A manually maintained diagram reflects the state of the environment at the time it was last edited. The agent reflects the state at the time it runs. The difference between those two points produces findings:

• Security groups with 0.0.0.0/0 inbound on ports not present in the diagram
• Subnets with a route to an Internet Gateway that are not classified as public in the documentation
• VPC peering connections created after the last diagram update
• EC2 instances running in CDE subnets that were not present in the previous diagram
• Elastic IPs assigned to instances with no documented reason for internet reachability

Each of these represents a discrepancy between documented architecture and actual infrastructure state. Auditors find these discrepancies during fieldwork. Running the agent before the audit surfaces them first, though it will not catch what is not in AWS: the firewall rule your network team added outside IaC, the shadow account, the on-prem jump box nobody documented.

---

The Permission Model

The agent uses a read-only IAM policy. No write access is required.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "elasticloadbalancing:Describe*",
        "rds:Describe*",
        "lambda:List*",
        "ecs:List*",
        "ecs:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

This policy can be shared with your QSA to document what access the automation uses.

---

Running It on a Schedule

The diagram does not need to be generated manually before each audit. The agent can run on a scheduled basis: weekly or after any infrastructure change, committing the updated Mermaid file to your documentation repository. Every commit is timestamped and attributed, which provides an audit trail of infrastructure state over time.

When your auditor asks for a current network diagram, you hand them the most recent output, the generation date, and a git log. What they do with the gaps it reveals is still your problem.

---

Next in this series: IAM access review: credential reports, MFA gaps, stale access keys, and inactive users, packaged automatically for auditors.

---

Need current network diagrams and the controls to back them up for your SOC 2 or PCI DSS audit? See how 543HQ structures compliance programs.