Quick answer: If you are bringing agentic AI to a plant, refinery, water utility, or any safety-critical industrial site, the first architecture decision should be whether the AI can write to your control systems. The safest, most defensible choice is a read-only architecture that observes, explains, and recommends — and leaves all actuation and final approvals to human operators.
This post explains why read-only matters, what recent regulatory guidance requires, common industrial AI risks, a secure reference architecture, and a practical checklist your team can use when evaluating vendors. Sources include federal OT guidance (CISA and allied agencies), the ISA/IEC 62443 family, and recent industry surveys on AI in OT.
Why this matters now
Regulators and security agencies are treating AI integration in OT as a structural component of cybersecurity posture, not an optional future consideration. In December 2025, joint guidance on integrating AI safely into OT established four principles — understand AI, assess AI use, establish governance and assurance, and embed safety and security practices — and emphasized that LLMs should not make safety decisions autonomously. In April 2026, CISA and federal partners published an OT zero-trust guide adapted to industrial constraints, mapping zero-trust functions to OT realities (zones-and-conduits segmentation, asset inventory, least privilege, and incident playbooks). These documents together create a clear operational expectation: scope AI access, log and monitor it, and ensure human override and containment.
Industry data shows rapid AI interest but limited production deployment: a 2026 survey found that about 87.7% of respondents were evaluating or piloting AI for OT cybersecurity while fewer than 8% had robust multi-function deployments. That gap underscores the need for secure architectures and clear governance before scaling.
What read-only architecture means (and why it limits risk)
Read-only architecture restricts the AI layer to ingesting telemetry, logs, and historian data and returning analysis, explanation, or recommended actions, without any capability to change setpoints, write PLC logic, or issue control commands. The practical consequences are threefold:
- Limits blast radius.If compromised, the agent cannot directly actuate equipment.
- Preserves human authority.Operators remain the final decision-makers for any action that affects safety or production.
- Improves auditability and validation.Observational systems are easier to test, validate, and include in incident response playbooks.
Common AI risks in OT and how read-only mitigates them
AI brings specific failure modes that are particularly concerning in physical systems. Below are the top risks and the read-only control that reduces each one.
| Risk | Why it matters in OT | How read-only helps |
| Prompt injection / data manipulation | Hidden or poisoned inputs can cause dangerous recommendations. | The agent can be isolated, and outputs must be human-reviewed before action. |
| Overconfident hallucinations | LLMs can assert incorrect root causes with convincing language. | Human operators validate recommendations against live telemetry before acting. |
| Excessive permissions | Write-capable agents expand attack surface and risk catastrophic commands. | No write privileges mean a compromised model cannot change setpoints or logic. |
| Data leakage | Sensitive process data could be exposed to third-party services. | On-premise, read-only deployments and explicit egress controls minimize leakage. |
| Broken trust / adoption failure | Operators lose confidence after a few high-impact errors. | Transparent read-only workflows keep humans in the loop and preserve trust. |
Reference secure architecture: key components
A secure, regulator-aligned deployment for agentic AI in OT should include the following elements. Treat this as a minimum baseline, not optional features.
- Read-only access by default; no autonomous writes to PLCs, DCS, or historian records.
- On-premises or air-gapped deployment options for sites that require data sovereignty and low-latency access.
- Network segmentation using an IEC 62443 / zones-and-conduits model to isolate AI processing from control networks.
- Distinct agent identity and credentialing with least-privilege reachability; treat agents like untrusted network endpoints.
- Inline session inspection and operator-custodied session logging so every query and output can be audited.
- Human-in-the-loop approval gates for any high-impact recommendation (HowTo or Step suggestions should be operator-executable only after approval).
- SBOMs and model lineage documentation from the vendor, as recommended by AI-in-OT guidance.
- Incident response playbooks that include AI failure modes: model drift, data poisoning, and disabling an agent quickly without interrupting essential control systems.
Questions every plant team should ask an AI vendor
Use this checklist in procurement and proof-of-concept planning. If a vendor cannot answer these clearly and with documentation, consider it a red flag.
| Question | What to expect in a secure answer |
| Can the product write to control systems, or is it read-only? | Vendor documents architecture; default is read-only; write-enabled features require documented, approved, auditable change requests. |
| Where is data processed and stored (on-prem, cloud, hybrid)? | On-premises or air-gapped options; if cloud used, explicit egress controls and consented data flows. |
| What data leaves the plant and under what governance? | Clear policy, encryption, anonymization, and contractual controls; minimal outbound telemetry. |
| How are credentials and identities managed? | Role-based access, hardware-backed keys where possible, and distinct agent identities. |
| How are prompts, outputs, and operator approvals logged? | Immutable logs retained per retention policy; logs labeled with agent identity and operator reviewer. |
| Do you provide an SBOM and model lineage? | Yes — complete SBOM for software components and clear versions for models with update notification windows. |
| How is the system tested in a simulated OT environment? | Vendor provides test plans, simulated datasets, and evidence of safety testing prior to production rollout. |
| What are failure modes and rollback procedures? | Documented playbooks for disabling agents, rolling back to known-good model checkpoints, and restoring operations without AI. |
| How do you defend against prompt injection and data poisoning? | Input sanitization, provenance checks, and defensive prompt engineering with operator review. |
| Who is responsible for security updates and response SLAs? | Contractual responsibilities, notification windows, and defined RTO/RPO for security incidents. |
AEO / SEO best practices to make this post discoverable
To help this article rank and be surfaced in AI answer engines, use the following on-page patterns in the published post:
- Place a concise “Quick Answer” paragraph beneath the title answering the core query directly (for AI Overviews).
- Include H2/H3 FAQ blocks with short, direct answers (great for featured snippets and AEO results).
- Cite primary sources (CISA, NIST, ISA/IEC 62443, industry surveys) with links to the original documents.
- Add Article and FAQ schema JSON‑LD in the page head for structured indexing.
- Internally link to related Valak blog posts: ‘What Is Agentic AI for Industrial Control Systems?’, ‘Why Lossless Data Fidelity Matters’, and ‘Deploying Agentic AI in an Air-Gapped Plant’.
FAQ
- Q: Can AI agents ever be allowed to write to OT systems?— In specific, audited, and safety-reviewed contexts with strict governance, write-capable integrations can exist, but they should follow explicit change-control processes, multi-person authorization, and exhaustive testing. For initial deployments and pre-production pilots, read-only is the recommended starting point.
- Q: Does read-only mean the AI is less useful?— No. Read-only agents provide high-value insights: faster root-cause analysis, alarm correlation, trend extraction, and procedural guidance. Humans still execute changes, which preserves safety and accountability.
- Q: How does read-only help comply with regulations like 21 CFR Part 11 or IEC 62443?— Read-only architectures simplify validation and audit trails because actions that affect records or product quality remain under controlled human processes; logging, SBOMs, and documented governance align with regulatory expectations.
- Q: What should my first AI-in-OT pilot look like?— A low-risk, high-value use case such as alarm triage, historian search via natural language, or operator Q&A on trends. Deploy read-only on a single cell or non-safety-critical line, validate outputs, build trust, and expand incrementally with governance in place.
Bottom line
Adopting agentic AI in industrial environments is a strategic opportunity to reduce downtime, accelerate diagnosis, and preserve tribal knowledge. But the architecture you choose is a safety decision. Read-only deployments align with current federal guidance, limit operational risk, preserve human authority, and make validation and incident response far easier. Start with read-only, design governance into every phase, and scale only after your team has operational evidence, a tested isolation plan, and contractual assurances from your vendor.
References and further reading
- CISA et al., “Adapting Zero Trust Principles to Operational Technology,” April 29, 2026.
- CISA and international partners, “Principles for the Secure Integration of Artificial Intelligence in Operational Technology,” December 2025.
- ISA, “ISA-TR62443-2-2-2025: Security for Industrial Automation and Control Systems, Part 2-2” (technical report).
- TakePoint / Nozomi Networks / BlastWave, “State of AI in OT Cybersecurity 2026” survey report.
- NIST, NIST Cybersecurity Framework and associated OT guidance references.