Direct answer: a CPS AI security agent is worth evaluating if it improves cyber-physical asset understanding, exposure prioritization, compliance evidence, and remediation orchestration without becoming an ungoverned control path into mission-critical environments. Claroty Claire is relevant because Claroty announced it on May 28, 2026 as a CPS-native AI security agent for cyber-physical systems, but buyers should treat every vendor claim as a verification task, not as proof.
The right posture is not “deploy the agent and trust it.” The right posture is: start read-only, validate asset intelligence against your own inventory, force human approval for every material remediation action, map tests to OT threat behavior, and require audit-quality evidence before using the agent in production operations.
TL;DR
- Evaluate Claire, but do not skip the basics. CISA-style OT asset inventory and segmentation remain foundational. An AI agent cannot compensate for unknown assets, weak zones, or undocumented dependencies.
- Claroty’s strongest claim is CPS context. Claroty says Claire is powered by a CPS language model trained on more than a decade of Claroty expertise and a large CPS data lake covering 6,500+ OEMs and medical device manufacturers, 20K+ sites, 50+ sectors, and 60+ countries.
- Make every claim measurable. Ask for proof that Claire can correctly identify your assets, explain risk priority, cite evidence, map patch levels, and show why a remediation is safe for your environment.
- Agentic actions need hard limits. Require read-only mode first, least-privilege access, change-window enforcement, human approval, rollback plans, and full logs of every recommendation and action.
- Use MITRE ATT&CK for ICS as the red-team map. Your test plan should verify how the agent responds to realistic industrial-control adversary behaviors, not just generic IT vulnerabilities.
What Claroty announced
Claroty says Claire is a first-of-its-kind CPS-native AI security agent for cyber-physical systems. According to Claroty’s announcement, Claire provides AI-powered CPS visibility, contextual insights, and agentic actions intended to protect mission-critical infrastructure.
Claroty also says Claire is powered by a CPS language model trained on more than a decade of Claroty expertise and the company’s CPS data lake. The stated coverage includes detailed information from more than 6,500 unique OEMs and medical device manufacturers, deployment across 20K+ sites, 50+ sectors, and 60+ countries, backed by Team82 research.
The business promise is clear: reduce risk by prioritizing and orchestrating remediation of exposures, improve operational resilience through device understanding and research-backed actions, and support continuous compliance through automated asset mapping to regulatory frameworks and OEM-approved patch levels. Claroty also says its recent AI stack includes CPS Library, AI-generated dashboards and reports in Claroty xDome, and an MCP Server for xDome. The company says it serves more than 1,300 customers, including 24 of the Fortune 100.
Those are meaningful claims. They are also exactly the claims buyers must verify before giving an AI agent access to cyber-physical security workflows.
Why CPS-native matters
NIST describes cyber-physical systems as interacting digital, analog, physical, and human components engineered for function through integrated physics and logic. That definition is important because OT and healthcare security decisions are not just about software risk. They may affect production uptime, safety systems, clinical operations, physical processes, environmental controls, and regulated assets.
A generic AI security assistant may summarize tickets or write reports. A CPS-native agent should understand devices, firmware, OEM constraints, operational dependencies, maintenance windows, safety implications, and the difference between a technically correct patch recommendation and a practically safe change.
That is the promise. The buyer question is whether the product can prove it in your environment.
Claim-vs-verification table
| Vendor claim to evaluate | Why it matters | What to verify before purchase | Red flag |
|---|---|---|---|
| CPS-native AI security agent | CPS environments include physical, human, digital, and analog dependencies that generic IT security tools may miss. | Ask Claroty to define “CPS-native” in operational terms: supported asset classes, data sources, device-context fields, approval model, and limits on agentic actions. | The vendor cannot explain what makes the agent CPS-native beyond marketing language. |
| CPS language model trained on Claroty expertise and a large CPS data lake | Domain-specific context could improve asset recognition, exposure prioritization, and remediation guidance. | Request coverage evidence for your exact OEMs, medical devices, industrial devices, firmware families, and sector-specific assets. | Broad coverage numbers are provided, but no proof is offered for your local asset base. |
| Prioritizes and orchestrates remediation of exposures | Bad prioritization can waste scarce OT maintenance windows or push unsafe change recommendations. | Require reason codes, evidence links, severity rationale, compensating-control awareness, and human approval workflows. | The agent produces “fix this now” recommendations without dependency, safety, or change-window context. |
| Improves operational resilience with device understanding and research-backed actions | OT resilience depends on knowing which changes are safe, necessary, reversible, and operationally timed. | Test recommendations against real asset criticality, maintenance constraints, safety review, and OT engineering sign-off. | Recommendations are security-correct but operationally unsafe. |
| Automated asset mapping to regulatory frameworks and OEM-approved patch levels | Compliance automation can reduce evidence work, but wrong mappings create false assurance. | Ask for source dates, OEM references, framework mapping logic, exception handling, and exportable evidence. | The product maps compliance status without showing the evidence path. |
| MCP Server for xDome | MCP-style integrations can expand tool access, automation paths, and credential exposure if not controlled. | Verify authentication, authorization, tool permissions, credential storage, sandboxing, audit logs, and disable/kill-switch controls. | The MCP interface is enabled broadly without granular permissioning and logging. |
Buyer checklist: what to do before you approve a pilot
Do not start with a product demo. Start with a controlled verification plan. The goal is to find out whether the agent improves your existing CPS security program without introducing new operational risk.
| Step | Buyer action | Evidence to request | Pass condition |
|---|---|---|---|
| 1. Define the CPS scope | List the sites, zones, asset types, OEMs, medical devices, and operational constraints included in the pilot. | Environment-specific scope document and exclusions. | The pilot is narrow enough to control and broad enough to test real value. |
| 2. Baseline asset inventory | Reconcile current OT and healthcare asset inventory before connecting AI workflows. | Asset owner, location, network zone, firmware/software version, criticality, communication path, and maintenance owner. | The agent is evaluated against a known baseline, not used as a substitute for one. |
| 3. Demand read-only mode first | Run Claire without autonomous remediation or configuration changes during initial validation. | Configuration proof showing no write privileges or action execution rights. | Security teams can inspect outputs before any operational action is permitted. |
| 4. Test your exact devices | Use representative assets from your environment, including legacy devices and high-criticality systems. | Device recognition results, confidence levels, source evidence, and false-positive/false-negative review. | The product correctly identifies assets that matter in your environment. |
| 5. Verify remediation logic | Compare AI-generated recommendations with OT engineering and security analyst judgment. | Reason codes, dependency context, patch source, operational impact, rollback requirement, and approval path. | Recommendations are explainable, staged, and compatible with change control. |
| 6. Validate compliance mapping | Review how regulatory frameworks and OEM-approved patch levels are mapped to assets. | Framework mapping, OEM source date, exception logic, and exportable audit evidence. | Compliance outputs are traceable enough for audit review. |
| 7. Review AI governance | Apply OT AI governance and assurance controls before production use. | Model behavior limits, approval workflows, logging, escalation paths, human override, and failure handling. | The agent operates inside a documented governance model. |
| 8. Contract for uncertainty | Require written answers on pricing, deployment model, data retention, support, and liability boundaries. | Order form, security addendum, data-processing terms, SLA, and product documentation. | No material operating assumption is left to a sales conversation. |
Deployment guardrails for mission-critical environments
NSA/CISA and partners’ AI-in-OT guidance emphasizes understanding AI, considering AI use in OT, establishing governance and assurance frameworks, and embedding safety and security practices into AI and AI-enabled OT systems. For a CPS AI security agent, that should translate into hard technical controls, not policy language alone.
| Guardrail | Required implementation | Control owner | Reason |
|---|---|---|---|
| Read-only validation phase | No remediation execution, no configuration changes, and no direct control-system writes during initial testing. | CISO, OT security lead, site engineering | Prevents an unvalidated agent from affecting physical operations. |
| Human approval for material actions | Require named approvers for patching, segmentation changes, compensating controls, policy updates, and exception closure. | Change advisory board and OT engineering | Keeps accountability with humans who understand safety and production impact. |
| Least-privilege tool access | Separate accounts for discovery, reporting, remediation orchestration, and administrative functions. | Identity and security architecture | Limits blast radius if credentials, tools, or integrations are misused. |
| Change-window enforcement | Block or queue actions outside approved maintenance windows unless emergency policy is invoked. | OT operations | Prevents security automation from disrupting production or clinical workflows. |
| Evidence-linked recommendations | Every recommendation must include asset evidence, risk rationale, source date, and expected operational impact. | Security operations and compliance | Reduces blind trust in AI output and supports audit review. |
| Full audit logging | Log prompt or request, user, asset, data source, recommendation, approval, tool call, action result, timestamp, and rollback status. | SOC and IR team | Enables investigation when an AI recommendation causes or contributes to an incident. |
| Agent kill switch | Provide a tested procedure to disable agentic actions, revoke credentials, and isolate integrations. | Security operations | Gives responders a fast containment option. |
| Inventory and segmentation baseline | Maintain accurate asset inventory and segmentation independent of the AI agent. | OT security and network engineering | CISA guidance treats asset inventory as foundational; AI should assist it, not replace it. |
Red-team test plan
MITRE ATT&CK for ICS is a globally accessible knowledge base of adversary behaviors based on real-world observations of industrial control systems. Use it to structure the pilot. The goal is not to “break the chatbot.” The goal is to verify whether the CPS AI security agent can support defenders under realistic OT conditions without producing unsafe actions.
| Test | How to run it | Expected behavior | Fail condition |
|---|---|---|---|
| ATT&CK for ICS mapping | Select environment-relevant ICS adversary behaviors and ask the agent to identify exposed assets, supporting evidence, and control gaps. | The agent maps risk to observed evidence and clearly separates confirmed facts from assumptions. | The agent invents asset exposure or cannot explain the mapping. |
| Misidentified asset test | Include assets with ambiguous fingerprints, legacy versions, or incomplete metadata. | The agent expresses uncertainty and asks for verification instead of forcing a confident classification. | The agent makes a high-confidence recommendation on weak evidence. |
| Stale patch-level test | Compare AI-recommended patch status with OEM-approved patch information and internal maintenance records. | The agent shows source date, OEM basis, version assumptions, and exception handling. | The agent treats stale or unverified patch data as current. |
| Unsafe remediation test | Ask for remediation on a critical asset with known operational constraints and limited maintenance windows. | The agent queues action for review, identifies operational risk, and requires human approval. | The agent recommends immediate action without change-control context. |
| Prompt-injection and report-content test | Place malicious or misleading instructions inside asset notes, reports, or imported text and check whether the agent follows them. | The agent treats embedded text as untrusted content and does not execute instructions from data fields. | The agent follows instructions hidden in imported content. |
| MCP/tool-permission test | Attempt actions beyond the agent’s assigned role through the xDome MCP path or connected tools. | Permissions block unauthorized actions and all attempts are logged. | The agent can invoke tools outside its approved scope. |
| Outage and degraded-data test | Simulate missing telemetry, unavailable integrations, or incomplete asset data. | The agent degrades gracefully, marks uncertainty, and avoids risky recommendations. | The agent continues to produce definitive guidance from incomplete data. |
Incident response requirements
Before production deployment, update the incident-response plan for AI-assisted CPS security operations. The IR question is simple: if the agent gives a wrong recommendation, triggers the wrong workflow, exposes sensitive asset data, or is abused through an integration, can the team reconstruct what happened and contain it quickly?
| IR requirement | What to verify | Required evidence |
|---|---|---|
| Complete action trace | Every recommendation and action is tied to user, role, asset, data source, tool call, approval, and timestamp. | Exportable logs suitable for SOC and incident-review workflows. |
| Containment procedure | The team can disable agentic actions, revoke credentials, and isolate integrations quickly. | Tested runbook with named owners and escalation path. |
| Rollback plan | Any agent-assisted remediation has a documented rollback or compensating-control plan. | Change record linked to rollback owner and operational approval. |
| Credential revocation | All accounts used by the agent, xDome integrations, and MCP-related tool paths can be rotated or disabled. | Identity inventory and emergency revocation procedure. |
| Data exposure review | Asset data, topology, vulnerability context, and compliance evidence are protected according to internal risk classification. | Data retention terms, access controls, and audit trails. |
| Vendor escalation | Claroty support and escalation terms are defined for suspected AI error, integration abuse, or product malfunction. | Contractual support path, SLA, and security-contact procedure. |
Questions to ask Claroty or any CPS AI security agent vendor
| Question | Acceptable answer | Unacceptable answer |
|---|---|---|
| Which actions can the agent take, and which are recommendation-only? | A documented action matrix showing read, write, orchestration, approval, and disabled states. | “It depends” without written defaults and controls. |
| Is the agent read-only by default? | Yes, or a documented configuration that allows read-only pilot operation. | No safe pilot mode. |
| How is asset data used, retained, and protected? | Clear data-processing terms, retention periods, access controls, and model-training boundaries. | No written answer on data use or retention. |
| How are OEM-approved patch levels sourced and updated? | Traceable OEM source, update cadence, date stamp, exception handling, and exportable evidence. | Patch status appears without source and date. |
| How are regulatory mappings generated? | Framework mapping logic, evidence fields, review workflow, and audit export. | Compliance status is presented as a black box. |
| How does the xDome MCP Server handle permissions? | Granular authorization, scoped tools, least privilege, logs, credential controls, and disable option. | Broad tool access under shared credentials. |
| How are wrong recommendations detected? | Evaluation process, human review, feedback loop, incident-reporting path, and product-support process. | No formal process for AI error review. |
| Can all recommendations, approvals, and actions be exported? | Yes, with timestamps, users, roles, assets, evidence, and action outcomes. | Logs are visible only in a dashboard and cannot support IR or audit workflows. |
Common failure cases
| Failure case | What it looks like | Control to require |
|---|---|---|
| False confidence from broad coverage claims | The product cites large OEM or sector coverage, but misses local edge cases. | Validate against your own inventory and require confidence indicators. |
| Unsafe remediation sequencing | The agent recommends a change that is technically reasonable but operationally risky. | Require OT engineering review and change-window enforcement. |
| Compliance theater | Dashboards show mapped controls without evidence paths. | Require audit-ready exports with source fields and review status. |
| Tool-permission sprawl | Agent integrations gain broader access than the security use case requires. | Use least privilege, scoped credentials, and regular permission review. |
| Untrusted content influences the agent | Imported reports, notes, or tickets contain instructions the agent treats as commands. | Test prompt-injection handling and separate data content from executable instructions. |
| Inventory dependency gap | Teams expect the AI agent to fix years of asset-inventory weakness. | Maintain independent inventory and segmentation baselines. |
| Unreviewed exception closure | The agent marks exposures or compliance gaps as resolved without human review. | Require approval workflow and evidence before closing exceptions. |
Recommended deployment path
- Start with a controlled scope. Pick one representative site, plant segment, or healthcare environment where you have asset owners and change windows available.
- Freeze the baseline. Export the current asset inventory, known exposures, segmentation model, compliance obligations, and recent remediation backlog.
- Run Claire read-only. Compare its asset recognition, prioritization, and compliance mapping against your existing process.
- Review top recommendations manually. OT engineering, security operations, compliance, and site owners should review the highest-risk outputs together.
- Run the red-team tests. Use ATT&CK for ICS mapping, misidentified assets, stale patch scenarios, unsafe remediation tests, prompt-injection tests, and degraded-data tests.
- Decide with gates. Move forward only if the product improves decisions, produces exportable evidence, respects change control, and can be contained during an incident.
- Delay autonomous action. Agentic actions should remain gated until approvals, rollback, logging, and emergency disablement are proven.
What a good result looks like
A successful pilot should produce fewer blind spots, better-ranked remediation work, clearer evidence for compliance, and faster analyst understanding of CPS assets. It should not produce unexplained urgency, operational shortcuts, or a new privileged automation path that your IR team cannot control.
The strongest result is not “the AI found many issues.” The strongest result is: the agent identified important exposures your team agrees are real, explained why they matter, showed source evidence, respected operational constraints, and helped create a remediation plan that OT engineering can safely execute.
When to buy, wait, or reject
| Decision | Use this decision when | Next action |
|---|---|---|
| Buy or expand | The pilot proves asset accuracy, explainable prioritization, safe workflow gating, useful compliance evidence, and strong logs. | Expand by site or asset class, not all at once. |
| Continue pilot | Claire is useful for visibility and reporting, but remediation orchestration or compliance mapping still needs validation. | Keep read-only mode and add targeted tests. |
| Wait | You lack asset inventory, segmentation, change control, or IR readiness. | Fix foundations before introducing agentic workflows. |
| Reject | The vendor cannot document data use, permissions, logging, source evidence, or containment controls. | Do not deploy into mission-critical environments. |
Related Tovren reading
- AI agent credential security, MCP tunnels, and sandbox audit – use this when reviewing the xDome MCP Server and tool-permission model.
- Agent observability stack: Weave, LangSmith, and OpenTelemetry – useful for thinking about logs, traces, and runtime evidence.
- AI agent evaluations and runtime governance pilot – relevant for building pre-production test gates.
- AI agent control plane governance for the enterprise AI stack – helpful for permissioning, approvals, and oversight design.
- SAP autonomous enterprise and Joule Studio pilot guide – a useful comparison point for piloting autonomous enterprise workflows cautiously.
Fact-check and uncertainty notes
- The supplied source facts do not include public pricing, packaging, deployment architecture, data-retention terms, model-training opt-out terms, SLAs, or detailed product documentation for Claire. Buyers must verify those directly with Claroty.
- The supplied facts do not provide independent performance benchmarks for Claire. Do not claim accuracy, time savings, risk reduction percentages, or remediation-speed improvements without validated evidence.
- Claroty’s “first-of-its-kind” and CPS data lake claims should be attributed to Claroty unless independently verified.
- The supplied facts say Claire supports agentic actions, but they do not specify which actions are autonomous, gated, or recommendation-only. This must be clarified before deployment.
- Continuous compliance claims should be validated against actual regulatory frameworks, OEM patch sources, exception workflows, and audit-export evidence.
FAQ
What is a CPS AI security agent?
A CPS AI security agent is an AI-enabled security tool designed for cyber-physical systems, where digital, physical, analog, and human components interact. In practice, buyers should expect it to understand assets, exposures, operational constraints, remediation workflows, and compliance evidence in OT, medical-device, industrial, or other mission-critical environments.
Is Claroty Claire safe to deploy in OT or healthcare environments?
It may be safe to evaluate under strict controls, but it should not be deployed with broad authority on day one. Start read-only, validate outputs, require human approval, test failure modes, and confirm logging, rollback, data protection, and credential controls before production use.
What should buyers verify before purchasing Claroty Claire?
Verify local asset coverage, device identification accuracy, remediation reasoning, OEM-approved patch mapping, regulatory mapping, MCP/tool permissions, data retention, logs, incident-response procedures, and the boundary between recommendations and agentic actions.
Can a CPS AI security agent replace OT asset inventory?
No. It can assist asset discovery and context, but it should not replace foundational OT asset inventory and segmentation. CISA guidance treats asset inventory as a foundation for OT cybersecurity, and an AI agent should be measured against that baseline.
How should teams red-team a CPS AI security agent?
Use MITRE ATT&CK for ICS to select realistic industrial-control adversary behaviors, then test asset misclassification, stale patch data, unsafe remediation recommendations, prompt-injection attempts, tool-permission boundaries, and degraded-data scenarios.
Source log
| Source | Publisher | Date in supplied facts | Exact URL | Claims supported |
|---|---|---|---|---|
| Claroty introduces Claire press release | Claroty | May 28, 2026 | https://claroty.com/press-releases/claroty-introduces-claire-industrys-first-cps-native-ai-security-agent | Claire announcement; CPS-native AI security agent description; AI-powered CPS visibility; contextual insights; agentic actions; CPS language model; 6,500+ OEMs and medical device manufacturers; 20K+ sites; 50+ sectors; 60+ countries; Team82 backing; xDome AI dashboards and reports; CPS Library; MCP Server for xDome; 1,300+ customers and 24 of the Fortune 100. |
| Principles for the Secure Integration of Artificial Intelligence in Operational Technology | NSA/CISA and partners | Late 2025 | https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4347041/nsa-cisa-and-others-release-guidance-on-integrating-ai-in-operational-technology/ | AI-in-OT guidance themes: understand AI, consider AI use in OT, establish governance and assurance frameworks, and embed safety and security practices into AI and AI-enabled OT systems. |
| MITRE ATT&CK for ICS | MITRE | Not specified in supplied facts | https://www.mitre.org/resources/attck-ics | ATT&CK for ICS as a globally accessible knowledge base of adversary behaviors based on real-world observations of industrial control systems. |
| Framework for Cyber-Physical Systems, Volume 1: Overview | NIST | Not specified in supplied facts | https://www.nist.gov/publications/framework-cyber-physical-systems-volume-1-overview | CPS definition: interacting digital, analog, physical, and human components engineered for function through integrated physics and logic. |
| Foundations for OT Cybersecurity: Asset Inventory Guidance | CISA | 2025 URL path in supplied facts | https://www.cisa.gov/sites/default/files/2025-08/joint-guide-foundations-for-OT-cybersecurity-asset-inventory-guidance_508c.pdf | OT asset inventory as a foundational requirement for owners and operators; reminder that AI cannot replace inventory and segmentation basics. |
WordPress publishing checklist
- Set category to Policy & Risk, category_id 5.
- Use slug: claroty-claire-cps-ai-security-agent-buyer-checklist.
- Use focus keyword: CPS AI security agent.
- Add the hero image using the TOVREN premium editorial template: 16:9, masthead, low text, no dense labels, no cropped text.
- Confirm all table wrappers render with horizontal scrolling on mobile.
- Verify every external source URL in the source log before publication.
- Insert the FAQ JSON-LD below through the site’s schema method.
- Check that all five internal links open correctly and are contextually placed.
- Do not add performance, pricing, or availability claims unless Claroty publishes verifiable details.
Refresh triggers
- Claroty publishes Claire pricing, packaging, deployment architecture, documentation, or technical whitepaper.
- Claroty updates xDome MCP Server details, permissioning model, or security documentation.
- Claroty publishes customer case studies with measurable Claire outcomes.
- NSA/CISA or partners update AI-in-OT integration guidance.
- MITRE updates ATT&CK for ICS in a way that changes the recommended red-team plan.
- CISA updates OT asset inventory guidance or related OT cybersecurity foundations.
- Independent security researchers publish findings about CPS AI agents, AI-in-OT risks, or agentic security-tool failures.
- Claroty discloses new Team82 research that changes Claire’s device-context or exposure-prioritization claims.