Firewalls haven’t changed much in 20 years. They still expose a web UI, expect humans to click buttons, and rely on manual rule updates.
What has changed is how we automate infrastructure — and how AI can reason about network events faster than any human.

AI‑assisted infrastructure is no longer a future concept — it’s here.
But when it comes to firewalls, the stakes are higher than anywhere else in your stack.
A misconfigured rule can take down production, expose internal systems, or break VPNs.

This article shows how to safely automate firewall management using any AI model:

• Claude (Anthropic)
• Gemini (Google)
• OpenAI (GPT‑4/5)
• Local LLMs (Ollama, LM Studio, GPU‑accelerated models)

…and how to do it for free, using:

• GitHub Actions as the execution engine
• WireGuard as the secure transport
• Zero exposed ports
• Vendor‑agnostic APIs or CLI

This works with any firewall vendor, including:

• Palo Alto Networks
• Fortinet FortiGate
• Check Point
• Cisco ASA / FTD
• OPNsense
• pfSense
• VyOS
• MikroTik
• Linux iptables/nftables

The goal:
AI proposes. You approve. GitHub executes. The firewall stays isolated.

Why AI‑Driven Firewall Automation Is Finally Possible

Modern LLMs can:

• Understand network topologies
• Explain logs and anomalies
• Generate API calls or CLI commands
• Validate rule changes
• Detect misconfigurations
• Suggest optimizations
• Compare policies across vendors

But they should never have direct access to your firewall.

The solution is a zero‑trust automation pipeline:

Code

AI Model → Validation Layer → GitHub Action → WireGuard → Firewall API/CLI

This gives you:

• Full auditability
• Human‑in‑the‑loop approvals
• No public exposure
• Vendor‑agnostic automation
• Free infrastructure

Why This Architecture Works

Zero attack surface

No public API.
No exposed ports.
No inbound access.

Vendor‑agnostic

Works with Palo Alto, Fortinet, Check Point, Cisco, OPNsense, pfSense, VyOS, Linux.

Model‑agnostic

Claude, Gemini, OpenAI, local LLMs — all compatible.

Free

WireGuard: free
GitHub Actions: free
Local LLMs: free

Human‑in‑the‑loop

AI proposes.
You approve.
GitHub executes.

Architecture Overview

The design is intentionally simple

Local LLM only

Hybrid

Technical Architecture: The "Data Diode" Flow

The architecture prevents the AI from ever "touching" the firewall directly. Instead, it follows a strict Proposal -> Review -> Execution pipeline

The AI generates:

• API requests
• CLI commands
• Rule updates
• Config snippets
• Explanations

The model never touches the firewall directly.

Validation Layer

A small script or prompt template that:

• Sanitizes commands
• Enforces allow‑lists
• Blocks destructive actions
• Requires human approval

GitHub Actions

Executes commands inside a controlled environment.

WireGuard Tunnel

Creates a private, encrypted path from GitHub to your firewall.

Firewall

Receives commands via:

• API (Palo Alto, Fortinet, OPNsense, etc.)
• SSH (VyOS, Linux, MikroTik)
• REST (Check Point, pfSense)

Build a WireGuard Tunnel to Your Firewall

WireGuard is perfect for this:

• Fast
• Encrypted
• Simple
• Free
• Works on every firewall vendor (directly or via a sidecar VM)

Example firewall‑side config:

Code

[Interface]
Address = 10.10.10.1/24
PrivateKey = <FIREWALL_PRIVATE_KEY>
ListenPort = 51820

[Peer]
PublicKey = <GITHUB_PUBLIC_KEY>
AllowedIPs = 10.10.10.2/32

GitHub runner config:

Code

[Interface]
Address = 10.10.10.2/32
PrivateKey = <GITHUB_PRIVATE_KEY>

[Peer]
PublicKey = <FIREWALL_PUBLIC_KEY>
Endpoint = <your-public-ip>:51820
AllowedIPs = 10.10.10.1/32
PersistentKeepalive = 25

Create a Minimal‑Privilege Automation User

Every vendor supports scoped automation:

Palo Alto

• Create an admin role with only:
  • Commit
  • Address objects
  • Security rules (optional)
• Generate an API key

Fortinet

• Create an API admin with:
  • Firewall address
  • Firewall policy
  • System read‑only

Check Point

• Create an API user with:
  • Read access
  • Publish rights
  • Optional: policy install

OPNsense / pfSense

• Create a GUI user
• Assign only required API privileges
• Generate API key/secret

VyOS / Linux

• Create a restricted SSH user
• Allow only specific commands via sudoers

Build the GitHub Action Executor

This is the secure execution layer.

.github/workflows/firewall.yml

yaml

name: Firewall Automation

