Your Firewall Vendor's AI Now Grades Its Own Changes. That Is Why Few Use It Daily

All three Leaders in Gartner's 2026 Magic Quadrant for Hybrid Mesh Firewall now sell AI that writes firewall policy or checks a policy change before it is committed. Yet Gartner found that customers are "not yet fully using AI-based orchestration and LLM assistants for everyday firewall administration", according to Redmond Channel Partner's summary of the report. Our read: the gap is not a skills problem. Change-impact analysis has moved inside the vendor's own manager, so the platform being changed now grades its own change, and a change board has good reason not to accept that grade on its own.

The report was published on 7 September 2026. Fortinet, Palo Alto Networks and Check Point were the only three Leaders, with Cisco the sole Visionary. A year earlier, in the first edition, Gartner had predicted that "AI's greatest impact will be automating daily firewall tasks, such as change management and routine policy assessments", as BankInfoSecurity reported. Twelve months on, the features exist and the daily use lags behind.

What the Leaders actually ship for policy changes

Each of the three Leaders, and Cisco from the Visionary corner, now has an AI or analytics feature that sits directly in the policy change path. The wording in their own documentation is close to identical: the tool takes an intent, produces or evaluates a rule, and tells you what the change will do. The table lists what each vendor says, in the vendor's own words.

Vendor (2026 MQ position)	Feature	What the vendor says it does
Fortinet (Leader)	FortiAI-Assist in FortiManager	"Translates operational and security intent into policy changes" and "validates scripts before deployment"
Palo Alto Networks (Leader)	Policy Analyzer in Strata Cloud Manager	Pre-change analysis to "evaluate the impact of a new rule" against the rules that already exist
Check Point (Leader)	Agentic Network Security Orchestration	"Translates intent into policy, delivering one-click Zero Trust posture tightening"
Cisco (Visionary)	Policy Change Impact Analyzer in AgenticOps	Analyzes pending rule changes "and assesses potential traffic impacts"; released 17 September 2026

Fortinet, per SDxCentral and Redmond Channel Partner, plans a unified Model Context Protocol (MCP) framework for AI agent-based automation over the next 12 months. Redmond Channel Partner also reports that all 12 vendors Gartner evaluated offer an LLM chat assistant, at very different levels of maturity. Writing the rule and grading the rule are converging in one console.

Change-impact analysis used to be someone else's job

Firewall change-impact analysis answers one question before a change goes live: what traffic will this rule allow, block or shadow, and does that match the request? For years, many large estates answered it with a tool that did not belong to the firewall vendor. Third-party policy-management suites such as Tufin, AlgoSec and FireMon built their business on reading every vendor's rule base and scoring a proposed change against it. The point was never only multi-vendor coverage. It was that the assessment came from outside the platform being changed.

The vendors have now absorbed that function. Palo Alto's Policy Analyzer checks a new rule for shadows, redundancies and generalisations before commit. Cisco's analyzer looks at pending changes across devices. Fortinet's assistant writes the change and validates it. In each case the same platform, built by the same company, writes or receives the rule, runs the check, and reports the verdict. Nothing in that loop has an interest that differs from the platform's own.

Who should assess the impact of a firewall change?

The impact of a firewall change should be assessed by a party that did not make the change and does not own the platform being changed. That is ordinary control design. NIST SP 800-53 control CM-4 requires organisations to "analyze changes to the system to determine potential security and privacy impacts prior to change implementation", and its discussion assigns that work to personnel with security or privacy responsibilities. Control AC-5 in the same catalogue calls for separation of duties, which its discussion describes as dividing functions among different individuals or roles.

Those controls were written for people. A requester does not approve their own firewall request, and the engineer who implements it does not sign off the verification. Nobody wrote the equivalent rule for tools, because until recently the tool that assessed the change was rarely the tool that made it. When the vendor's AI drafts the rule from your intent and the vendor's analyzer then confirms the rule matches your intent, the four-eyes principle has quietly become two eyes, both owned by the same company.

This is a different question from the one in our earlier piece on AI agents with write access to firewall policy, which asked who signs a change an agent proposes. Here the question sits one step earlier: whose analysis the signer is reading.

Why aren't customers using the AI they already bought?

In our view, customers are not yet using vendor AI for daily firewall administration mainly because a change process cannot accept the output as independent evidence. Gartner, in Redmond Channel Partner's summary, says the low use is "limiting their impact on policy optimization". The usual explanation is that teams lack the skills or the trust. We think the more precise explanation is procedural.

• The change board asks for an impact statement it can rely on. A vendor-generated assessment of a vendor-generated rule is one opinion, not two. Boards that have been through an audit know the difference.
• The evidence has to survive the vendor. If the impact analysis lives only inside the vendor's cloud manager, the record goes with the subscription. That matters at the next migration, and it matters when a change record ends up as legal evidence.
• Mixed estates break the model. Each vendor's analyzer is built around its own rule base. A path that crosses two vendors gets two partial verdicts and no combined one, a gap any multi-vendor estate already knows.

None of this says the vendor tools are wrong. Palo Alto's shadow and redundancy checks are the same class of analysis our rule-analysis methodology describes, and they are useful. The problem is their place in the chain of approval.

Where vendor AI belongs in the change process

Vendor AI fits well at the start of a firewall change and badly at the end. Drafting a rule from a ticket, flagging a duplicate before anyone files a request, cleaning up shadows across a rule base that nobody has touched in years: all of that is preparation, and preparation does not need independence. The approval step does.

Step in the change	Vendor AI is a good fit	Needs an independent check
Translate the request into a draft rule	Yes	No
Spot duplicates and shadows before submission	Yes	No
Impact statement presented to the change board	As input only	Yes
Post-change verification and recertification	As input only	Yes

In practice that means three decisions to write down before anyone switches the features on. First, state in the change policy which assessments must come from a source the vendor does not control, whether that is a second tool, a separate team, or both. Second, export the vendor's analysis into your own change record, so the evidence is yours and outlives the contract. Third, treat AI-drafted rules exactly like human-drafted ones at recertification. A rule nobody remembers asking for is still a rule nobody can justify.

What this means for the next firewall decision

For a decision-maker, the useful conclusion is narrower than "vendor AI is not ready". Vendor AI is ready to do work. It is not positioned to provide assurance, and buying it does not remove the need for an independent check. The independence that third-party policy tools used to provide by default now has to be designed in deliberately. Across hundreds of migrations, the changes that went wrong were rarely the ones nobody checked. They were the ones checked by the same people, with the same assumptions, who wrote them.

That applies directly to procurement. A firewall tender, such as an ASA replacement, should ask each bidder how its AI's impact assessments can be exported, reviewed outside its console, and checked by something it does not own. A vendor that cannot answer has told you where its AI stops being useful to your change board.

Why it matters

Gartner predicted a year ago that change management would be where AI mattered most in firewall operations. The vendors delivered the features, and the customers have not yet put them to full daily use. Reading that as reluctance misses the point. The tools arrived inside the one place a change process cannot take its assurance from, which is the platform under change. Separation of duties has always applied to people. It now has to apply to tools as well, and the organisations that write that rule down first will be the ones that can put the AI to work.

Could your change board show who assessed the impact of last month's firewall changes, and who owns that tool? The free NIS2 Readiness Check walks through the evidence a firewall change process has to produce.