AI Agent Governance Statistics for Manufacturing Operations
There is currently no verified, manufacturing-specific dataset quantifying AI agent adoption rates, incident counts, or permission misconfigurations in production, quality, or supply chain systems. What is documented is a structural gap: existing OT security frameworks such as IEC 62443 and general frameworks like the NIST AI RMF were not designed to govern autonomous agent tool-call behavior, leaving manufacturers to build agent-specific runtime controls on top of, not in place of, existing ICS security practices.
What the Evidence Actually Supports
Absent verified adoption or incident data, evaluation should be grounded in what is demonstrably true about the current control landscape rather than unverified claims.
No Verified Adoption Figures
No confirmed source quantifies how many manufacturers run autonomous agents against production or OT systems.
Framework Gap
IEC 62443 and NIST AI RMF provide general principles but no manufacturing-specific agent tool-call benchmarks.
Distinct Risk Surface
Agent tool calls introduce access patterns that traditional ICS access control models do not address.
Control-Gap Focus
Governance priority should follow documented control gaps, not unverified incident claims.
Evaluation Criteria for Governance and Runtime Security Solutions
Use the following questions to assess whether a proposed governance or runtime security solution actually addresses agent-specific risk in OT environments, rather than repackaging existing IT access control.
- Does the solution log every tool call and system access an agent makes within OT and ICS environments, in a format suitable for audit review?
- Can permissions be scoped separately for read-only telemetry access versus write or control actions on production and safety systems?
- Does the platform integrate with existing IEC 62443-aligned network segmentation rather than requiring a separate, parallel access-control system?
- Can anomalous or unauthorized tool-call behavior be detected and blocked at runtime, rather than identified only through after-the-fact log review?
- Has the vendor provided independently verifiable evidence of deployment in comparable industrial environments, rather than marketing claims alone?
Where Runtime Governance Fits Relative to Existing OT Controls
A Control Layer, Not a Replacement
Runtime governance for AI agents is not a replacement for ICS security architecture. It is a control layer that sits alongside identity and access management, addressing the gap where OT frameworks stop and agent decision-making begins.
Why This Topic Lacks Reliable Statistics
Manufacturing organizations have adopted AI agents for tasks ranging from production scheduling assistance to quality data analysis, but no independent, methodologically transparent survey currently quantifies how many of these deployments have direct write or control access to operational technology (OT) systems. Vendor-commissioned surveys and marketing materials frequently cite adoption percentages or incident counts without disclosing sample size, methodology, or verification, which makes them unsuitable as a basis for governance decisions. This is a data availability gap, not a definitive marker of a small or large-scale problem. Sound governance planning should be built on documented structural gaps rather than unverifiable figures.
The Framework Gap Between OT Security and Agentic AI
IEC 62443 defines security requirements for industrial automation and control systems, including network segmentation, zone and conduit models, and role-based access. The NIST AI RMF provides a general risk management structure for AI systems, covering governance, mapping, measuring, and managing risk. Neither framework was written with autonomous agent tool-call behavior in mind. IEC 62443 assumes human operators or deterministic software interacting with defined interfaces; it does not address an agent dynamically selecting which system to query or which action to take. The NIST AI RMF addresses AI risk broadly but does not specify manufacturing OT controls, such as how to scope an agent's access to a programmable logic controller or manufacturing execution system. This leaves a real gap between two mature but non-overlapping frameworks, which manufacturers must fill with agent-specific controls.
What the Gap Means in Practice
In practice, this means that a manufacturer following both IEC 62443 and the NIST AI RMF to the letter can still have no formal control over what an AI agent is permitted to do once it has network access to an OT-adjacent system. Compliance with existing frameworks does not equate to agent governance.
Why Tool-Call Access Is a Distinct Risk Category
Traditional ICS access control is built around static roles: a given user or service account is granted a fixed set of permissions, typically reviewed periodically. AI agents behave differently. An agent's specific tool calls in a given session are determined by a model's interpretation of a prompt and available context, which means the exact sequence of system interactions is not fully predictable in advance. This does not mean agents are inherently unsafe, but it does mean that permission models designed for static roles do not naturally extend to dynamic, per-call decision-making. Distinguishing between read-only telemetry access and write or control actions on production and safety systems becomes essential, since the consequences of an unauthorized read differ substantially from those of an unauthorized write.
Operational and Implementation Considerations
Manufacturers evaluating agent governance should treat it as an extension of existing OT security practice rather than a parallel program. Practical considerations include:
- Maintaining a single source of truth for network segmentation, rather than layering a separate access model on top of IEC 62443 zones and conduits.
- Requiring audit logs for agent tool calls that meet the same evidentiary standard used for human operator actions in regulated environments.
- Scoping agent permissions at the level of individual actions, not just system-level access, so read and write operations can be governed independently.
- Requiring runtime enforcement, meaning anomalous behavior is blocked as it occurs, rather than relying solely on retrospective log review.
- Evaluating vendor claims against independently verifiable deployment evidence rather than adoption or incident statistics that cannot be traced to a disclosed methodology.
How Trussed AI Fits This Problem Space
Trussed AI positions its runtime governance layer as a complement to existing OT security investment, not a replacement for it. The premise is that manufacturers already have identity, network segmentation, and access control programs in place; what is missing is a mechanism purpose-built to log, scope, and constrain agent tool-call behavior at runtime, in a way that produces audit-ready evidence and integrates with existing IEC 62443-aligned infrastructure.
Evaluate Runtime Governance Before Expanding Agent Access
Manufacturing enterprises deploying AI agents against production, quality, or supply chain systems should assess permission scope and audit coverage before adoption outpaces control.
Request a Demo