"Can you allow app-client-01 to reach the database on port 5432?"
That's the simple business need. In many organizations, what follows is complicated: someone opens a ticket, team members exchange questions over email and chat, an engineer gathers information from several systems, performs technical analysis, and eventually logs in to the firewalls to add the rules by hand. Throughout the process, multiple people document the change across several disconnected systems. The request is simple, but the process is manual, slow, and fragmented.
For network automation engineers and ITSM administrators, Red Hat Ansible Automation Platform offers a faster, safer alternative: starting from that same ServiceNow ticket, it orchestrates the entire change—from AI-assisted path analysis to human approval and deployment.
First, an AI model analyzes the network topology and proposes the firewall rules. Next, humans approve the change at 2 defined gates. Then Ansible Automation Platform deploys it through a deterministic execution path. At a high level: AI proposes, humans approve, Ansible Automation Platform orchestrates, validates, and executes.
Red Hat Ansible Automation Platform as the trusted execution layer
The workflow connects 4 systems that normally don't talk to each other: ServiceNow handles requests and approvals, GitHub stores the intended firewall configuration and manages pull requests, a large language model (LLM) analyzes user requests and proposes rules, and 2 Palo Alto Networks firewalls serve as the deployment target. Event-Driven Ansible, a capability of Red Hat Ansible Automation Platform, receives events from ServiceNow and GitHub. Ansible Automation Platform jobs then gather data from the firewalls, call the model, create or update records, and deploy the approved rules. See Figure 1.
Because LLM output is probabilistic, meaning it can produce different results from the same input, it shouldn't be used for execution without validation. Ansible Automation Platform provides a deterministic execution path based on explicit automation logic defined in rulebooks and playbooks, idempotent modules, and controlled state transitions. In this workflow, the AI never connects to a device or accesses credentials. Secrets remain stored in Ansible Automation Platform and are injected only at runtime. Ansible Automation Platform logs every automation job, including who ran it, what actions it performed, and the results. The AI produces structured data that Ansible Automation Platform renders into a reviewable pull request and deploys only after human approval at 2 defined gates.
Event-driven automation triggers each stage
In this workflow, Event-Driven Ansible listens for ServiceNow webhooks and Git pull request state updates to trigger each execution stage automatically.
When an engineer submits a ServiceNow ticket, Event-Driven Ansible captures the payload, checks live firewalls for configuration drift, and opens a GitHub pull request with AI-generated rule recommendations. Once an engineer approves the pull request, Ansible Automation Platform creates the corresponding change request in ServiceNow and updates the Requested Item (RITM) so that ServiceNow reflects the current workflow state. After an administrator approves the change request in ServiceNow, Ansible Automation Platform executes an Ansible playbook to deploy and validate the firewall rules before updating Git and ServiceNow to close out the workflow.
This event-driven approach connects requests, approvals, and execution in real time, eliminating the need for scheduled polling. Ansible Automation Platform carries key variables—such as IP addresses, ticket IDs, and pull request links—from step to step, ensuring every task has the exact data it needs.
Configuration as Code and drift detection
Ansible Automation Platform stores the intended firewall configuration as structured data in the host_vars
directory of the GitHub repository, following a Configuration as Code approach. The main branch represents the last successfully deployed state, while a pull request represents the proposed next state. This gives engineers a chance to review every proposed change in Git before anything touches production. Ansible merges the pull request only after the deployment is verified.
The process follows GitOps principles: changes are proposed in Git, reviewed through pull requests, deployed through automation, and recorded in version control.
Before executing anything, Ansible Automation Platform compares the live firewall configuration with the intended state defined in GitHub. If they don't match, the workflow stops. If no requested change is applied, Ansible Automation Platform records the drift in a ServiceNow work note and closes the ticket. Automation proceeds only from a trusted starting point.
How AI is used in this scenario
AI supports the workflow by analyzing requests, proposing firewall rules, and preparing information for human review by attaching network path analysis and rule rationale directly to ServiceNow tickets, change records, and pull requests. AI doesn't deploy changes. Ansible Automation Platform executes the approved changes only after the required approval gates. Ansible Automation Platform calls the LLM through its API, and the model returns analysis and content:
- Proposes firewall rules: The AI traces the traffic path across firewalls, identifies the relevant security zones, and returns the proposed firewall rules as structured data that Ansible Automation Platform can process.
- Prepares the pull request: The AI attaches the traffic-path analysis and a clear rationale for the proposed change to the pull request. A human reviewer must approve the pull request before the workflow continues.
- Drafts the change record: The AI prepares the ServiceNow change request by summarizing the scope, risk, impact, and rollback plan for Change Advisory Board (CAB) review.
- Updates the request: When no change is required, the AI explains the outcome. For example, this occurs when the traffic is already allowed, the request conflicts with an existing policy, a firewall application ID is not defined, or the network topology can't be determined. Ansible Automation Platform posts this information to the ServiceNow RITM.
The end-to-end workflow
Putting the pieces together, the request moves through the following steps, illustrated in Figure 2:
- The Event-Driven Ansible feature within Ansible Automation Platform detects the ServiceNow request.
- Ansible Automation Platform checks the firewalls for configuration drift.
- Ansible Automation Platform updates the IT Service Management (ITSM) ticket.
- The LLM analyzes the network path and proposes rules.
- Ansible Automation Platform opens a pull request.
- An engineer approves the pull request (human gate 1).
- Ansible Automation Platform creates the ServiceNow change request.
- The Change Advisory Board (CAB) approves the change (human gate 2).
- Ansible Automation Platform deploys the firewall rules.
- If deployment fails, Ansible Automation Platform runs the rollback.
- After successful deployment, Ansible Automation Platform merges the pull request and updates ServiceNow.
Workflow records in ServiceNow and GitHub
The following screenshots show how Ansible Automation Platform keeps the workflow records synchronized across ServiceNow and GitHub. The ServiceNow RITM contains the original connectivity request, while automated work notes track the progress and outcome of the workflow. Ansible Automation Platform also creates a ServiceNow change request and a GitHub pull request, both enriched with analysis and content generated by the LLM. See Figure 3.
The RITM activity stream displays automated status updates and work notes added during the process (Figure 4).
The ServiceNow change request displays automated implementation details generated for CAB review (Figure 5).
The GitHub pull request, as shown in Figure 6, includes the proposed rule syntax and AI-generated rationale.
The demo lab
The demo lab uses Containerlab and includes:
- 2 Palo Alto Networks VM-Series firewalls
- 1 Arista cEOS router
- 2 Linux containers representing an application client and a database server
You can find the implementation of the workflow, including the lab components used in the demo, in the Ansible AIOps Firewall Orchestration GitHub repository. The Containerlab topology definition, infrastructure details, and supporting files reside in the topology
directory.
The lab includes 3 use cases that demonstrate different outcomes:
- Partial coverage: An existing rule already covers part of the PostgreSQL traffic path, so the AI proposes 1 rule on 1 firewall.
- No coverage: No existing rules cover a Secure Shell (SSH) request, so the AI proposes rules on both firewalls.
- Unresolvable request: No corresponding App-ID is defined on the Palo Alto Networks firewalls for the requested port. The workflow stops, and the AI explains in a ServiceNow work note that an engineer must define the App-ID before the request can proceed. App-ID creation could also be automated, but this workflow stops here intentionally.
For more details about the use cases, see the Ansible AIOps Firewall Orchestration GitHub repository.
Extending this architecture beyond firewalls
While this example focuses on Palo Alto Networks firewalls, the same pattern applies anywhere you need AI to analyze intent while Ansible Automation Platform enforces deterministic execution and human approval gates. For example, in access management, an LLM can interpret a new access request, map it to the matching policy, and propose that change in Git, leaving Ansible to deploy it once it is approved.
In each case, Red Hat Ansible Automation Platform acts as the trusted execution layer. It keeps credentials and infrastructure access separate from the AI, enforces approval gates, and applies approved changes through a controlled, deterministic workflow.
Facts Only
Red Hat Ansible Automation Platform orchestrates firewall rule changes.
The workflow integrates ServiceNow, GitHub, a Large Language Model (LLM), and Palo Alto Networks firewalls.
Event-Driven Ansible triggers actions based on ServiceNow webhooks and GitHub pull request updates.
AI analyzes network topology to propose firewall rules and drafts ServiceNow change records.
Humans must approve changes at two gates: a GitHub pull request and a ServiceNow change request.
Ansible Automation Platform executes deployment only after both approvals.
Intended configurations are stored as structured data in GitHub's hostvars directory.
The system compares live firewall configurations against GitHub records to detect drift before execution.
Secrets are stored in Ansible Automation Platform and injected at runtime.
A demo lab utilizes Containerlab with two Palo Alto Networks VM-Series firewalls, one Arista cEOS router, and two Linux containers.
The workflow includes a rollback function if deployment fails.
Executive Summary
Network security updates often suffer from fragmented, manual processes involving disconnected ticketing, chat, and manual firewall configuration. Red Hat Ansible Automation Platform addresses this by integrating IT Service Management (ITSM) and version control into a deterministic execution pipeline. In this model, a Large Language Model (LLM) handles the probabilistic task of analyzing network paths and proposing rules, while Ansible manages the deterministic task of deployment and validation.
The process relies on a "Configuration as Code" approach using GitOps principles, where the intended state is stored in GitHub and verified against live environments to prevent configuration drift. Human oversight is maintained through two mandatory approval gates—one technical review of the code and one administrative review of the change request—ensuring that AI-generated suggestions are validated before implementation. While this architecture specifically demonstrates Palo Alto Networks firewalls, the underlying pattern of AI-assisted intent analysis coupled with automated, gated execution is applicable to various infrastructure management tasks.
Full Take
The strongest version of this narrative is that AI is best utilized as a sophisticated "drafter" rather than a "doer," shifting the human role from manual laborer to strategic validator. By decoupling the probabilistic nature of LLMs from the deterministic requirements of network security, the system creates a safety buffer that prevents AI "hallucinations" from becoming production outages.
However, this is a classic vendor-driven narrative. It frames a common operational pain point—slow ticket processing—as a problem solvable through a specific product ecosystem. The persuasive force relies on the "Authority Game," where the vendor's own architectural design serves as the primary evidence for the efficacy of the solution. It presents a seamless "happy path" that minimizes the potential for AI-generated errors or the complexity of maintaining the integration layer itself.
The underlying paradigm is the move toward "Autonomous Infrastructure," where human agency is relegated to "gates" rather than "creation." While this increases speed, it risks creating a dependency where engineers may lose the deep systemic knowledge required to troubleshoot the network if the automation layer fails. The benefit accrues to the organization in efficiency, but the cost may be a gradual atrophy of manual technical proficiency.
Patterns detected: ARC-0043 Authority Game
Root Cause: The shift toward AIOps necessitates a narrative where AI provides the "intelligence" and the vendor provide the "trust," positioning the product as the essential bridge between the two.
Bridge Questions:
1. If the "human gates" become routine checkboxes due to the perceived reliability of the AI, does the safety mechanism actually persist, or does it become a formality?
2. How does the complexity of managing the automation pipeline compare to the complexity of the manual processes it replaces?
Counterstrike Scan: A coordinated campaign would use "fear of inefficiency" and "AI FOMO" to push a proprietary tool as the only safe way to implement LLMs in infrastructure. The content aligns with this pattern by emphasizing the dangers of probabilistic AI while presenting their specific platform as the sole deterministic cure.
Sentinel — Human
The text reads like a well-structured explanation of a technical automation workflow, exhibiting high coherence and domain-specific detail typical of an expert author, with low synthetic confidence.