Industrial AI security guidance is evolving, but factories, warehouses, and connected service operations already have AI-enabled decisions entering real workflows.

That creates a practical gap. A business cannot wait for a future technical report or committee deliverable before deciding what an AI tool may observe, recommend, change, or control.

The constructive response is an interim control overlay: a documented layer of permissions, validation, approval, evidence, monitoring, recovery, and manual fallback applied to every industrial AI use case. It should complement the organization’s existing automation cybersecurity program without claiming compliance with guidance that has not been published.

What changed—and what did not

On October 19, 2026, Automation.com reported that the ISA99 standards committee is expanding its work around industrial automation and control system security.

Documented fact: ISA99 voting members approved Work Group 17 to examine supply-chain requirements affecting industrial automation and control system security. The group is in preliminary formation and is expected to consider responsibilities across suppliers, system integrators, and asset owners.

Documented fact: ISA99 is also investigating whether to form a separate work group addressing the implications of AI for securing automation and control systems. The proposed group’s scope and description are still being developed and remain subject to approval by committee voting members.

What has not happened: The announcement did not publish a new industrial AI security standard, technical report, certification, control catalog, implementation deadline, or conformity claim. It also said the committee is considering how these issues fit within the established ISA/IEC 62443 lifecycle and shared-responsibility framework rather than treating them as unrelated standards topics.

The official ISA99 committee page describes the committee’s existing remit: industrial systems whose compromise could affect safety, regulatory obligations, confidential information, economic performance, or national security. ISA’s public overview of ISA/IEC 62443 confirms that the current series addresses industrial automation and control system security throughout the lifecycle and assigns responsibilities across asset owners, suppliers, integrators, and service providers.

Bridge Road’s interpretation: The committee activity is a useful signal that industrial AI security is becoming a lifecycle and shared-responsibility problem. It is not evidence that a finished AI-specific standard exists. Businesses should define interim controls now, preserve their evidence, and revise the overlay when authoritative guidance matures.

Why an interim overlay matters to an operating business

Industrial AI rarely arrives as a single system with a clean boundary. It may be embedded in machine vision, predictive maintenance, quality inspection, scheduling, energy management, warehouse orchestration, remote support, digital twins, engineering tools, or supplier software. Some tools only summarize data. Others recommend actions, write work orders, change setpoints, issue purchase requests, move inventory, or influence release decisions.

The risk does not come from the model alone. It comes from the complete operating path: sensors and source records, integration services, prompts or policies, model and version, tools and credentials, deterministic logic, human decisions, downstream systems, physical equipment, and recovery procedures.

A model can be accurate in a test and still create operational harm if the wrong data is connected, a service identity is over-permissioned, an output bypasses an interlock, a vendor changes a version without notice, or an operator cannot return to a known manual procedure. That is why Bridge Road’s industrial automation work treats AI as part of a controlled system—not as a detached application.

Build the overlay around the action path

Start by registering every AI-assisted industrial function, including pilots and vendor-embedded features. For each one, document the business purpose, affected process, owner, operator, supplier, system integrator, data sources, model or service, credentials, downstream actions, safety dependencies, and recovery method.

Then classify what the AI can do:

• Observe: read data or create a summary without changing a record;
• Recommend: propose an action that a person must review;
• Prepare: create a draft transaction, work order, schedule, or configuration;
• Execute: perform a bounded action inside deterministic constraints; or
• Influence control: affect equipment, safety, quality release, or production parameters.

Higher levels require stronger validation, narrower permissions, clearer approval, faster monitoring, and a proven rollback or fallback. A chatbot summarizing maintenance history should not inherit the same authority as an agent able to dispatch work, change inventory, or influence equipment.

Keep deterministic controls outside the model

Models can help interpret conditions and generate recommendations, but hard operating limits should remain deterministic. Preserve safety interlocks, engineered limits, quality tolerances, separation of duties, approved routing, transaction thresholds, and state-transition rules outside the model’s discretionary reasoning.

For example, a quality-vision model may flag a product for review, but a separate rule should determine whether a release is permitted. A maintenance agent may draft a work order, but it should not change safety logic or bypass lockout procedures. A warehouse agent may recommend replenishment, but supplier, quantity, price, and authorization limits should be checked by deterministic business rules before a transaction is created.

Record which control blocks an unsafe or invalid action. If the only answer is “the prompt tells the model not to,” the control is not yet strong enough for a consequential workflow.

Use least privilege for data, tools, and physical influence

Create a dedicated identity for each production AI service. Limit it to the minimum records, sites, machines, APIs, commands, and time windows required for its purpose. Separate read, draft, approval, and execution permissions. Do not allow a vendor support account, integration identity, or general-purpose agent to inherit broad access across engineering, production, quality, inventory, ERP, or remote access.

