When a scanner reports a vulnerability in software used at a factory, the next question should not be only, “What is its severity score?” The team needs to know which asset runs that version, how the flaw could be reached, and whether a fix would affect production or safety.
On October 8, 2026, Anthropic announced the Anthropic Cyber Mission, an effort that starts in two areas: critical infrastructure, including industrial operational technology, and open-source software. The company introduced the Critical Infrastructure Defense Program with a group of security providers, and OSS Scanner for projects that enroll. Anthropic’s announcement
One detail deserves attention: Anthropic says OSS Scanner reports are generated by models and sent to project maintainers without human review. Some reports may be inaccurate, including an incorrect severity rating. The company expects a true-positive rate above 90%, but that is its stated expectation, not a guarantee for every system or organization. The scanner is opt-in for open-source projects, while the critical-infrastructure program is starting with a small cohort of providers. The announcement does not mean that every factory can use these tools today.
The announcement points to a shift in the work. AI may help teams see more potential vulnerabilities sooner. The difficult part then becomes confirming which findings apply to their systems, deciding which risks come first and choosing a response that will not stop a production line or create a safety issue.
A vulnerability in a factory is not an automatic patch order
Operational technology (OT), such as PLCs, HMIs, SCADA, machinery and control networks, interacts with physical processes. Many systems need to run continuously and have limited maintenance windows. NIST’s latest complete guide is SP 800-82 Rev. 3; Revision 4 is still a public draft. The published guide says OT patches should be tested and validated to avoid affecting operational capability or safety. It recommends testing in a separate environment, planning around maintenance windows and preparing recovery plans. NIST’s publication and revision status
Open-source software adds a related supply-chain question. CISA and partner agencies recommend that OT and industrial control system organizations maintain an inventory that identifies open-source components, understand their environment-specific patching process and manage vulnerabilities according to risk. CISA guidance on open-source software in OT/ICS
An AI-generated finding should therefore begin as an item to investigate, not an instruction to change a running system. A manufacturer can adapt this workflow:
- Match the finding to a real asset. Check the product, software version, affected component and system owner against the equipment inventory and software component records. If the version is unknown, mark the match as unconfirmed.
- Ask the model for evidence. Have AI summarize the vendor advisory or vulnerability record with links and supporting passages. Separate what the source says from the model’s inference. Do not treat a model’s severity score as confirmation.
- Have a specialist validate impact. Check which network can reach the asset, what conditions are required for exploitation and whether there is evidence of active exploitation. Test a proposed fix in a representative lab or test device first. Do not experiment on production machinery without an approved plan and owner.
- Prioritize for the plant. Consider exploitability, safety, people, production, product quality, delivery commitments and the time available to act. Standard severity scores help with an initial comparison, but they do not capture the full operating context.
- Choose a response and assign an owner. If a patch can be applied, OT and production teams should set the test window, installation window and rollback plan. If it cannot be installed yet, consider temporary measures supported by the equipment vendor, such as limiting connections or increasing monitoring. Set a review date and name the person responsible for the exception.
AI can help read findings, but should not approve a plant change
A model can misread a vulnerability, match it to the wrong product or suggest a patch that does not fit the equipment version. Factory asset lists, network diagrams, source code and incident logs may also be sensitive operational information. Before sending them to an AI service, review its terms, data handling and access controls.
Keep a record of the source of each finding, who validated it, which asset is affected, who approved a change, and when the work or exception must be reviewed. Security, production and software teams can then make decisions from the same evidence.
Anthropic’s announcement signals investment in defensive cybersecurity tools. It does not show that AI can already make decisions for factory operators. For organizations starting now, the first step is still a trustworthy inventory of assets and software components. Then teams can test AI on summaries and grouping of scan results, with a person checking each recommendation before connecting it to the production change process.
Sources: Anthropic Cyber Mission, Anthropic, October 8, 2026, Guide to Operational Technology Security, NIST SP 800-82 Rev. 3 and Rev. 4 draft status, Improving Security of Open Source Software in OT/ICS, CISA and partners
AI-generated illustration of a fictional factory team reviewing a security report before changing a system. It does not depict actual Enersys or customer personnel, facilities, systems or incidents.
Talk with Enersys about factory systems and operational security
