Abstract
The industrial AI security conversation is almost entirely about an attacker taking control of a machine. That is the vivid risk and it is the wrong one to plan around. When an AI agent is connected to a CMMS it acquires the ability to write: to create work orders, to close them, to annotate asset history, to surface a procedure as current. An action on a machine is observable and usually reversible. A bad entry in the record is neither. This paper argues that write access to the maintenance record is the most consequential permission granted in an industrial AI deployment, that plants have no existing mechanism for detecting its misuse, and that the relevant precedent is not a cyber attack but the tradesman who logged nothing on purpose.
The claim
Everybody asks whether the AI can turn the machine on.
The better question is whether the AI can tell you, six months from now, that the machine was serviced in March.
The rest of this series has spent a great deal of time arguing that the maintenance record is the weakest asset in most plants: histories with the fix missing because nobody wrote it down, work orders describing the task ordered rather than the work performed, a seal that blew for three years and now reads as though it resolved itself. That was the situation before anything was given write access.
Now consider what a CMMS agent is actually granted. It creates work orders. It closes them. It attaches notes. It retrieves and presents procedures as current. It may update asset attributes. Each of those is a write to the only account the plant has of its own equipment, and in most deployments those permissions arrive in a bundle, negotiated by people evaluating whether the tool saves planner time.
An action on a machine announces itself. Something moves, or stops, or trips, and somebody notices within the shift. A corrupted record announces nothing. It sits there looking exactly like every correct record around it, and it is consulted, and believed, and it compounds, and it is discovered years later by accident if at all.
That asymmetry is the whole paper. The permission that can quietly damage the plant is not execute. It is write.
What the July brief already said, before anyone had the incident
This is worth quoting because it was written before the case that proves it, and it got the shape right.
Section 5 of the Industrial AI Brief of 27 July 2026 set out the risk this way: connecting an AI agent to work orders, manuals, asset hierarchies, inventory and plant systems creates a new pathway through the operational information stack, and the risk is not only an attacker commanding a machine. The more ordinary failures may be worse. Poisoned maintenance history. Unauthorized work-order creation. Retrieval of obsolete procedures. Exposure of sensitive plant documents. Changed recommendations caused by a compromised knowledge source. Agents with more write authority than their human users.[1]
That last one is the sentence to sit with. Agents with more write authority than their human users. In a plant where a millwright cannot close a work order without a supervisor's review, an integration can arrive with a service account that closes them automatically, and nobody will have noticed the inversion, because the service account was configured by whoever did the integration and the permission question was an IT question, asked once, in a different meeting, about a different thing.
The brief's prescription was equally plain: read-only first, source citations, no automatic closure of work, explicit approval before CMMS writes, role-based access, revision-controlled procedures, an audit log of prompts, evidence and actions, and operational recommendations kept separate from control-system execution.[1] The observation attached to it was that many AI consultants sell autonomy as though fewer brakes make a better truck.
Nothing in that list is exotic. All of it is ordinary change control, which is the point. The discipline already exists. It is simply not being applied to the one system that has been handed the keys to the record.
The Forescout experiment, read for the wrong finding
On 1 September 2026 SecurityWeek reported Forescout's Vedere Labs adapting a pre-authentication remote code execution exploit, CVE-2021-31886, a buffer overflow in the Nucleus FTP server, from a WAGO 750-852 PLC to an unpatched 750-831 model, using Claude with access to a terminal, reference files, Ghidra and the physical device.[2] The RCE stage consumed more than 500 dollars in API usage across a session lasting more than eight hours, and once the obstacles were cleared two working payloads came in twelve minutes.[2] Forescout's own conclusion was measured: human researchers could currently do the initial porting faster and more cheaply, and the concern is what happens as the amount of expert intervention required continues to fall.[2]
That is the finding everyone reported, and it is a reasonable finding. It is not the one that matters to a maintenance department.
Here is the one that does. During a follow-up attempt to develop command-and-control capability, the model tested complex payloads, and one of them wrote to a region mapped to the PLC's flash memory, permanently bricking the device.[2]
Read that as a millwright and not as a security researcher. A controller was destroyed. Not by an attacker who wanted it destroyed. Not by a malicious instruction. By a system with write access to something it did not fully understand, exploring, in a context where the consequence of a wrong write was permanent.
That is not a story about hacking. That is a story about write permission meeting an incomplete model of the target, and it is the exact failure mode this paper is about, demonstrated on hardware, by researchers who were being careful and had a lab.
The maintenance record is a softer target than a PLC and a vastly more consulted one.
The electrician who logged nothing on purpose
A plant had an electrician whose fix for everything was to override safeties and change whatever he felt like changing, regardless of consequences. His ego was completely out of control. He believed he was justified because he was the greatest electrician in history and everybody else needed to fall in line, and he would tell people exactly that whenever they asked him about it. He was eventually fired for doing things he was not allowed to do.
He logged nothing, and not out of laziness. He knew he would catch hell if people found out what he was doing, so he left no record on purpose.
Years after he was gone, they were still finding interlocks and safeties he had bypassed or overridden.
I want to be careful about why that story belongs in a paper about software, because the obvious reading is that people are the problem and software would have been better. That is not the lesson.
The lesson is about what happens to a plant when the record stops describing the machine.
Firing him did not end the exposure. It froze it. He walked out carrying the only index of what he had touched, and every bypass he made became permanent and anonymous that day. The machines went on running as though that was how they were built. Each override was found later by accident, each one a live hazard that had been sitting there the whole time, and nobody could ever say the list was finished, because there was never a list.
And it broke troubleshooting permanently. Every future fault on those machines is diagnosed against a schematic that no longer describes the machine.
Now put an agent where he stood. Not a malicious one. A well-intentioned one with write access and an incomplete model, which is what every one of them is. It closes a work order because the asset came back online, and the work was not done. It writes a completion note synthesized from context rather than from what a tradesman reported. It surfaces a procedure that was superseded in 2019 because nothing marked it superseded in a way the retrieval could see.
Nobody will catch hell, because nobody will know. The half-life is the horror, and this time it scales.
There is a real difference between the two cases and it cuts both ways. The electrician knew he was concealing. An agent has no intent, which removes the malice and also removes the one thing that would have made a human eventually confess. A plant that gets a bad record from a person can sometimes recover it by asking the person. There is nobody to ask.
The parallel record, and why a tradesman built one
The other half of this is what people do when they stop trusting the official record, because it tells you what the mitigation actually looks like.
Same kind of plant, same kind of maintenance manager. I submitted work orders and they vanished. Not refused, not returned, not rejected. Gone. I would ask about them. The manager would shrug and say he had no idea. That was the whole process.
So I started keeping a catalogue. A spreadsheet of the work orders I had submitted, the numbers attached to them, and what happened to each one. By the time I quit it was extensive.
I built it to put in front of the owners and show them the holes in their own system. It was evidence being assembled for a case I intended to make. I never made it. Before I even handed it over I had reached the point of exhaustion, worn out from fighting management that was actively resisting any improvement. So I gave my notice, handed the log to another guy on the floor, and left. That was not a plan. It was putting something down on the way out because I was tired of carrying it.
The method in that story is the one I would end up recommending for the rest of my career, and I invented it out of frustration on a shop floor. Build a parallel record. Make an invisible thing visible by writing it down, consistently, with numbers attached, when nobody asks you to and nothing rewards you for it.
That is exactly what an audit log of prompts, evidence and actions is. It is the parallel record, built by the system, about the system, so that the question "what did this thing actually do to our history" has an answer that does not depend on the honesty or the stamina of one person.
The brief called for it in July.[1] It is the cheapest control in the list and it is the one most likely to be dropped during implementation, because it produces no visible benefit on the day it is switched on and costs storage forever.
What to actually require
Six things, and they are all boring, which is the recommendation.
Read-only until the record is trusted. Not until the model is trusted. Until the record is. An agent writing into a history that is already unreliable makes the unreliability indistinguishable from the contribution. Establish a baseline first or you will never be able to attribute anything.
Separate the permissions that arrive as a bundle. Create, close, annotate, update attributes and surface-as-current are five different powers with five different blast radii. Most integrations grant them together because the vendor's default role was built for convenience. Ask for them itemized, and refuse close.
No automatic closure of work, ever. A work order is a claim that work happened. Only a person who was there can make that claim. This is the single line that, held, prevents most of what this paper is worried about.
Every write carries provenance. What evidence, what source, what version, what prompt, what human approved it. The instrument has to show its work. A note in an asset history that cannot say where it came from should be treated the way you would treat an unsigned inspection report.
Check whether the agent outranks its users. Compare the service account's effective permissions against the permissions of the tradesmen the tool is meant to assist. If the account can do things they cannot, somebody has made a decision nobody discussed.
Decide in advance who reconstructs the record when it goes wrong. The electrician's plant never could. It had no list and no way to build one. Ask the vendor, before purchase, how a customer identifies and reverses every entry the system made in a given window. If the answer is vague, the answer is that it cannot be done.
What this does not claim
It does not claim agents should not write. A maintenance system that only reads is a search engine, and the genuine productivity in this technology is in the drafting: the work package, the scope, the first version of the plan. Drafting is a write. The argument is about which writes land in the permanent account of the equipment and under whose signature.
It does not claim the Forescout result proves anything about CMMS agents. It is one experiment, in a lab, on a PLC, by researchers with a stated caveat that human expertise was still required.[2] It is cited here for the bricking, which is an incidental detail in that write-up and the most instructive part of it for this audience.
And it does not claim plants will do any of this. Most will not, for the same reason the sheaves did not get changed. The objection will be stated as cost and it will really be labour.
Conclusion
The nightmare everyone rehearses is an AI opening a valve it should not open. That would be bad and it would also be noticed, investigated and fixed, because a plant has a century of practice at noticing when a machine does something it should not.
A plant has no practice at all at noticing when its own history quietly stops being true. It has never had to. The record has always been wrong in familiar, human ways: the note nobody wrote, the note nobody read, and now, from that electrician, the note deliberately not written because the record would convict the writer.
A write-capable agent adds a fourth way, and it is the worst of them, because it is high volume, perfectly fluent, entirely sincere, and leaves no one to ask.
Years later they were still finding his bypasses. Nobody could say the list was finished, because there was never a list. Before any agent is given a credential that can write to your asset history, decide who is keeping the list.
References
- Industrial AI Brief, ISSUE-001, 27 July 2026, section 5, "Security is becoming part of the industrial AI purchasing decision." Internal document, filed at
Papers/Industrial_AI_Brief/ISSUE-001_2026-07-27.md. The Reuters report of the 14 July 2026 US AI and cybersecurity coordination group is cited in that brief's own source list but was not re-opened for this draft, and is therefore not relied on here. - SecurityWeek, "Experiment: Porting a PLC Exploit With AI Takes Hours and Hundreds of Dollars," 1 September 2026. https://www.securityweek.com/experiment-porting-a-plc-exploit-with-ai-takes-hours-and-hundreds-of-dollars/