Dragos joins Anthropic’s OT defense program for xOT security

At a glance

What this is: Dragos describes joining Anthropic’s Critical Infrastructure Defense Program to extend AI-assisted defense into xOT environments where operational and physical consequences matter.

Why it matters: For security leaders, the signal is that OT defence is moving toward shared, community-informed AI support, which raises new questions about trust, detection quality, and governance across critical infrastructure.

Context

This announcement sits at the intersection of critical infrastructure security, operational technology governance, and AI-assisted defence. xOT environments differ from enterprise IT because availability, safety, and long asset lifecycles dominate the risk model, while patching and reimaging options are often constrained.

Dragos is positioning the program as a collective-defense model rather than a vendor-specific feature story. For practitioners, the important issue is whether AI support is being applied to improve detections, engineering guidance, and shared operational knowledge without creating new trust, dependency, or lifecycle blind spots.

Key questions

Q: How should OT teams govern AI-assisted detections in critical infrastructure?

A: OT teams should treat AI-assisted detections as governed operational controls, not passive analytics. That means defining the trusted data sources, the allowed action scope, the human approval path, and the failure mode if the model is wrong. In xOT, the question is less about model accuracy alone and more about whether the workflow preserves safety, accountability, and uptime.

Q: Why do AI systems create new risk in operational technology environments?

A: AI systems can influence maintenance decisions, monitoring, and control-relevant data flows without fitting traditional user access models. That makes their trust boundary broader than a normal application. If a vendor’s hygiene weakens, the resulting compromise can affect safety, uptime, and the integrity of operational decisions.

Q: What signs show that shared threat intelligence is not working in xOT?

A: Shared threat intelligence is failing when it produces repeated false positives, cannot be mapped to local assets, or is ignored by operators because it lacks process context. In OT, a usable signal must be tied to the environment’s engineering reality. If local teams constantly override the shared detections, the governance model is not aligned to operations.

Q: What should security leaders consider before relying on frontier AI in critical infrastructure?

A: Security leaders should confirm that frontier AI use is bounded by explicit ownership, validation rules, and escalation paths. If the model can influence detection, response, or engineering guidance, the programme needs stronger governance than a normal IT use case. In critical infrastructure, the decisive question is whether the AI layer reduces operational uncertainty or simply adds another opaque dependency.

Technical breakdown

Why xOT security cannot inherit enterprise IT assumptions

Extended operational technology covers the systems that run industrial processes, physical infrastructure, and connected control environments. These environments are not just slower versions of enterprise networks. They contain long-lived assets, safety-critical processes, and maintenance constraints that make standard patch-and-reboot responses unrealistic. That changes how defenders must think about visibility, response speed, and acceptable operational risk. AI can help sift alerts, correlate telemetry, and surface patterns across many sites, but it cannot replace engineering context or asset-specific operational limits. Practical implication: security teams should evaluate whether any AI-enabled defence control respects OT uptime, safety boundaries, and change windows before deployment.

Practical implication: security teams should evaluate whether any AI-enabled defence control respects OT uptime, safety boundaries, and change windows before deployment.

Shared defence models change how threat intelligence is operationalised

Collective defence works when one participant’s observations can improve another participant’s detections without exposing sensitive operational detail. In OT, that usually means anonymised telemetry, shared indicators, and community-tuned detection logic rather than raw environment replication. The value is not simply more data. It is better pattern recognition across systems that individually see only a fragment of the threat landscape. This is especially relevant where adversaries are using AI to accelerate reconnaissance, social engineering, or multi-stage intrusion planning. Practical implication: practitioners should scrutinise how shared intelligence is normalised, governed, and validated before it is allowed to influence detection or response decisions.

Practical implication: practitioners should scrutinise how shared intelligence is normalised, governed, and validated before it is allowed to influence detection or response decisions.

OT AI governance debt: the governance gap is not model use, but model trust

The deeper issue is not whether AI enters the environment. It is whether organisations can govern what the model is allowed to see, infer, recommend, and influence inside a safety-critical workflow. OT programmes already carry governance debt from legacy visibility gaps, asset ambiguity, and fragmented ownership. Adding frontier models can either reduce that debt or hide it behind a more capable interface. The governance question is therefore about accountability, validation, and operational boundaries, not novelty. Practical implication: teams should require explicit control ownership for any AI-assisted detection or guidance workflow used in critical infrastructure.