on:
  workflow_dispatch:
    inputs:
      command:
        description: "Command to run on firewall"
        required: true

jobs:
  run-command:
    runs-on: ubuntu-latest

    steps:
      - name: Install WireGuard
        run: sudo apt-get install -y wireguard

      - name: Configure WireGuard
        run: |
          echo "${{ secrets.WG_CONF }}" > wg0.conf
          sudo wg-quick up ./wg0.conf

      - name: Execute Command
        run: |
          ssh -o StrictHostKeyChecking=no \
              -i <(echo "${{ secrets.FW_SSH_KEY }}") \
              automation@10.10.10.1 \
              "${{ github.event.inputs.command }}"

This works for:

• Palo Alto (via curl API calls)
• Fortinet (via REST API)
• Check Point (via mgmt API)
• OPNsense/pfSense (via API)
• VyOS (via CLI)
• Linux firewalls

Connect Any AI Model

Your AI model becomes the “brain” of the system.

Claude

Best for reasoning, policy validation, and explaining logs.

Gemini

Excellent for structured output and network diagrams.

OpenAI

Strong at generating vendor‑specific API calls.

Local LLMs (Ollama)

Perfect for offline or sensitive environments.

Prompt Template for Any Model

Use this template to keep the AI safe:

You are a network automation assistant.
You generate firewall commands following zero‑trust principles.
Output only the command.
No explanations.
No destructive actions.
Allowed operations:Add temporary rulesModify address objectsQuery system statusRead logs
The command will be executed via GitHub Actions over WireGuard.

Example AI output:

Code

curl -k -X POST https://10.10.10.1/api/v2/cmdb/firewall/address \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"name":"temp-block","subnet":"8.8.8.8/32"}'

How the AI Model Reads Firewall Configuration

For an AI agent to reason about firewall behavior, it first needs a read‑only snapshot of the configuration.
This is done safely — without giving the model write access or admin privileges.

1. Configuration Export Layer

Each firewall vendor provides a way to export or query configuration data:

Palo Alto NetworksXML or REST API (/api/?type=config&action=show)curl -k -u $API_KEY https://fw/api/?type=config&action=showFortinet FortiGateREST API (/api/v2/cmdb/firewall/policy)curl -H "Authorization: Bearer $TOKEN" https://fw/api/v2/cmdb/firewall/policyCheck PointManagement API (show-objects, show-access-rulebase)mgmt_cli show access-rulebase name "Network" --format jsonCisco ASA/FTDREST API or CLI export (show running-config)curl -u admin:pass https://fw/api/configOPNsense / pfSenseBuilt‑in API (/api/firewall/rule/searchRule)curl -u key:secret https://fw/api/firewall/rule/searchRuleVyOS / LinuxSSH read‑only user (sudo vtysh -c "show configuration")ssh readonly@vyos "show configuration"

All these methods return structured data — XML, JSON, or plain text — that can be parsed safely.

Parsing and Normalization

The AI agent never reads raw text directly.
Instead, a parser script converts the configuration into a normalized JSON schema:

json

{
  "interfaces": ["eth0", "eth1"],
  "zones": ["LAN", "WAN"],
  "rules": [
    {"src": "LAN", "dst": "WAN", "action": "allow", "service": "HTTPS"},
    {"src": "LAN", "dst": "Internet", "action": "block", "service": "SSH"}
  ],
  "nat": [{"src": "LAN", "dst": "WAN", "type": "masquerade"}]
}

This schema is then passed to the AI model.

AI Model Interpretation

The AI (Claude, Gemini, OpenAI, or a local LLM) reads the normalized JSON and performs:

• Pattern recognition: Detects redundant or conflicting rules.
• Policy validation: Checks if rules align with zero‑trust principles.
• Optimization: Suggests merging or reordering rules.
• Explanation: Describes why certain rules exist or overlap.

Example prompt to the model:

“Analyze this firewall configuration JSON. Identify redundant rules, missing deny policies, and potential misconfigurations. Output a summary and recommended changes.”

The model’s output is then reviewed by a human or validated by a script before any change is applied.

Security Controls: The Backbone of AI‑Driven Firewall Automation

When AI interacts with network infrastructure, security controls are not optional — they are the foundation.
This section defines how to protect your environment when integrating AI models (Claude, Gemini, OpenAI, local LLMs) with firewalls through GitHub Actions and WireGuard.

1. Zero‑Trust Isolation

Every component operates under least privilege and explicit verification:

• The AI agent never connects directly to the firewall.
• All communication flows through a WireGuard tunnel with mutual key authentication.
• GitHub Actions runners are isolated, ephemeral, and scoped to a single task.
• No inbound ports are exposed; all traffic is outbound‑initiated.