Restrict outbound connections and tool destinations. Use allowlists for approved systems and operations. Make denied actions stop safely and escalate to a named owner; an AI agent should not search for an alternate route when a control blocks the intended path.

Bridge Road’s AI governance practice applies the same principle across business systems: authority belongs to an identity with a defined purpose, not to a model because it appears capable.

Make change control model-aware

Industrial change management should identify more than software version numbers. Record the model and version, system instructions, tools, connectors, retrieval sources, validation dataset, thresholds, deterministic rules, approval design, and permissions that were tested together.

Define which changes require revalidation. A model upgrade, new data source, modified prompt, broader tool permission, new plant, changed product family, revised tolerance, or supplier-side update may alter behavior even when the user interface looks unchanged.

Before deployment, test normal cases, edge cases, stale or missing data, conflicting inputs, unavailable dependencies, malicious content, rejected actions, partial transactions, communication loss, and manual takeover. Preserve the test inputs, expected outcomes, actual outcomes, approver, date, and release decision so the organization can show what was validated.

Require an evidence packet from suppliers and integrators

The newly approved supply-chain work group reinforces a point manufacturers already face: no single party controls the full lifecycle. Ask each supplier and integrator for a practical evidence packet covering:

• product, model, and dependency inventory;
• supported deployment architecture and data flows;
• required identities, permissions, ports, and external services;
• secure-development and vulnerability-handling processes;
• model and software change-notification terms;
• logging, retention, and evidence-export capabilities;
• known operating limits and prohibited uses;
• incident-notification and escalation contacts;
• rollback, supported-version, and end-of-support procedures; and
• responsibility for validation, monitoring, recovery, and customer communication.

Supplier documentation is evidence to evaluate, not an automatic approval. The asset owner still decides whether the system’s access and consequence are acceptable in the real operating environment.

Define monitoring and incident ownership before production

Log inputs, source versions, model or service version, requested actions, tool calls, deterministic validation results, approvals, completed transactions, exceptions, reversals, and operator interventions. Monitoring should detect both prohibited actions and unusual allowed behavior, such as a sudden rise in recommendations, repeated rejected commands, activity outside production windows, or new destinations.

Assign an owner for each exception class. Operations may own continuity, engineering the equipment boundary, quality the release decision, IT the identity and integration path, security the investigation, and the supplier the product defect. One named incident lead should coordinate the response when responsibilities overlap.

Predefine containment options: revoke the service identity, disable a connector, return the workflow to recommendation-only mode, isolate a cell or integration, restore a known configuration, or suspend the AI function while the underlying operation continues safely.

Prove rollback and manual fallback

Rollback is not merely reinstalling an earlier model. The team may need to restore prompts, rules, connectors, permissions, configurations, queued transactions, production parameters, and affected records as one known-good release. Keep versioned deployment packages and reconcile what changed while the AI-enabled workflow was active.

Manual fallback must be specific enough to operate. Identify the trigger, decision-maker, staffing, forms or offline records, production limits, data-entry backlog, reconciliation steps, and criteria for returning to automation. Rehearse it during a realistic shift, not only in a conference room.

For an eCommerce or distribution operation, fallback might mean holding price or availability updates, routing exceptions to a queue, and continuing approved orders. For manufacturing, it may mean reverting to an established inspection plan, maintenance schedule, or operator-controlled mode. Bridge Road’s operations practice connects those technical controls to the people who must keep work moving.

A practical 60-day implementation sequence

1. Inventory every AI-assisted industrial and connected-business workflow.
2. Classify each workflow as observe, recommend, prepare, execute, or influence control.
3. Map data, identities, tools, deterministic rules, approvals, systems, equipment, and suppliers.
4. Remove unused access and separate read, draft, approval, and execution authority.
5. Write acceptance tests for normal, edge, denied, degraded, and recovery states.
6. Require supplier and integrator evidence, notification terms, and named escalation contacts.
7. Define logs, monitoring thresholds, retention, and independent review.
8. Assign business, technical, security, quality, and incident owners.
9. Test containment, rollback, record reconciliation, and manual fallback.
10. Review the overlay when authoritative guidance changes and document each decision.

This overlay is not a substitute for professional safety engineering, cybersecurity assessment, or applicable standards. It is a way to avoid an unmanaged waiting period while industrial AI guidance develops.

Used with clear boundaries, AI can improve inspection, maintenance, planning, energy use, service, and decision support. The goal is not to slow adoption. It is to make useful adoption repeatable, reviewable, and recoverable.

Schedule a conversation to map an industrial AI workflow from data and recommendation through action, evidence, rollback, and manual continuity.