I spent Wednesday afternoon in Huntsville, Alabama, telling a room full of security personnel seven different ways that the AI they deploy in their network could be used to harm them.
I meant all of it. Forty-five minutes, seven threat modes, and I would give the same talk again tomorrow without softening a word.
Then we got to Q&A, and one question was not about anything I had just said about AI.
Someone in the audience asked about some of the AI hallucinations that I had seen.
I answered by explaining my past few months of striving repeatedly to get AI to do what I actually wanted, including several instances of early efforts when AI came back after a second pass on a task and apologized for being completely wrong in its first answer. I also related the story of an AI agent that blamed me for a document change that it had done itself. I was maybe ninety seconds into this when I realized the mood in the room had changed. More hands went up. The rest of the Q&A session was not about my presentation at all.
I realized, the attendees had not come for another threat briefing. They had come to find out whether anybody had actually managed to deploy AI in an OT network successfully.
Meanwhile, the only conversation the cybersecurity industry is having about AI is the one I gave.
Look at what gets published: Threat research, advisories, vendor warnings, and conference sessions with titles like mine. I contributed to that pile on Wednesday, because the threats are real and somebody has to enumerate them.
But an industry that only publishes fear produces two kinds of people, and neither is going to be any good at dealing with an AI deployment.
The first is paralyzed. He has read enough material to know that AI deployments can be dangerous but not quite enough to know which parts, so he blocks all of it and waits. The second is credulous in the opposite direction. He has also read the threat material, decided it was marketing scare-mongering, and instead approves things without evaluation.
Both of them are downstream of the same knowledge gap – you cannot assess the risk in a technology you have not used. Fear or confidence without fluency makes them both wrong in unpredictable ways.
Each of the seven "Deadly AI Sins" I presented is easily understood if you have seen the harmless version of each sin occur in your own work. An agent that follows your instruction too literally and produces something confidently useless is no different to an AI agent that is intentionally manipulated into causing harm. But if you have seen the benign version enough times, the malign version is not abstract when it arrives.
Fine tuning is the whole job
The least glamorous element was the part that turned the room.
Getting AI to do useful work is not easy or exciting. It is a long, unremarkable loop of writing down what you want, watching the machine do something desired-outcome-adjacent, and then realizing that the gap was in the shortcomings of your specifications, rather than in the model’s understanding.
That’s the work. And you’ll never see it in a sales demo, because the demo you’re shown is the hundredth iteration after the first ninety-nine crapped out.
The maddening thing is also the one thing that makes it valuable. The machine does exactly what you said. It does not do what you meant, or even what you thought you meant. It has no way of noticing the difference, because noticing is not a task you assigned. Every time I have been frustrated with an output, the honest postmortem found the fault in the instructions I gave it.
For anyone who writes technical requirements for a living that can be an uncomfortable education. But it is also the single most transferable skill available right now, and like any skill, you can only get better at it by being very bad at it to begin with. Ask anyone who has ever tried to learn to play a musical instrument. No one is ever Mozart on day 1.
The most fun I have had in twenty-five years
I am running the smallest team of my career. I am also producing more, and more of it is good, than at any point in the past when I had real headcount and a real budget. Those two small team/small budget versus big team/big budget dynamics used to be in tension, and to begin with it makes you question your skills and capabilities. But the more I looked at it, the more I understood that’s not how I should look at it.
There is not more of me. Instead, the distance between imagining something and having it chas ollapsed. For twenty-five years, the greatest constraint on anything I wanted to build was how many people I could put on it and how long I could hold their attention. That constraint is no longer the governing principle. Watching it disipate was genuinely a thrill, and I have not been able to talk about it and make it sound appropriately serious in any meeting since.
I know that a marketer telling you AI is wonderful is worth approximately the square root of nothing. So instead, try it and check for yourself: the loop I described above is tedious but real, and the reason I can describe it in that much detail is that I have spent most of this year slogging through it.
After my session in Ballroom 3
The people in that room are about to be asked to approve autonomous agents on plant floors. Predictive maintenance, optimization, quality control, all of it arriving as a purchase order rather than as an attack. Every agent is a non-human identity with reach into a physical process, and it cannot sit through security awareness training.
The person who evaluates that well is not the one who has read the most threat research. It is the person who has already spent six months finding out what an agent does when the instruction is slightly wrong, before the cost of being wrong is more than a bad paragraph.
After the session I was approached by someone who asked me how he could use AI in his role protecting his company:
Go and play with it. Now. On something that doesn’t matter, before somebody hands you the version that really matters. Set up an automated feed that tracks any new vulnerabilities for any vendors' products that you have deployed in your network. Learn how to make that better every day. Then try the next thing. And the next thing.
The Seven Deadly Sins are all still true. I would give that same presentation again tomorrow. But the people most likely to get this right are the ones enjoying themselves in the moment, and that is not a sentence I expected to be writing at this point in my career.
FAQs
Why aren’t AI threat briefings enough for OT security teams?
Threat briefings can explain how AI systems might be attacked or misused, but they do not give security teams practical experience with how AI actually behaves. OT security professionals need hands-on familiarity with AI agents so they can recognize unexpected behavior, poorly specified instructions, hallucinations, and other problems before AI is deployed in operational environments.
Why should OT cybersecurity professionals gain hands-on experience with AI?
Hands-on experience helps security professionals understand the gap between what an AI system is instructed to do and what the user actually intended. By experimenting with AI on low-risk tasks, teams can learn how agents interpret instructions, make mistakes, and respond to changing requirements before those agents have access to critical OT systems.
What makes AI agents a cybersecurity concern in OT environments?
An AI agent can function as a non-human identity with access to systems, applications, data, or physical processes. In an OT environment, that access could eventually extend to predictive maintenance, process optimization, quality control, and other operational functions. Security teams therefore need to understand both the agent's permissions and how it behaves when instructions are incomplete, incorrect, or manipulated.
How can AI hallucinations help security teams understand AI risk?
Hallucinations and other harmless AI failures provide practical examples of how an AI system can confidently produce an incorrect or unintended result. Experiencing these failures firsthand can make more serious AI security scenarios easier to understand because teams have already observed how unexpected behavior can arise from seemingly ordinary instructions.
What role does fine-tuning or iteration play in using AI effectively?
Effective AI use requires an iterative process: define the desired outcome, evaluate what the AI produces, identify where the instructions were insufficient, and refine them. Repeating this process helps users become better at specifying tasks and recognizing situations where an AI system's output does not match the intended result.
How should OT security teams begin experimenting with AI?
Start with a task where mistakes have little or no operational consequence. For example, build an automated feed that tracks newly disclosed vulnerabilities affecting products deployed in your network. Improve the instructions and results over time, then gradually experiment with additional use cases as your understanding of AI behavior improves.
How To: Build AI Fluency Before Deploying AI in OT
1. Start with a low-risk use case.
Choose an AI task that cannot affect production systems, safety, or physical processes if something goes wrong. The goal is to learn how the technology behaves before giving it meaningful operational authority.
2. Define exactly what you want the AI to do.
Write clear instructions describing the task, expected output, boundaries, and relevant conditions. Avoid assuming the AI will automatically understand what you intended but did not explicitly specify.
3. Review what the AI actually produces.
Compare the output with your intended result. Look for hallucinations, overly literal interpretations, missing information, unexpected actions, and results that are technically responsive but practically useless.
4. Refine the instructions.
Identify where the specification failed to communicate the intended outcome. Update the instructions and run the task again.
5. Repeat the process.
Continue testing, evaluating, and refining. The objective is not simply to obtain a successful result once, but to understand how changes in instructions affect AI behavior.
6. Study harmless failures.
Pay particular attention when the AI behaves unexpectedly. These failures can help security teams recognize how similar behavior could become dangerous when an agent has access to sensitive systems or physical processes.
7. Expand to additional low-risk tasks.
Once one workflow is reliable, experiment with another. Vulnerability monitoring, research feeds, information analysis, and other non-operational workflows can provide practical AI experience without placing OT processes at risk.
8. Apply those lessons before approving operational AI agents.
When AI agents are proposed for predictive maintenance, optimization, quality control, or other plant-floor functions, use the experience gained through lower-risk experimentation to evaluate their instructions, permissions, identities, boundaries, and potential failure modes.
Jaguar Land Rover’s cyberattack shut production for five weeks. The lesson: limit blast radius with network cloaking, segmentation, and verified access to OT.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
Less than 8% of OT and ICS Companies Have Robust AI Deployment, According to new Nozomi Networks and BlastWave-Sponsored Takepoint Research
.svg)
.svg)