This ensures that even if an AI model or runner is compromised, the firewall remains unreachable from the public internet.

2. Role‑Based Access Control (RBAC)

Each automation user has a minimal privilege profile:

• Read‑only for configuration and observability.
• Write access only for approved rule changes or alias updates.
• No system‑level privileges (no reboot, firmware, or admin operations).
• API keys are scoped per user and rotated automatically.

Vendors like Palo Alto, Fortinet, and OPNsense support granular API roles — use them to enforce separation of duties.

3. Credential Hygiene

Secrets are never hard‑coded or stored in plaintext.

• GitHub Actions uses encrypted secrets vaults for API keys and SSH keys.
• WireGuard private keys are stored in GitHub Secrets, not in workflow files.
• AI models receive redacted configuration data — no passwords, tokens, or VPN secrets.
• Rotate all credentials periodically and revoke unused keys immediately.

4. Command Validation Layer

Before any AI‑generated command executes, it passes through a validation filter:

• Regex and semantic checks block destructive operations (delete all, flush, reboot).
• Allow‑lists define permitted API endpoints or CLI commands.
• Human approval is required for high‑impact actions (rule creation, NAT changes).
• Dry‑run mode simulates execution and logs output without applying changes.

This layer ensures that AI suggestions are interpreted, not blindly executed.

5. Auditability and Logging

Every action is traceable:

• GitHub Actions logs every workflow run, including command, timestamp, and output.
• Firewall audit logs record API calls and configuration changes.
• WireGuard logs connection events and peer activity.
• AI model prompts and outputs are archived for compliance review.

Together, these logs create a complete forensic trail — essential for regulated environments.

6. Data Protection and Privacy

AI models only process non‑sensitive metadata:

• Configuration exports are sanitized before ingestion.
• Threat and traffic logs are anonymized (no IPs or usernames).
• Observability endpoints expose only aggregated metrics.
• Local LLMs can be used for confidential analysis without external data transfer.

This protects both organizational and personal data while maintaining analytical depth.

7. Continuous Security Monitoring

Integrate your AI‑driven automation pipeline with existing SOC tools:

• Forward GitHub audit logs to SIEM (Azure Sentinel, Splunk, Chronicle).
• Monitor WireGuard peer activity for anomalies.
• Use AI itself to detect deviations in configuration baselines.
• Trigger alerts when unauthorized commands or key rotations occur.

Automation doesn’t replace monitoring — it enhances it.

8. Human‑in‑the‑Loop Governance

AI proposes, humans approve, GitHub executes.
This triad keeps control in human hands while leveraging AI’s analytical power.

• Approval workflows in GitHub require manual validation.
• AI suggestions are reviewed by network engineers before merging.
• Policy updates follow change‑management procedures.

Governance ensures that automation remains predictable, auditable, and reversible.

9. Vendor‑Specific Hardening

Each firewall vendor offers unique security features — use them:

• Palo Alto: API key scopes, commit locks, and admin profiles.
• Fortinet: REST API token expiration and role separation.
• Check Point: Session‑based authentication and publish locks.
• OPNsense/pfSense: HTTPS enforcement and per‑user API keys.
• Cisco ASA/FTD: Command authorization sets.

Combine these with your AI pipeline for maximum resilience.

10. Principle of Non‑Persistence

Automation environments should be stateless:

• GitHub runners are destroyed after each job.
• WireGuard peers are temporary and re‑keyed per session.
• AI models operate on ephemeral data snapshots.
• No long‑term storage of configuration or logs outside secure repositories.

This minimizes exposure and ensures clean recovery after every run.

Add Guardrails

AI must never be allowed to:

• Delete all rules
• Disable WAN
• Reset admin credentials
• Install policies without approval
• Reboot the firewall

Add:

• Regex validation
• Allow‑list of commands
• Human approval steps
• Dry‑run mode

Step 6 : Observability for the AI

Expose read‑only endpoints:

• Traffic logs
• Threat logs
• VPN status
• Interface stats
• Routing tables
• NAT tables

The AI can then:

• Detect anomalies
• Suggest rule changes
• Explain traffic spikes
• Identify misconfigurations

Architecture: Secure Observability Flow

This diagram illustrates how telemetry moves safely from the protected segment to the AI Agent.

Conclusion

AI‑assisted firewall automation is not only possible — it’s safe, free, and enterprise‑ready when designed correctly.

By combining:

• AI reasoning
• GitHub Action execution
• WireGuard secure transport
• Least‑privilege firewall access

…you get a modern, zero‑trust automation pipeline that works with any firewall and any AI model.

If you're running a similar setup or have questions, reach out in the comments or on LinkedIn.

— Antonio | AboutCloud

arusso@aboutcloud.io