Who this is for: OT security engineers, critical infrastructure operators, ICS/SCADA security teams, compliance officers at utilities and manufacturing facilities, and assessors evaluating AI deployments in operational technology environments.
Joint international guidance. "Principles for the Secure Integration of Artificial Intelligence in Operational Technology" was jointly published by CISA and the Australian Signals Directorate's Australian Cyber Security Centre (ASD ACSC), with endorsement from international partners. It applies to any organization deploying AI systems that interact with, monitor, or control operational technology in critical infrastructure sectors.
Contents
1. Overview 2. The Four Principles 3. The IT/OT Convergence Challenge 4. Principle-to-Procedure Mapping 5. Detailed Procedure Cards 6. Connection to Five Eyes Agentic AI Guidance 7. Quick Reference 8. Quick Start 9. References1. Overview
An auditor walks into your water treatment plant and asks: "You deployed an AI-based anomaly detection system on the SCADA network last quarter. Show me how you verified the AI model's supply chain integrity before it touched a Purdue Level 1 device." You open a spreadsheet. The auditor opens a finding.
This is the evidence gap that CISA's joint guidance with ASD ACSC exposes. Critical infrastructure organizations are deploying AI systems into OT environments -- predictive maintenance on power grids, anomaly detection in water treatment, quality optimization in manufacturing, route planning in transportation -- but the evidence trail that proves these deployments were done securely does not exist in most organizations.
The guidance establishes four principles for secure AI integration in OT. Each principle creates specific evidence obligations. Without cryptographic proof that those obligations were met, organizations are left defending AI-in-OT deployments with policy documents that describe intent, not evidence that proves execution.
Key characteristics of this guidance:
- Scope: Any AI system that interacts with, monitors, or controls operational technology in critical infrastructure
- Joint publication: CISA (United States) + ASD ACSC (Australia) + international partners from the Five Eyes alliance
- Focus areas: Power grids, water treatment, manufacturing, transportation, and other critical infrastructure sectors
- Relationship to existing frameworks: Complements NIST CSF 2.0, NIST AI RMF, and ICS-CERT advisories
- Enforcement mechanism: Sector-specific regulatory requirements (NERC CIP, EPA, TSA Security Directives) reference CISA guidance as baseline expectations
- Companion guidance: Extends the Five Eyes joint statement on agentic AI systems into the OT domain
2. The Four Principles
| Principle | Summary | OT-Specific Concern |
|---|---|---|
| 1. Understand AI-OT system interactions | Maintain a complete inventory of where AI systems touch OT assets, including data flows, decision boundaries, and control interfaces | AI that crosses Purdue model layers without documented authorization creates unmonitored attack surface |
| 2. Apply existing OT security to AI | Extend established OT security controls -- segmentation, access control, monitoring -- to AI components operating in the OT environment | AI models often bypass traditional OT segmentation because they need data from multiple zones |
| 3. Maintain robust data security for AI in OT | Protect the integrity, confidentiality, and availability of data used by AI systems in OT, including training data, inference inputs, and model outputs | Poisoned training data or manipulated sensor inputs can cause AI to issue unsafe control commands |
| 4. Prioritize secure-by-design for AI in OT | Require AI vendors and integrators to build security into AI-OT products from inception, not as an afterthought | Legacy OT devices (15-25 year lifecycles) cannot be patched to accommodate AI security requirements |
3. The IT/OT Convergence Challenge
AI in OT is not the same as AI in IT. The consequences of failure are fundamentally different. A misconfigured AI recommendation engine on a retail website causes a bad product suggestion. A misconfigured AI anomaly detector on a water treatment SCADA system can miss a chemical dosing failure that threatens public health.
Safety vs. Security
OT environments prioritize safety and availability over confidentiality. A traditional IT security posture -- block suspicious traffic, quarantine endpoints, force re-authentication -- can be catastrophic in OT. Blocking a legitimate control signal to "investigate" it can shut down a power grid or halt a manufacturing line. AI systems operating in OT must be witnessed not just for security posture, but for safety impact -- what happens when the AI gets it wrong, and was there a human-reviewable record of what the AI recommended before a control action was taken?
The Purdue Model Boundary
The Purdue Enterprise Reference Architecture defines hierarchical levels from Level 0 (physical process) through Level 5 (enterprise network). AI systems create unique challenges because they inherently need data from multiple levels -- sensor data from Level 0/1, historian data from Level 2/3, and cloud analytics from Level 4/5. Every AI data flow that crosses a Purdue boundary must be inventoried, authorized, and monitored. Most organizations cannot show an auditor which AI models have access to which Purdue levels, let alone prove that access was authorized.
Legacy Device Constraints
OT environments contain devices with 15-25 year operational lifecycles. PLCs, RTUs, and HMIs deployed in 2010 were never designed to interact with AI systems. When AI is layered onto these environments, the legacy devices become part of the AI system's attack surface -- but they cannot be updated, patched, or instrumented. The evidence gap widens: how do you prove an AI system's interaction with a legacy device was safe if the device itself cannot produce telemetry?
4. Principle-to-Procedure Mapping
| CISA Principle | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| 1. Understand AI-OT interactions | HBOM-INV.1 | AI component inventory within OT asset hierarchy | Anchor with component type, OT zone placement, Purdue level, discovery method |
| 1. Understand AI-OT interactions | HBOM-SUPPLY.1 | AI model supply chain provenance for OT-deployed models | Anchor with supplier identity, model origin, integrity hash, chain of custody |
| 1. Understand AI-OT interactions | HBOM-LIFE.1 | AI component lifecycle tracking in OT environment | Anchor with lifecycle stage, deployment date, planned retirement, update history |
| 2. Apply OT security to AI | NHI-CYCLE.1 | Non-human identity lifecycle for AI service accounts in OT | Anchor with credential type, rotation status, zone authorization, expiry |
| 2. Apply OT security to AI | NHI-PRIV.1 | Privilege boundaries for AI identities across Purdue levels | Anchor with privilege scope, zone restrictions, escalation policy, last review |
| 2. Apply OT security to AI | AI-CHAIN.1 | AI decision chain handoff between IT and OT zones | Anchor with source zone, destination zone, handoff type, authorization reference |
| 3. Maintain data security | AI-DRIFT.1 | Model drift detection for OT-deployed AI | Anchor with drift metric, threshold, baseline comparison, sensor data integrity |
| 3. Maintain data security | AI-AUDIT.1 | Audit trail integrity for AI decisions affecting OT processes | Anchor with decision type, audit completeness, tamper detection, retention proof |
| 3. Maintain data security | ADR-EVENT.1 | AI-related OT event recording for incident reconstruction | Anchor with event type, affected assets, timeline position, correlation ID |
| 4. Secure-by-design | AI-HW.1 | Hardware attestation for AI inference in OT environments | Anchor with hardware platform, firmware version, attestation result, enclave status |
| 4. Secure-by-design | AI-SAFE.1 | Safety guardrail verification for AI control recommendations | Anchor with guardrail type, safety check result, override status, human review |
| 4. Secure-by-design | ADR-GRID.1 | AI grid/infrastructure interaction boundaries | Anchor with infrastructure type, interaction scope, boundary enforcement, failsafe status |
5. Detailed Procedure Cards
AI Component Inventory in OT Asset Hierarchy
CISA Principle 1 requires: Organizations must understand every point where AI systems interact with OT assets. This means maintaining a complete inventory of AI components -- models, inference engines, data pipelines, API endpoints -- mapped to their location within the OT architecture, including which Purdue levels they access.
How SWT3 addresses it: The witnessHbomInventory() call mints an anchor each time an AI component is discovered, deployed, or modified within the OT environment. The anchor records the component type, its OT zone placement, the Purdue level it operates at or accesses, and the discovery method (manual audit, automated scan, or deployment pipeline). Over time, these anchors build a cryptographically verifiable inventory that proves the organization knows where its AI systems are.
Query HBOM-INV.1 anchors grouped by Purdue level. Every AI component in your OT environment should have at least one inventory anchor. Cross-reference with your network architecture diagram -- if an AI model accesses Level 2 historian data but has no HBOM-INV.1 anchor documenting that access, the inventory is incomplete. A complete inventory means every AI-OT touchpoint has an anchor.
AI Model Supply Chain Provenance
CISA Principle 1 requires: Organizations must know where their AI models came from before deploying them into OT environments. A model trained on compromised data or delivered through a tampered supply chain can produce unsafe outputs in safety-critical systems.
How SWT3 addresses it: The witnessHbomSupplyChain() call records the supplier identity, model origin (commercial vendor, open-source repository, internal training), integrity hash of the model artifact, and the chain of custody from development to OT deployment. This creates an evidence trail that proves the model was vetted before it was allowed to interact with physical processes.
For each AI model deployed in OT, show a HBOM-SUPPLY.1 anchor with an integrity hash that matches the deployed artifact. The chain of custody should trace back to the original source. If the model was updated, there should be a new HBOM-SUPPLY.1 anchor for each version. Models without supply chain anchors represent unvetted deployments -- a critical finding in OT.
AI Component Lifecycle Tracking
CISA Principle 1 requires: AI components in OT must be tracked through their entire lifecycle -- from initial deployment through updates, retraining, and eventual decommissioning. OT lifecycles are measured in decades, and AI components within those environments must have documented plans for maintenance and retirement.
How SWT3 addresses it: The witnessHbomLifecycle() call records the lifecycle stage (deployed, updated, retrained, deprecated, decommissioned), deployment date, planned retirement date, and update history. This creates a longitudinal record that proves AI components are actively managed, not abandoned in production.
Query HBOM-LIFE.1 anchors for each AI component. The lifecycle stage should reflect current reality. Components with a "deployed" anchor from 18 months ago and no subsequent lifecycle anchors indicate neglected AI assets -- particularly concerning in OT where unmanaged software is a safety risk. Planned retirement dates should align with the OT asset's own lifecycle plan.
AI-Related OT Event Recording
CISA Principle 3 requires: Organizations must maintain audit trails for AI decisions that affect OT processes, with sufficient detail for incident reconstruction. When an AI system influences a control action and something goes wrong, investigators need to reconstruct exactly what the AI recommended, what data it used, and when.
How SWT3 addresses it: The witnessAdrEvent() call records each AI-related OT event with the event type, affected assets, timeline position, and a correlation ID that links related events across the investigation. These anchors form a tamper-evident timeline that incident responders and regulators can use to reconstruct AI-influenced OT events.
During a tabletop exercise or incident review, pull ADR-EVENT.1 anchors by correlation ID to reconstruct the AI decision timeline. Each anchor's timestamp establishes ordering. The affected assets field should match the OT assets involved. If the timeline has gaps -- periods where the AI was active but no events were recorded -- the event recording coverage is insufficient.
AI Grid/Infrastructure Interaction Boundaries
CISA Principle 4 requires: AI systems interacting with grid or infrastructure control systems must operate within defined boundaries. An AI system that can influence physical processes must have enforceable limits on what it can recommend, what it can control directly, and what requires human authorization.
How SWT3 addresses it: The witnessAdrGrid() call records the infrastructure type (power grid, water system, manufacturing line), the interaction scope (read-only monitoring, advisory recommendation, direct control), boundary enforcement status, and failsafe configuration. This proves that AI-infrastructure interaction boundaries are defined and enforced, not just documented in a policy.
ADR-GRID.1 anchors should exist for every AI-infrastructure interaction point. The interaction scope field is critical -- if the AI has direct control capability, the boundary enforcement and failsafe fields must show active safeguards. Advisory-only AI systems should have anchors confirming the scope is limited to recommendations. Any discrepancy between documented scope and actual capability is a high-severity finding.
Non-Human Identity Lifecycle for AI in OT
CISA Principle 2 requires: AI service accounts and machine identities in OT must follow the same lifecycle management as human accounts -- provisioning, rotation, review, and deprovisioning. In practice, AI service accounts in OT environments are often created during initial deployment and never rotated, reviewed, or revoked.
How SWT3 addresses it: The witnessNhiCycle() call records the credential type (API key, certificate, token), rotation status, zone authorization (which OT zones the identity is permitted to access), and credential expiry. This creates evidence that non-human identities are managed with the same rigor as human accounts.
Query NHI-CYCLE.1 anchors filtered by OT zone. Every AI service account should have a lifecycle anchor showing its current rotation status and next scheduled rotation. Credentials that have not been rotated in over 90 days in an OT environment represent stale machine identities -- a common finding. Zone authorization fields should match the network segmentation policy.
AI Identity Privilege Boundaries Across Purdue Levels
CISA Principle 2 requires: AI identities must have privilege boundaries that respect OT network segmentation. An AI model that needs read access to Level 2 historian data should not have write access to Level 1 controllers. Privilege must be scoped to the minimum necessary for the AI function.
How SWT3 addresses it: The witnessNhiPrivilege() call records the privilege scope, zone restrictions (which Purdue levels the identity can access and what operations it can perform), escalation policy (whether the identity can request elevated access), and the date of the last privilege review. This proves that least-privilege principles are applied to AI identities in OT.
NHI-PRIV.1 anchors document the privilege boundary for each AI identity. Cross-reference with NHI-CYCLE.1 anchors to verify that privilege scope matches zone authorization. If an AI identity has broader privilege than its documented zone authorization permits, the privilege boundary is not enforced. Last review dates older than the organization's access review cycle indicate overdue reviews.
Hardware Attestation for AI Inference in OT
CISA Principle 4 requires: AI inference hardware deployed in OT environments must be attested -- the organization must verify that the hardware running AI models is genuine, has not been tampered with, and is running authorized firmware. Counterfeit or compromised inference hardware in an OT environment is a supply chain attack vector.
How SWT3 addresses it: The witnessHardware() call records the hardware platform (GPU, FPGA, edge TPU), firmware version, attestation result (pass/fail from a hardware root of trust), and enclave status (whether the inference runs in a trusted execution environment). This proves that AI inference in OT runs on verified hardware.
AI-HW.1 anchors should exist for every hardware platform running AI inference in the OT environment. The firmware version must match the organization's approved firmware list. Attestation results should be PASS. Edge devices deployed in physically accessible locations (substations, pump stations) are higher priority -- if an attacker can physically access the device, hardware attestation becomes the primary tamper detection mechanism.
Model Drift Detection for OT-Deployed AI
CISA Principle 3 requires: AI models in OT must be monitored for drift -- changes in model behavior that occur after deployment due to shifting data distributions, sensor degradation, or environmental changes. In OT, drift is not just a performance concern; it is a safety concern. A drifted anomaly detection model in a water treatment plant might fail to detect chemical dosing anomalies.
How SWT3 addresses it: The witnessDrift() call records the drift metric (statistical distance, accuracy degradation, output distribution shift), the threshold that defines acceptable drift, the baseline comparison, and sensor data integrity checks. This creates a continuous evidence trail that the model's behavior is being monitored against known-good baselines.
AI-DRIFT.1 anchors should appear at regular intervals for each OT-deployed model. The drift metric should stay below the defined threshold. If anchors show the metric approaching or exceeding the threshold, there should be corresponding ADR-EVENT.1 anchors documenting the response. Gaps in drift monitoring -- periods with no AI-DRIFT.1 anchors -- indicate the model was running unmonitored, a serious finding for safety-critical OT applications.
Safety Guardrail Verification for AI Control Recommendations
CISA Principle 4 requires: AI systems that produce recommendations affecting physical processes must have safety guardrails that prevent unsafe outputs. If an AI system recommends increasing a chemical dosing rate beyond safe limits, the guardrail must catch it before the recommendation reaches the control system.
How SWT3 addresses it: The witnessSafetyGuardrail() call records the guardrail type (range check, physics-based constraint, operational limit), the safety check result (pass/block/override), override status (whether a human overrode the guardrail), and whether human review occurred before the AI recommendation was executed. This proves the safety layer is active and functional.
AI-SAFE.1 anchors with safety check result "block" prove the guardrail is catching unsafe outputs. Anchors with "override" status require corresponding documentation of who authorized the override and why. If all anchors show "pass" over an extended period, consider whether the guardrail thresholds are appropriately calibrated -- a guardrail that never triggers may be set too permissively for the OT environment.
AI Decision Chain Handoff Between IT and OT Zones
CISA Principle 2 requires: When an AI decision or recommendation crosses from an IT zone into an OT zone -- or between OT zones at different Purdue levels -- the handoff must be documented, authorized, and traceable. Untracked cross-zone AI decision flows bypass the segmentation controls that OT security depends on.
How SWT3 addresses it: The witnessChainHandoff() call records the source zone, destination zone, handoff type (data transfer, control recommendation, model update), and authorization reference (the policy or approval that permits this cross-zone flow). This creates a verifiable record of every AI decision that crosses a zone boundary.
AI-CHAIN.1 anchors should exist for every cross-zone AI data flow or decision path. Map these anchors to your network architecture diagram -- every arrow that crosses a Purdue level boundary should have corresponding AI-CHAIN.1 anchors. The authorization reference must point to a valid, current approval. Cross-zone flows without authorization references are undocumented pathways through your OT segmentation.
Audit Trail Integrity for AI Decisions Affecting OT
CISA Principle 3 requires: Audit trails for AI decisions in OT must be complete, tamper-evident, and retained for the duration required by sector-specific regulations. When a regulator investigates an OT incident, the AI decision log must be trustworthy -- not just a text file that anyone with admin access could have modified.
How SWT3 addresses it: The witnessAuditIntegrity() call records the decision type, audit completeness metric (percentage of AI decisions captured), tamper detection status (whether the audit trail's integrity has been verified), and retention proof (evidence that records are being preserved per policy). The cryptographic anchors themselves serve as tamper-evident seals on the audit trail.
AI-AUDIT.1 anchors prove the audit trail is being actively maintained and verified. The audit completeness metric should be at or near 100% -- any gap means AI decisions occurred without being logged. Tamper detection status should consistently show "verified." Cross-reference the retention proof with your sector's retention requirements (NERC CIP: 3 years, EPA: varies by state). Incomplete audit trails in OT are not just compliance gaps -- they are investigation blockers.
6. Connection to Five Eyes Agentic AI Guidance
CISA's AI-in-OT principles complement the broader Five Eyes joint guidance on securing agentic AI systems. Where the agentic AI guidance addresses autonomous AI agents operating across digital environments, the AI-in-OT guidance extends those concerns into the physical domain -- where AI decisions can affect human safety, environmental protection, and critical service availability.
Key intersections between the two guidance documents:
- Identity and access: Both require robust identity management for AI systems. The agentic AI guidance focuses on agent identity in digital workflows; the OT guidance extends this to machine identities crossing Purdue model boundaries (NHI-CYCLE.1, NHI-PRIV.1).
- Decision chain traceability: The agentic AI guidance requires tracing autonomous agent decisions. The OT guidance adds the constraint that decisions crossing IT/OT boundaries must be explicitly authorized and logged (AI-CHAIN.1).
- Safety guardrails: The agentic AI guidance addresses guardrails for autonomous behavior. The OT guidance specifies physics-based and operational safety constraints unique to physical processes (AI-SAFE.1).
- Supply chain integrity: Both emphasize model provenance. The OT guidance adds hardware attestation requirements because OT inference often runs on edge devices in physically accessible locations (AI-HW.1, HBOM-SUPPLY.1).
Organizations deploying agentic AI systems in OT environments should implement both sets of procedures. The CISA Agentic AI Crosswalk covers the agentic-specific procedures; this guide covers the OT-specific procedures. Together, they provide complete evidence coverage for autonomous AI in critical infrastructure.
7. Quick Reference
| Examiner Question | Where to Look |
|---|---|
| Do you know where AI touches your OT environment? | HBOM-INV.1 anchors mapped by Purdue level. Every AI-OT touchpoint should have an inventory anchor. Cross-reference with network architecture diagrams. |
| How did you vet the AI model before OT deployment? | HBOM-SUPPLY.1 anchors showing supplier identity, integrity hash, and chain of custody. The hash should match the deployed artifact. |
| Are AI components actively managed or abandoned? | HBOM-LIFE.1 anchors showing lifecycle stage progression. Components with only a "deployed" anchor and no subsequent updates indicate neglected AI assets. |
| How are AI service accounts managed in OT? | NHI-CYCLE.1 anchors showing rotation status and credential expiry. NHI-PRIV.1 anchors showing privilege scope is limited to required Purdue levels. |
| What happens when AI crosses an OT zone boundary? | AI-CHAIN.1 anchors with source zone, destination zone, and authorization reference. Every cross-zone AI flow should have a corresponding anchor. |
| Is model drift being monitored in OT? | AI-DRIFT.1 anchors at regular intervals. Drift metrics should stay below defined thresholds. Gaps in monitoring indicate unmonitored model operation. |
| Do AI safety guardrails work in your OT environment? | AI-SAFE.1 anchors showing guardrail activation. "Block" results prove the guardrail catches unsafe outputs. "Override" results require human authorization documentation. |
| Can you reconstruct an AI-related OT incident? | ADR-EVENT.1 anchors by correlation ID. AI-AUDIT.1 anchors showing audit completeness near 100% and tamper detection verified. |
| Is AI inference running on verified hardware? | AI-HW.1 anchors with attestation results. Firmware versions should match the approved list. Edge devices in accessible locations are highest priority. |
| What are the AI's boundaries with grid infrastructure? | ADR-GRID.1 anchors showing interaction scope (read-only, advisory, direct control) and failsafe status. Direct control scope requires active boundary enforcement. |
8. Quick Start
pip install swt3-ai
# Initialize with the OT security profile
swt3 init --profile nist-csf --tenant YOUR_TENANT
# Run the demo to see OT-relevant witness anchors
python -m swt3_ai.demo
# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile nist-csf
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
9. References
- CISA -- Principles for the Secure Integration of Artificial Intelligence in Operational Technology -- Joint CISA + ASD ACSC publication
- Australian Signals Directorate -- Australian Cyber Security Centre (ASD ACSC)
- NIST Cybersecurity Framework (CSF) 2.0
- NIST AI Risk Management Framework (AI RMF)
- CISA ICS-CERT -- Industrial Control Systems Cyber Emergency Response Team
- CISA Agentic AI Crosswalk -- Five Eyes joint guidance on securing agentic AI systems
- SWT3 UCT Registry -- 271 procedures across 9 namespaces
- SWT3 Bidirectional Framework Crosswalks -- machine-readable JSON, 77 frameworks
- SDK Documentation -- Python, TypeScript, and 5 additional language SDKs