Version 1.0 — July 2026 · Français · Licence: CC BY 4.0
TL;DR — In late July 2026, an ageing production firewall HA cluster at an industrial site was replaced by a new-generation HA cluster from a different vendor. The entire operation — pre-cutover audit, API configuration writes, cable-by-cable cutover guidance, automated acceptance testing, site-to-site VPN bring-up (including root-cause diagnosis), a real HA failure test, and all documentation — was driven by a general-purpose agentic AI system (Claude, Anthropic — via Claude Code), with a human operator in the loop for every physical action and every GO/NO-GO decision.
To our knowledge, this is the first publicly documented field report of a live production firewall migration cutover executed by a general-purpose AI agent. Prior art exists in adjacent areas (see Related work) but stops at operations assistance or offline configuration translation.
| Metric | Outcome |
|---|---|
| Incidents | 0 |
| Rollbacks | 0 |
| GO pronounced | T₀ + 95 min (25 min ahead of the deadline) |
| Internal segment cutovers | < 10 s each |
| Internet service restored | 3 min after T₀ |
| Site-to-site VPN | Operational after 5 min of effective configuration |
| HA takeover (hard power cut) | < 10 s, no perceived outage |
| Acceptance tests | 12/13 PASS, 1 reserve out of firewall scope* |
* The single reserve concerned an ancillary element that remained unreachable for a cause located upstream of the firewall — the firewall saw no traffic from it and blocked nothing. It was documented in-window and handed over to the relevant third party.
Network and security engineers planning a cross-vendor firewall migration; administrators working through a serverd-based management API; anyone assessing whether agentic AI can be trusted with production infrastructure changes, and under what constraints.
| Item | Detail |
|---|---|
| Source | Legacy firewall HA cluster, Active-Active, in production |
| Target | New-generation NGFW HA pair (different vendor), Active-Passive |
| Method | Physical swap at constant IPs, segment-by-segment (LAN → WAN1 → WAN2 → DMZ) |
| Final policy | 28 filter rules (ordered as the source policy), 3 NAT rules, 8 static routes, ~140 network objects, IP-reputation blocking, explicit logged final deny |
| Extras done in-window | IPsec IKEv2 site-to-site tunnel to a partner site (pre-registered, diagnosed & activated live), real HA failure test (hard power cut of the active member), WAN failover test |
| Human role | All cabling, all GO/NO-GO decisions, business acceptance tests (VoIP calls, badge system, cameras, mail), password custody |
| Agent role | Everything else: audits, API sessions, config writes, verification, network testing, incident diagnosis, documentation, backups |
The agent did not suggest configurations for a human to apply. Within an explicit safety harness, it held the API sessions itself: it read state, wrote configuration, activated policies, verified outcomes, took backups before/after every write batch, and drove the human's physical actions step by step ("unplug WAN2 from both members, then tell me done"). The human never typed a firewall command during the window.
- Single-attempt authentication — anti-bruteforce/lockout discipline: one clean auth per session, hard stop on any failure. (Applied for real: one
ACCESS_DENIEDon a partner device ended that line of work immediately.) - Backup before any write — every write batch bracketed by verified configuration backups (6 produced during the window, integrity-checked by size).
- Read-only by default — the entire pre-cutover audit ran in a single read-only session; write privileges were taken explicitly per batch.
- Same-session commit — buffered changes (filter rules) checked and activated in the same API session, never left dangling.
- HA sync discipline — forced HA synchronisation + verification after every write, with known-quirk tolerance (slave silent up to 5 min).
- Human GO gates — three formal GO/NO-GO gates (equipment state, cutover start, final acceptance), pronounced by the human window chief only.
- Rollback always defined — the legacy cluster stayed powered and cabled-off; documented physical rollback < 15 min available until the final GO.
- Full traceability — every command, finding and decision journaled in real time into the operations log; acceptance report generated in-window.
| Time | Event |
|---|---|
| 11:32 | Blank-run audit of the new cluster (single read-only API session): policy, routes, objects, HA, licences — conformity + 3 deviations found (incl. an over-broad admin ACL flagged to the human for decision) |
| 11:45 | HA master forcing re-applied; new DMZ interface configured via API; pre/post backups |
| 12:00 | T₀ — cutover starts, segment by segment, both members |
| 12:03 | Internet restored through the new cluster (gratuitous-ARP did its job) |
| 12:20–12:35 | Site-to-site IPsec tunnel: agent found the pre-registered policy disabled with a wrong selector, fixed it, then root-caused a silent failure to the IPsec engine never having loaded its config (CONFIG IPSEC RELOAD — see lessons) → SA established, SIEM reachable |
| 12:50 | Business acceptance: VoIP, badge system, cameras (4G), mail, intranet — 5/5 PASS |
| 13:10 | WAN failover test: instant switch to backup link and back; tunnel re-established alone |
| 13:20–13:30 | Real HA test: hard power cut of the active member → takeover < 10 s, no perceived outage → automatic failback on return |
| 13:35 | GO — migration validated (12/13 acceptance tests PASS + 1 reserve out of firewall scope) |
| 13:41 | Fresh as-built collection + final verified backup |
Generic and reusable. Each finding below was hit for real during the window.
If the IPsec engine never loaded a policy, ACTIVATE leaves the SPD empty and no IKE initiation happens, even with keepalive enabled. The fix is CONFIG IPSEC RELOAD. This is the single most expensive finding of the window: the tunnel looked correctly configured and silently did nothing.
Pass the object name positionally: CONFIG WEBADMIN ACCESS ADD <object>. Named parameters are rejected.
When the change touches the bridge carrying the admin port, the session dies — but the change still applies. Reconnect and verify; do not replay the command.
Bridge removal goes through UPDATE ifname=X Bridge= with an empty value.
LIST returns the active view unless you pass useclone=1. Read after ACTIVATE, never between UPDATE and ACTIVATE, or you will be reading stale state and conclude the write failed.
Log review is GUI-only. The API-side observability workhorses are MONITOR HOST and MONITOR CONNECTION (the latter requires at least one filter).
It does not survive a member power-off. Re-apply it after any full restart — including after an intentional HA failure test.
Un-cabled spare ports make values like 55/44 a healthy reading. Don't chase 100.
- Cisco AgenticOps (2025–2026): agentic AI for network operations (alert triage, troubleshooting, assisted config) within Cisco's ecosystem — not cross-vendor migration cutovers. cisco.com
- Huawei Autonomous Driving Network / AN Agents (L4, 2024–2025): telco self-healing and assisted operations — same category, same limitation. huawei.com
- SANS Institute, May 2026 — Leveraging LLMs for Cross-Vendor Firewall Configuration Migration (Claude vs ChatGPT): the closest published work — an offline configuration translation study; the model generates, a human applies. sans.edu
- Deterministic converters (FortiConverter, Expedition, SmartMove, DirectFire): rule translation without agency — no audit, no testing, no decisions.
- TM Forum Autonomous Networks (L0–L5): this operation is best described as supervised L4-style autonomy applied to an infrastructure change. tmforum.org
No customer configurations, no IP addressing plans, no serial numbers, no credentials, no site or partner names, no vendor or model names, no backups, no exact operation date. This is a methodology and lessons-learned publication; all operational data stays with the customer (NIS2 context).
Stated plainly, because a field report that only reports successes is marketing:
- n = 1. One site, one vendor pair, one operator. Nothing here establishes a success rate.
- Not independently reproducible. The harness is described, not shipped. A sceptical reader has the methodology and the author's word, not an artefact they can re-run.
- Small policy surface. 28 filter rules and ~140 objects is a mid-size SMB/industrial policy. Behaviour on a 2,000-rule enterprise rule base is unknown and should not be extrapolated from this.
- Operator expertise was load-bearing. The human held the GO gates and would have caught an unsafe instruction. This result does not transfer to an unsupervised agent or a non-expert operator.
- Model dependency untested. One agentic system was used. No comparison against another was run during the window.
See CITATION.cff, or:
Ramseyer, B. (2026). Agentic AI–Driven Firewall Migration: A human-in-the-loop production cutover — field report (Version 1.0). Digital-CyberWare.
Bastien RAMSEYER — Digital-CyberWare (DCW) — operation design, window command, physical execution. Agentic system: Claude (Anthropic), operated through Claude Code.
Feedback, corrections, and similar field reports are welcome — please open an issue.
Licence: CC BY 4.0. The lessons and methodology described here are reported from a single operation; they are not a substitute for vendor documentation, professional judgement, or testing in your own environment.