AI adds software surfaces to an already complex environment
OT security discussions have traditionally focused on controllers, engineering workstations, remote access and network segmentation. AI introduces another set of components: model APIs, vector databases, data collectors, agent tools, inference servers and new credentials.
The security question is therefore not simply whether the model is secure. It is what the complete AI-enabled workflow can access and change.
Map the data path first
Document where the model gets information. Does it read historian data? Maintenance tickets? Engineering drawings? Recipes? User-uploaded files?
Then map the action path. Can it only answer questions, or can it create work orders, query a database, send notifications or call a control interface?
This simple inventory often reveals more risk than a long discussion about model providers.
Prompt injection matters in industrial systems too
A retrieval system can expose external text to a language model. If that text contains instructions intended to manipulate the model, the model may interpret those instructions as part of the task.
The practical mitigation is to separate retrieved data from control instructions and to enforce permissions outside the model. A document should never be able to grant a tool permission simply because the model read it.
Credentials should be narrow
An AI service should not have a shared administrator account because “it makes integration easier.” Use narrow service identities and expose only the operations required by the use case.
This is familiar least-privilege engineering. AI does not change that rule; it makes it more important because the toolchain is dynamic.
Logging should include AI actions
Record tool calls, user identity, source documents, relevant model version and important outputs. Engineers need enough information to reconstruct the path from request to action.
Keep the control boundary hard
The strongest general rule is simple: AI should not become an implicit bypass around established PLC, safety, access-control or change-management boundaries.
If an application needs to change a process parameter, the same approval and validation logic that protects the parameter should apply regardless of whether the request came from a human, an API or an AI assistant.
A practical OT AI threat model
- Data poisoning: manipulated or low-quality historical data affects training or recommendations.
- Prompt injection: untrusted content tries to influence agent behaviour.
- Credential abuse: overly broad service identities expand the blast radius.
- Model compromise: an inference endpoint or model supply chain is attacked.
- Tool misuse: a legitimate AI workflow calls a tool in an unsafe context.
The controls are not exotic. Segmentation, identity, least privilege, validation, monitoring and clear interfaces remain the foundation.
Threat modelling should include the full AI chain
An AI application may have a model endpoint, retrieval database, orchestration layer, monitoring service, data collector and several tool integrations. Each component creates a different trust boundary. The model itself is only one part of the attack surface.
Data poisoning is particularly relevant to factories
If a model learns normal process behaviour from historical data, manipulated records can influence what it learns. A sudden flood of incorrect sensor values may create a false baseline, while altered maintenance labels can distort failure analysis.
Controls include source validation, quality checks, provenance and controlled access to training datasets.
Agent tools need explicit permissions
An agent may be allowed to search a historian but not acknowledge alarms. It may draft a work order but not release it. These permissions should be encoded in the tool layer rather than relying on the language model to obey an instruction.
Model confidentiality is another concern
Industrial organisations should consider whether sensitive plant information is being sent to a third-party model provider, stored in prompts, retained in logs or exposed through retrieval systems. Data classification should happen before implementation.
Incident response must include AI services
If an AI endpoint is compromised, the organisation should know how to revoke credentials, disable tool access, isolate the service and continue plant operation without it. AI should have a safe degraded state.
Attack paths often run through the integration layer
The model may be perfectly isolated while the service account behind a connector has excessive privileges. Review the data collector, database credentials, API endpoints and agent tools as carefully as the model runtime.
Make the failure mode boring
If the AI service disappears, the plant should continue according to the established operational logic whenever the use case allows it. A system that simply stops providing advice is much easier to recover than one that leaves control functions in an uncertain state.
Use identity and segmentation as foundations
Industrial AI should inherit the same basic security discipline as other OT services: explicit identities, narrow permissions, segmented network paths, managed secrets and monitored administrative access. The AI layer is not a reason to bypass those controls; it is another reason to apply them consistently.
Review the tool interface like an engineering interface
If a tool can query or change a production system, document its accepted inputs, error states and authorisation rules. Make invalid requests fail explicitly. This mirrors good PLC design: interfaces should be constrained so that unexpected states do not become normal operation.
Security controls must survive model changes
Replacing a model should not silently change which data an application can read or which tools it can call. Keep identity and permission boundaries outside the model so that model upgrades do not become security changes by accident.
Protect the retrieval layer
In a RAG system, the vector store or search index may contain sensitive engineering documents. Access controls need to follow the source-document permissions. A user who cannot open a controlled drawing should not receive its contents through an AI assistant.
Monitor unusual tool behaviour
Agent logs can reveal patterns that traditional application monitoring misses, such as repeated failed tool calls or unexpected query sequences. Treat those events as security signals when appropriate.
Test the safe fallback
Disable the AI service intentionally during a controlled exercise. The team should know exactly which conventional functions continue to work, which dashboards lose enrichment and which workflows require manual handling.
Network architecture still matters
An AI service should not require unrestricted connectivity to every PLC simply because that makes the prototype convenient. Place the model and data services behind appropriate network boundaries, and expose only the information the use case needs.
Review the supply chain
Models, container images, Python packages and external APIs become part of the software supply chain. Keep versions controlled and know which components are deployed in production. An AI system is still software, and software supply-chain hygiene applies.
Security testing should include misuse
Do not test only the normal user question. Try excessive queries, unexpected file uploads, malformed tool requests and attempts to access restricted documents. The point is to understand how the complete system behaves when the user or an external input does something the designer did not intend.