The short version
Writing firewall rules one at a time, in a UI or a CLI, plant by plant, is slow. It takes weeks across a fleet of sites, and the rules drift from what anyone intended.
Security vendors are moving to AI agents to do that work. Fortinet now coordinates agents over the Model Context Protocol (MCP) in its SOC platform, and logs agent activity in FortiOS 8.0 with read and write calls kept apart.
On a control network, two things matter more than speed. The enforcement has to sit on the wire, in front of each machine. And a human has to approve every write.
With Access Gate Performance, your LLM becomes the console. You describe the access you want in plain words. The LLM writes the change. You dry-run it, review it and apply it. Each change lands in the enclave change history, and you can roll it back.
Firewall rules at scale are a people problem.
A single plant is manageable. One engineer knows the network, knows the vendors, and keeps the rule base in their head.
Twenty plants are different. Each one has its own firewall, its own exceptions, and its own history of "temporary" rules. A new vendor needs access to the same type of PLC at every site, and someone has to translate that into twenty rule sets by hand.
The work is repetitive and easy to get wrong. A typo opens a subnet instead of one address. A rule added for a commissioning job is never removed. Six months later, nobody can say why half the rules exist.
The limit is the number of hours a qualified person can spend writing and checking rules. Hiring more of those people is hard, and OT teams are small. That is why the industry is turning to agents.
The industry is moving to agents.
Three signals from this year show the direction.
Fortinet launched FortiSOC in June 2026. The platform uses "Model Context Protocol (MCP)-powered agent coordination across alerts, investigations, threat hunting, cases, and response actions." Fortinet says the agents "recommend or execute response actions under analyst oversight" (Fortinet press release, June 16, 2026).
Fortinet added MCP observability to FortiOS 8.0. Its white paper describes logging that "ties every MCP session and A2A interaction back to a human user." It also distinguishes "between Read methods and Write/Execute methods," so a security team "can allow AI-driven analysis while blocking high-risk AI-driven modifications to production" (Fortinet white paper, Securing the Agentic Enterprise with MCP Observability).
Engineers are building their own connectors. Community-built MCP servers for FortiGate firewalls are on GitHub. They let an LLM read and change firewall configuration directly.
The pattern is the same in all three. An LLM is very good at turning intent into configuration. The open question is what stops a wrong change from reaching production. Fortinet's own answer is to separate reads from writes and to tie every action to a person.
What changes on an OT network.
On an IT network, a bad rule usually means a broken application and a ticket. On a control network, a bad rule can stop an HMI from reaching its PLC, or let a vendor laptop reach a safety system.
So the questions are stricter.
- Where is the rule enforced? A firewall at the plant edge does not see traffic between machines on the same subnet. The rule has to apply in front of each machine.
- Who approves the write? An agent that executes changes on its own is not acceptable near a process. A person reviews and applies every change.
- Can you prove what changed? An auditor asks who changed access to a machine, and when. The answer has to come from a record, not from memory.
- Can you undo it in minutes? If a change breaks a process, the fix is the previous configuration, not a new round of rule writing.
How it works with Access Gate.
Access Gate is an appliance, one per plant, that connects to your existing network and enforces access per machine. Nothing is installed on the machines. Your LLM manages it through admin access to the appliance and to its configuration database, the same access an administrator uses. All the plants are managed from one shared control plane, so a change is prepared and pushed once. You can run a local, self-hosted LLM so the configuration never leaves your site, and give it a scoped or read-only account.
The workflow has four steps.
- Iterate with your LLM. You tell your LLM what you want in plain words, for example "give the packaging line vendor access to the three filler PLCs on line 2," and refine it until it says what you mean. Any LLM or agent tool that can use the admin access works. Claude Code and ChatGPT are two examples.
- Dry-run the config file. The LLM prepares the configuration and runs it as a dry run. You see every rule it would create before anything is applied. Not right? Go back to step one.
- Push the migration. A person reads the proposed change and pushes it. The LLM proposes. The human approves.
- Live. Access Gate enforces it on the wire, in front of each machine it covers. The change shows in the enclave change history: your LLM prepared it, a named person pushed it, and you can roll it back.
The page on firewall rule automation with your LLM walks through the workflow end to end.
What each rule carries.
A rule in Access Gate is more than an allowed port. Each one carries three controls, and a change from your LLM can set all three.
- An access screen. Users authenticate on a splash page before they reach the machine. See authenticate users with access screens.
- Encryption. The connection to the machine is protected with TLS, even when the machine itself has no encryption. See set up TLS encryption.
- A per-machine access control list. Each user reaches only the machines and services the rule names. See access control lists.
These rules live in enclaves, the group of machines and users that Access Gate protects together. The guide to protecting an asset with enclaves shows the model. For administrator and vendor sessions on sensitive machines, add privileged access management.
Four ways to manage rules, compared.
| Rule by rule in a UI or CLI | Vendor AI agent on the firewall | Community MCP server on the firewall | Your LLM with Access Gate Performance | |
|---|---|---|---|---|
| Who writes the change | An engineer, by hand | The vendor's agent | Your LLM | Your LLM |
| Where it is enforced | At the firewall | At the firewall | At the firewall | On the wire, in front of each machine |
| Review before it applies | Peer review, if the team has time | "Under analyst oversight," per Fortinet | Depends on the project | Dry run, then a human approves |
| Record of every change | Firewall logs and tickets | Write calls tied to a user in FortiOS 8.0 | Depends on the project | Enclave change history |
| Undo | Rewrite the rule | Not publicly documented | Depends on the project | Rollback |
| Choice of LLM | Not applicable | Not publicly documented | Yours | Yours, for example Claude Code or ChatGPT |
What it changes in practice.
The time saved is in the writing and the checking. An engineer describes the intent once. The LLM writes one change for every plant, through the shared control plane. The dry run shows exactly what will move. The reviewer reads one proposed change instead of writing hundreds of rules.
The appliance itself is quick to put in. Access Gate is installed in a day per site. At Thales, each deployment took 4 hours from installation to enforcement.
LLM-managed configuration is available today on Access Gate Performance only. It is not part of Access Gate Essential. The Performance edition page lists what else it includes.
Where to start.
Pick one plant and one repetitive task, such as vendor access to a family of PLCs. Describe it to your LLM, run the dry run, and compare the result with the rules you would have written by hand. Then look at the enclave change history and try a rollback before you need one.
The OT firewall rule automation page shows the full workflow. The enclave change history guide shows where each change is recorded.