The Agent Can Write Firewall Rules. Who Signs the Change?

In May 2026 the firewall industry quietly crossed a line it had been approaching for two years. Check Point launched an agentic orchestration platform for network security policy: autonomous agents that execute network security operations across enterprise environments without constant human intervention. Tufin, Cato and Cisco have shipped their own versions. The agent no longer suggests the change. It makes it. And every firewall change process in existence was written on the assumption that a human composed the thing being approved.

That assumption is now false, and almost nobody has updated the paperwork that depends on it. This is not an argument against agentic policy management. The vendors have correctly identified a real and expensive problem. It is an argument that the half of the system they automated is not the half that was load-bearing.

What actually shipped

Check Point’s Agentic Network Security Orchestration Platform is built on a network knowledge graph: a live relational model of the customer environment, continuously updated with topology, traffic flows, asset dependencies and real-time configuration data. The stated direction of travel is from thousands of static rules toward intent-based policy, and from fragmented per-vendor management toward a single orchestration layer. Policy Auditor, Policy Insights and AI Assist are generally available; the agent components entered an early availability programme with a broader preview scheduled for the second half of 2026.

The company is refreshingly blunt about the problem it is attacking. A single change request, in its framing, takes two to four weeks to work through analysis, security review and policy dependencies, only to break something else and restart the cycle. Anyone who has sat on a change advisory board recognises that sentence. It is the honest description of firewall change management in a large estate, and it is why the pitch lands.

Cato ships autonomous policy management for firewall-as-a-service. Tufin has a multi-vendor agentic offering. Cisco announced intent-aware agentic inspection alongside its AgenticOps work in February 2026. This is not one vendor experimenting. It is the category moving.

The vendors are right about the problem

The case for agentic policy work is strong on its own terms, and the honest way to evaluate it is to name what the traditional process actually assumed.

Every row in the right-hand column is a governance change, not a technical one. None of them is addressed by a better knowledge graph.

The number that should stop you

The 2026 CISO AI Risk Report from Saviynt and Cybersecurity Insiders surveyed 235 CISOs, CIOs and senior security leaders across the United States and United Kingdom. Only 5 percent felt confident they could contain a compromised AI agent. Ninety-five percent doubted they could detect or contain misuse if it occurred, and 92 percent reported no real visibility into AI identities in their environment at all.

Be precise about what that survey measures: AI identities broadly, not firewall agents specifically. It is not a study of agentic policy management. But it is the closest available read on whether the organisations now being sold write access to their firewall estate believe they could stop an agent that went wrong. The answer is that one in twenty thinks so, and the other nineteen are buying anyway.

Everyone is auditing the proposal. Nobody rebuilt the record.

Read the launch material for any of these products and you will notice that the entire safety argument is about proposal quality. The agent reads the graph. It checks dependencies. It verifies before acting. It shows its work. All of that is genuine engineering and all of it improves the change that gets proposed.

Firewall change management was never primarily about proposal quality. It is an accountability record. Strip it back and it answers four questions: who asked for this, who reviewed it, who approved it, and can that person explain why. Our seven-step change process exists to produce answers to those four questions in a form that survives an audit two years later.

An agent-composed change breaks the fourth question outright. It also erodes the second and third in a way that is easy to miss: the reviewer is now reviewing something they did not write, produced at a rate no human could match, in a system whose reasoning is a derivation rather than an argument. The signature is still collected. What the signature attests to has quietly changed from “I understand this change” to “I did not object to this change.” Those are different controls with the same evidence artefact.

Approval throughput is the real failure mode

One trade appears in none of the launch material. Suppose the agent works exactly as advertised and produces a correct, dependency-checked change in ninety seconds. Your change advisory board still meets on Tuesdays. The two-to-four-week cycle is now a ninety-second proposal followed by a two-week wait, and you have bought nothing.

So the pressure arrives immediately: approve at agent speed. And the only way to approve at agent speed is to reduce what approval means. Every organisation that deploys this will meet that choice in about month three, and most will resolve it by quietly downgrading the review rather than by admitting the throughput gain was never available.

The defensible resolution is to stop treating all changes as one class. Let the agent act autonomously inside a bounded, reversible envelope, and route everything outside that envelope to a real human review that keeps its old meaning. That is the same logic behind zero-trust change controls: the control is proportionate to blast radius, not uniform across every request.

What to write down before you turn one on

• Give the agent its own identity. Not a shared service account, not a borrowed admin credential. It is a non-human identity and needs the same lifecycle, ownership and revocation path as any other.
• Bound the blast radius explicitly. Name the zones, rule bases and object groups it may touch, and treat everything else as out of scope by default rather than by omission.
• Keep a standing never-list that no intent can override. Management-plane access, the deny-all backstop, cross-domain rules. An intent-based system will otherwise find a technically correct route through them.
• Capture reasoning as an artefact, not a log line. The auditor’s question is why, and “the model determined it” is not an answer. Store the intent, the derivation and the graph state at decision time.
• Test rollback on an agent-made change specifically. A rollback rehearsed on human changes proves nothing about a change nobody on the team composed. The rollback path has to be exercised against the new failure mode.
• Name a human per change class. Not per change, which does not scale, and not per platform, which is meaningless. Per class of change, with a real person who owns the outcome.
• Keep drift detection independent of the agent. If the same system both makes changes and reports on them, drift detection has stopped being a control and become a self-assessment.

The conversation is running behind the product

One observation from surveying the last thirty days of practitioner discussion: there is almost none of it on this specific subject. Agents with root, sandboxing untrusted agent code and agent legal personhood all generate real debate. Agents with write access to production firewall policy, shipped by four major vendors, generate close to nothing.

That silence is worth noting rather than filling with invented consensus. The products arrived in May. The governance argument has not started. In this industry that ordering, capability first and control discourse second, is reliably where the next round of incidents comes from.

This is not the same as AI reading your rulebase

Worth separating clearly from the adjacent thing, because they get conflated in vendor conversations. Using a model to analyse and classify an existing rulebase is a read operation. Its worst failure is a wrong recommendation that a human then rejects, and the cost of being wrong is an hour of review time. Write access inverts that: the worst failure is a correct-looking change that reaches production, and the cost is an outage or an exposure. Same underlying technology, entirely different risk class, and the governance one is not a superset of the other.

Why it matters

The firewall change process is one of the few controls that reliably produces evidence auditors accept. It is what a NIS2 evidence pack is built from, and the same records carry weight under DORA and ISO 27001. That evidence has value for one reason: a named human was answerable for each entry, and could be asked to explain it.

Automate the composition without rebuilding the answerability and you have not modernised the control. You have converted an evidence-producing process into a log file, and you will find out which one you have during an audit rather than before it. The agents are coming regardless, and on the merits they should. Rebuild the record first.

Start the free NIS2 Readiness Check →