Practical implication: teams should require explicit control ownership for any AI-assisted detection or guidance workflow used in critical infrastructure.

NHI Mgmt Group analysis

OT defence is now an identity-and-trust problem as much as a network problem. Critical infrastructure security fails when defenders assume enterprise-style visibility and response models will transfer cleanly into xOT. In practice, the control question becomes who and what is trusted to recommend, automate, or influence operational response. That makes governance of AI-assisted workflows and machine identities materially relevant to OT programmes. Practitioners should treat trust boundaries as first-class operational controls.

Collective defence only works when shared intelligence is operationally usable. Shared, anonymised visibility is valuable only if the receiving environment can validate and contextualise it against local process constraints. Otherwise, the programme produces noise or overreach. For OT teams, this means governance over how detections are tuned, when guidance is acted on, and which decisions remain human-owned. Practitioners should demand explainability at the point of action, not just at the point of model output.

Frontier AI in critical infrastructure will widen the gap between capability and governance unless lifecycle controls catch up. The article points to AI being used by attackers, defenders, and internal operators, which means the same model layer can carry multiple risk roles. That creates a lifecycle issue around access, usage boundaries, and accountability across tools and teams. Practitioners should map AI use cases to explicit ownership, permitted actions, and escalation paths before they become embedded in operations.

xOT programmes need a named concept for the control gap: AI governance debt. This describes the accumulated risk created when AI-assisted detection, guidance, or automation is added on top of incomplete OT governance. The debt is paid back through validation, ownership, and operational boundary-setting, not by adopting more AI. Practitioners should assess whether each AI use case reduces or compounds existing xOT blind spots.

The market signal is a shift from isolated product capability toward community-governed operational resilience. The program model implies that critical infrastructure defence is moving toward shared practice, shared detection logic, and shared learning loops. That direction is sensible because no single operator sees enough of the threat landscape alone. Practitioners should evaluate whether their own programme can participate in, consume, and govern such shared defence models without weakening local control.

What this signals

AI governance debt: critical infrastructure teams should expect AI capabilities to arrive faster than the controls needed to govern them. The programme risk is not adoption itself, but unmanaged trust in model outputs that can influence operational decisions.

OT teams need to evaluate AI-assisted detection the same way they evaluate any safety-relevant control: by asking who owns it, what it can change, and how failure is contained when local process reality diverges from the model's assumptions.

For practitioners

• Define AI use boundaries for OT workflows Document where AI may support detection, triage, engineering guidance, or summarisation, and where it must not make or trigger operational changes.
• Map trust ownership across xOT decision paths Assign accountable owners for model inputs, model outputs, and any human or machine action taken on AI-assisted recommendations.
• Validate shared intelligence before operational use Require local testing of community-fed detections against your own asset inventory, process constraints, and false-positive tolerance.
• Separate safety-critical controls from efficiency use cases Keep cost-saving AI uses distinct from functions that can affect physical operations, recovery decisions, or incident escalation.

Key takeaways

• AI is becoming part of critical infrastructure defence, but xOT environments still require safety-aware governance that enterprise IT controls do not provide.
• The practical value of shared defence depends on whether community intelligence can be validated against local process and asset constraints.
• Security leaders should separate efficiency use cases from any AI workflow that could influence physical operations, recovery, or escalation.

Key terms

• Extended Operational Technology: Extended operational technology is the broader set of systems that support industrial and critical infrastructure operations beyond classic plant-floor control networks. It includes connected environments where availability, safety, and long asset lifecycles shape security decisions more than standard enterprise assumptions.
• Collective Defense: Collective defence is a security model where multiple organisations share observations, patterns, or detection knowledge to improve protection across the group. In critical infrastructure, it works best when the shared input is anonymised, operationally validated, and mapped to local process constraints before action is taken.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Safety-Critical Workflow: A safety-critical workflow is any operational process where a wrong or poorly governed decision can affect physical systems, service continuity, or human safety. In OT environments, these workflows require stricter validation, clearer accountability, and tighter change control than ordinary IT processes.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and agentic AI identity. It helps practitioners connect identity control to the broader security decisions that shape resilient programmes.