OT security for AI deployments

Three of the seven CTO questions in Chapter 4 were security questions in disguise. That wasn’t accidental. Integration architecture and OT security architecture are joined at the hip in oil & gas, and any AI deployment that ignores either one fails the security review or fails the work loop. This chapter is what your security team will actually ask, and what the auditable answers look like.

We write this from the position of having designed for the security review before any customer made it the question. OT security is one of those domains where building the right architecture up front is a fraction of the cost of remediating later, and where shipping product to production-grade operators without it is a non-starter. The wrong AI deployment in an OT environment is a regulatory problem, an insurance problem, and an HSE problem. The right one is none of those. The chapter below is the architecture we built so the answer to every review question is “here it is, in writing.”

IEC 62443, zone-and-conduit in plain language

IEC 62443-3-3 is the standard your CISO will expect any OT-adjacent vendor to align with. Zone-and-conduit is the architecture: every network zone has a defined trust level, and every connection between zones runs through a conduit with explicit ingress and egress rules. The AI platform sits on the IT side of the conduit, consuming a read-only feed of operating data. The control system sits on the OT side, untouched.

The sub-clauses your security team will ask about by name are SR 1.1 (human user identification and authentication), SR 1.4 (identifier management), and SR 1.7 (strength of password-based authentication) under FR 1, plus SR 3.1 (communication integrity) and SR 3.4 (software and information integrity) under FR 3 for the system-integrity controls. Your vendor should be able to map their controls to these sub-clauses without consulting a marketing deck. If the answer is “we’re working toward IEC 62443 alignment,” the conversation should pause until that work is done.

A note on certification vs. alignment. Most vendors in this space claim alignment with IEC 62443, not certification. Alignment is a real thing, an architecture and a control set built to the standard, validated against it. Certification is a paperwork exercise that takes 18 to 24 months and is rarely worth the customer’s time. SOC 2 Type II is the more useful artifact for procurement. Ask for the SOC 2 Type I report under MNDA, and ask for the Type II completion timeline.

Read-only by default, enforced at the network layer

The single most important security claim an AI vendor in oil & gas can make is “read-only.” The single most common failure mode is making that claim weakly. The strong version of read-only is enforced at the network layer: allowlisted endpoints, unidirectional data flow, no return path from the platform to the control system. The weak version is a config flag in the integration server that an admin can flip. The first is a security control. The second is documentation.

Concretely, our platform cannot write setpoints to PLCs, modify production records, issue control commands to field equipment, or override safety interlocks. None of those are options exposed in the application. They are not options exposed at the network edge either. The asymmetry is by design. The platform consumes, ranks, and recommends. The control system, the foreman, and the field crew execute.

Read-only at the application layer is documentation. Read-only at the network layer is a control.

For strictly isolated deployments, an on-premises edge connector sits inside the OT zone, ingests data, and pushes it across an allowlisted unidirectional conduit. Air-gap support means the platform never opens an inbound connection to OT. Operators running a Purdue Level 1 or 2 environment without external connectivity get a deployment shape that matches that constraint, not a workaround.

Single-tenant, BYOK, HYOK, and what cross-tenant means

Single-tenant deployment is the modern default for OT-adjacent AI. Each customer’s operational data lives in its own dedicated environment, with its own infrastructure boundary. The opposite, multi-tenant data pools, is fine for SaaS like a CRM. It is not fine for production data from a 5,000-well operator. Multi-tenancy in this domain creates two failure modes that operators and insurers are right to refuse: data co-mingling that complicates incident response, and shared ML training pools that quietly use your data to improve a model another customer benefits from.

Bring-your-own-key (BYOK) is the default posture WorkSync supports today for customers whose security team requires customer-managed encryption keys. With BYOK, the customer’s KMS holds the master key and the platform requests data encryption keys per session. Hold-your-own-key (HYOK), where the customer’s key never leaves the customer’s environment, is on the 2026 roadmap for customers with sovereign or air-gap key requirements. The platform-managed-keys default is not acceptable for OT-adjacent data, regardless of which posture the customer chooses.

Data residency is a related question. US-East, US-West, and EU regions cover most operators we work with. The right answer to “where does my data live?” is a region name and a cloud provider, not a vague reassurance. Cross-tenant ML training should be explicitly off; your operating data should never train a model another customer sees.

Identity, access, and the audit trail

SSO via SAML or OIDC is the baseline. Okta, Azure AD, Google Workspace, all standard. MFA required for admin roles, not optional. Role-based access control aligned with IEC 62443 SR 1.1 through SR 1.13, with separation between read-only operator roles, configuration roles, and admin roles. Just-in-time privilege elevation for the rare admin operation, with the elevation logged and auto-expiring.

The audit log is the underrated control. Every access event, every config change, every data export, every model run that touched customer data, all logged with user, timestamp, IP, and session ID. Logs are immutable from inside the application, forwarded to the customer’s SIEM if requested, and retained for the contracted period. When a security review asks “how do you reconstruct what your platform did in the 30 minutes around an incident?” the answer is the audit log.

What the security review actually looks like

For a mid-tier operator, the security review takes one to two weeks of elapsed time. Architecture review with the CISO and sometimes a third-party assessor. Walkthrough of the SOC 2 Type I report (Type II if available) under MNDA. Penetration-test executive summary, also under MNDA. The OT integration threat model. The runbook for a security incident, including the customer’s notification window and the platform’s data-handling commitments.

The security team will also test the operational flow. Who can see what? What happens if a credential is compromised? What happens if the platform is compromised? What happens if the operator’s SOC sees suspicious activity originating from the platform? The right answers are pre-written, in a runbook you can hand them. The wrong answers are improvised on the call.

WorkSync designed this security posture preemptively, before any customer review forced the question. The runbook below is what an enterprise OT review typically tests, IEC 62443 alignment, network-layer read-only enforcement, single-tenant deployment, customer-managed encryption keys, immutable audit logs, the operational test scenarios above. We built it that way because that is the standard the next ten customers are going to ask for. Audit-log retention is the policy lever we expect customers to tune to their own requirements; the rest is architecture, not configuration.

The checklist your security team should be running

Take this to your next vendor evaluation. If a vendor cannot answer all of the following affirmatively, the OT security review will fail later, when it’s more expensive.

• ✓IEC 62443 alignment with named SR sub-clauses, not generic "we are 62443-aligned."
• ✓Network-layer enforcement of read-only, with an architecture diagram.
• ✓On-premises edge connector available for air-gap or strictly isolated deployments.
• ✓Single-tenant deployment, with regional data residency options.
• ✓Customer-managed encryption-key custody (BYOK today, HYOK on the 2026 roadmap), with the customer’s KMS as the trust root.
• ✓No cross-tenant ML training, in writing, in the contract.
• ✓SOC 2 Type II audit complete or in observation, with Type I available under MNDA.
• ✓SSO via SAML/OIDC, MFA enforced for admins, RBAC mapped to IEC 62443 SR.
• ✓Immutable audit logs, forwardable to the customer SIEM, with documented retention.
• ✓Pre-written incident runbook, including notification windows and data-handling commitments.

The wrong AI deployment in an OT environment is a regulatory problem. The right one is invisible to the people who write the regulations.

The next chapter, Chapter 6, leaves the plumbing and the OT security behind and looks at the actual upstream use case in depth: the 10⁶⁹⁹ problem, the ranked work plan in the truck cab, and the math that says no human shift could find the optimal answer.