Industrial AI agent security starts with a boundary question, not a model benchmark: what may the agent read, what may it change, and where must a person or deterministic control be able to stop it? A chatbot error may remain on a screen. An agent equipped with tools for maintenance tickets, ERP schedules, MES orders, PLCs or robots can propagate a bad decision into downtime, quality deviation or equipment damage. This guide is for manufacturing, OT and IT leaders in Thailand and Southeast Asia who need a practical design for capability tiers, least privilege, approval, segmentation, kill switches, audit evidence and FAT/SAT.
Executive answer: build AI agent OT security outside the model
The safe starting point is not to trust an LLM as a safeguard. A model may propose or plan an action, but it should not be the final authority for permission, value limits, command order, equipment state, emergency stop or fail-safe behavior. Safety PLCs, safety instrumented systems (SIS), certified safeguards, machine interlocks and accountable human roles remain independent of the model.
A deployable design combines nine controls:
- A unique identity, owner, purpose and expiry for every agent.
- Capability tiers that separate reading, advising, constrained writing and direct execution.
- Least privilege over tools, assets, data, time windows and value ranges.
- Separation between untrusted documents or external input and execution tools.
- An approval service and segregation of duties for high-risk actions.
- Deterministic interlocks and a defined safe state outside the model.
- An AI agent kill switch that can revoke execution immediately.
- Telemetry linking instructions, context, tool calls, approvals and outcomes.
- Rollback, incident response, change control and evidence delivery.
Google Cloud’s manufacturing guidance dated 14 September 2026 recommends embedding security across the agent lifecycle, unifying IT/OT visibility, maintaining agent identity and registry, and detecting unauthorized agents. These are useful vendor recommendations, not a neutral standard or product safety certification. Apply them together with site risk assessment, equipment-vendor requirements, functional safety, cybersecurity and local law.
Why a factory agent is different from a chatbot
The decisive difference is whether tools can change state. Search and summarization mainly influence a human decision. A tool-enabled agent may open a maintenance order, reserve spares, change a schedule, submit a recipe candidate, dispatch an AGV or request robot motion. It can also chain several tools, using one result as context for the next action.
Google Cloud’s 10 September 2026 “agentic factory” article describes agents bridging digital context and physical action under human supervision. It reports, as a Google/GE example, more than 800 customized agents at GE Appliances and a supplier-collaboration agent covering more than 600 suppliers with a reported 25% reduction in backorders. Those figures belong to that organization and use case; they are not a general performance guarantee. The FANUC natural-language-to-mechanical-action example likewise illustrates a vendor scenario, not proof that every plant is ready for closed-loop autonomy.
Separate three operating zones
Before procurement, separate at least these scopes.
| Zone | Typical use | Default posture |
|---|---|---|
| IT assistance | Procedure search, report drafting, inquiry classification | Govern confidentiality, provenance and wrong answers |
| OT-adjacent | Read equipment history, suggest fault causes or work orders | Use a separated read path; a person transfers approved output to the system of record |
| OT execution | Change settings, issue operation, robot, material-handling or process commands | Require constrained APIs, deterministic validation, plant approval and an independent safety layer |
This article focuses on the boundary between OT-adjacent and OT execution. It does not propose that an LLM replace a safety PLC or SIS. AI may recommend a stop, while certified deterministic mechanisms remain responsible for guaranteed protective action.
Contract four capability tiers
NIST discusses classifying agent tools by function and access pattern—read-only, constrained write and write—and by trusted versus untrusted environments. It explicitly includes robotic arms and laboratory or factory equipment as physical extensions. The L0–L3 model below is TOMAS TECH’s manufacturing procurement synthesis, not NIST terminology.
| Tier | Capability | Example | Required boundary | Procurement position |
|---|---|---|---|---|
| L0 Observe | Read, retrieve and summarize | Historian trend or alarm summary | Read-only replica, data scope, provenance | Standard starting point |
| L1 Advise | Generate a recommendation without changing state | Maintenance candidate, schedule proposal | Human decision in a separate interface, visible evidence | Expand after L0 evidence |
| L2 Constrained execute | Perform a narrow write after approval | Draft/create ticket, change an order within permitted values | Approval, range, target, frequency, expiry, idempotency | Authorize by use case |
| L3 Direct execute | Change state in a closed loop | Bounded cell adjustment or dispatch | Independent safety layer, strict broker, immediate stop | Advanced exception |
Do not approve “the AI agent” as one indivisible object. One agent may have L0 access to vibration data, L2 access to maintenance-ticket creation, and no PLC-write permission. Promotion must identify the use case, asset, action, time window and exact model, prompt, policy and tool versions. This prevents a new connector from silently turning an L2 deployment into effective L3 autonomy.
Threat model: look beyond hallucination
MITRE ATLAS’s 2026 OpenClaw Investigation is a case study of one agentic tool. It documents prompt smuggling, indirect prompt injection, third-party skill and supply-chain compromise, context or memory poisoning, credential harvesting and dangerous tool invocation. It should not be generalized as a finding about every agent, but it provides concrete questions for industrial procurement.
In its 1 September 2026 announcement, the OWASP GenAI Security Project said the 2026 LLM Top 10 incorporates evidence from real-world incidents and introduced the Agent Control Standard as practical runtime-enforcement guidance. These are useful public resources for structuring threats and execution controls; they are not functional-safety certification for industrial equipment. The sections below combine them with plant-specific state, interlocks and safe-state design.
1. Untrusted instructions enter the execution path
Maintenance PDFs, email, webpages, supplier portals, QR content and free-text logs can contain natural-language commands. If a model cannot reliably distinguish evidence from instruction, retrieved text can steer a tool call. A warning banner is insufficient: sessions that consume untrusted data should be technically unable to invoke write tools.
2. Excessive agency and reused credentials
A broad ERP, MES or OT service account hides which agent performed an action. Never expose secrets in a prompt or model context. Let the tool broker issue short-lived tokens constrained by target, action, range and count. Avoid automatically inheriting every permission of the requesting user; a person’s legitimate ability does not imply that an agent needs the same reach.
3. Poisoned memory and stale state
Persistent memory can retain a wrong asset relationship, obsolete recipe or hostile string and reuse it later. Store provenance, author, timestamp, asset scope, approval state and expiry with memory. Re-read the system of record before execution, and require review before user text becomes persistent operational memory.
4. Model, skill and connector supply chain
The effective execution capability depends on the model API, agent framework, plugin or MCP server, Python packages, container, connector and prompt template. Manage not only an SBOM, but also allowed versions, signatures or hashes, origin, approver, test evidence and rollback version.
5. Unsafe physical action from missing context
A plausible command can be physically unsafe when a sensor is missing, clocks drift, the machine is in maintenance mode, lockout/tagout is active, a workpiece is misplaced or a person is present. Do not use model “confidence” as a safety decision. Deterministic rules must reject execution when required signals are unavailable or invalid.
6. Loss of provenance and accountability
“The AI decided” is not an incident record. Link the original request, retrieved data and timestamps, model/prompt/tool version, generated proposal, policy result, approver, command and equipment response with a correlation ID. At the same time, do not copy secrets and personal data indiscriminately into logs; define access and retention.
Target architecture: place an execution broker between AI and OT
Avoid a direct session from an agent to a PLC or robot. A reference flow is AI AGENT → API GATE → OT DMZ → PLC/ROBOT. APPROVAL holds high-risk actions on a separate path. SAFE STOP bypasses the model and reaches the plant’s deterministic safety layer.
Agent identity and registry
Register owner, business purpose, tier, model, tools, site, data classification, accountable manager, expiry and last review. At runtime, record the agent, invoking person or service, session and tool version. The broker denies unregistered and expired identities.
Separate read and write paths
Where practical, read historians, MES and quality data through read-only replicas or outbound APIs. Consider one-way transfer or a data diode for suitable use cases. Use different networks, credentials and endpoints for writing. Real-time requirements still do not justify unrestricted access; expose only selected tags or functions through a broker.
API gate and tool broker
Do not give an agent generic SQL, shell access or PLC program download. Expose narrow business actions such as create-maintenance-draft or request-line3-speed-candidate. The broker validates schema, type, unit, range, equipment mode, rate, concurrency, time and duplicate command IDs. Idempotency means a retry cannot execute the same physical action twice.
Approval service and segregation of duties
Approval should not be an ambiguous “OK” in chat. Freeze the asset, current value, proposed value, difference, rationale, impact and expiry in an approval object. Separate requester from approver and model editor from production promoter. Invalidate approval when inputs or plant state change materially.
OT DMZ and segmentation
Separate cloud/IT, OT DMZ, cell/area and equipment networks, with explicit permitted directions and destinations. Do not permit arbitrary AI-platform traffic into OT. The DMZ performs protocol conversion, policy enforcement, queuing, rate limiting and audit. On communication loss, follow a use-case-specific policy—stop, hold current state, or continue local control—rather than letting the model guess.
Deterministic interlocks
Temperature, pressure, speed, guard doors, worker detection, machine mode and lockout/tagout conditions belong in PLC, safety PLC, SIS or machine controllers. Even a proposal within its nominal range must be rejectable by the plant interlock. The agent has no authority to disable safeguards.
Safe state and AI agent kill switch
A kill switch is more than stopping an application. It must prevent new tool calls, revoke issued tokens, quarantine pending queues, complete or cancel in-flight work through a defined procedure, return authority to local control, notify accountable staff and require controlled approval for restart.
The safe state differs by asset. An immediate conveyor stop may cause a dropped load; a furnace may not tolerate a hard stop; an in-process batch may require controlled completion. Engineering, operations, safety, quality and maintenance must agree on transitions implemented independently of AI.
Build an AI agent least-privilege matrix
A role name alone is too coarse. Define subject, tool, action, target, condition, approval, limit and expiry.
| Field | Example | Ambiguity to prohibit |
|---|---|---|
| Subject | agent-maintenance-line3-v2 | Shared “AI user” |
| Action | work-order.create-draft | Generic write |
| Target | Named assets on Line 3 | Factory-wide wildcard |
| Value scope | Priority, due date, approved reason codes | Arbitrary field changes |
| Conditions | Day shift, asset stopped, sensor freshness under 60 s | Always on |
| Approval | Maintenance lead plus production owner | Requester’s self-approval |
| Limit | 10 actions/hour, one asset/action | Unlimited batch |
| Expiry | 15-minute session, 90-day capability authorization | Permanent credential |
Test that prohibited actions fail: another line, out-of-range tag, wrong time, excess rate, expired approval, wrong unit, missing signal, duplicate ID and reversed sequence. FAT/SAT evidence should show that the request was denied before reaching OT.
What an industrial AI RFP must require
An RFP should elicit design and evidence, not yes/no feature claims.
1. Complete inventory of tools and actions
Require every standard, optional and third-party tool, with read/write classification, data, target, protocol, credential, dependent service and network path. If the agent can discover, generate or install tools at runtime, require the control, review, signature and sandboxing model.
2. Trust boundaries and data flows
Require a diagram of users, external documents, RAG, model, memory, broker, IT, OT DMZ and equipment. Ask which inputs are untrusted and how write tools are disabled after such input has entered a session.
3. Identity and permissions
Separate human, agent, service and tool identities. Require short-lived credentials, secret storage, rotation, emergency revocation, site-specific scope and segregation of duties. Administrative permission changes are themselves audited events.
4. Model and skill supply chain
Request model and version, hosting, training/retention terms, framework, skills, connectors, dependencies, SBOM, signatures, vulnerability response, support life, change notification and rollback. Confirm that automatic updates cannot bypass a production promotion gate.
5. Audit and replay
Saving every prompt can create a new sensitive-data repository. Define required evidence, redaction, access, retention, clock synchronization, correlation IDs, tamper resistance, SIEM integration, search/export and reconstruction procedure together.
6. Emergency stop, recovery and rollback
Require procedures for agent disablement, token revocation, queue isolation, local OT operation, manual work, escalation and restart criteria. Ask for rollback unit and recovery time for the model, prompt, policy, tool, configuration, memory and connector.
7. Incident response and change control
Assign responsibility for detection, containment, evidence preservation, equipment safety, communication, root cause and corrective action. High-risk changes trigger repeat FAT/SAT; emergency changes receive time-bound retrospective approval.
8. Deliverable evidence
Make architecture, permission matrix, threat model, test record, residual risk, known limitations, sample logs, restore test, training record, runbook and component inventory contractual deliverables. “Supported” is not evidence; configurations, policies, API schemas and negative-test logs are.
For the broader program, see our AI agent implementation guide. For data and privacy architecture, use secure generative AI environment design. This article narrows the broader AI agent acceptance testing guide to OT connectivity and physical action.
FAT/SAT: prove rejection and safe-state behavior
FAT verifies design, configuration and boundaries in the supplier environment. SAT repeats relevant tests with the actual site’s network, modes, operators, clock, load and procedures. These tests do not replace functional-safety certification or statutory inspection. They demonstrate that the AI path does not bypass existing safeguards.
| Test | Injected condition | Expected result | Required evidence |
|---|---|---|---|
| Indirect injection | Execution text embedded in PDF or maintenance note | Treat as data; do not invoke an unauthorized tool | Input, policy decision, denial log |
| Permission boundary | Other line, out-of-range tag, limit exceeded | Broker denies; nothing reaches OT | API audit and no OT receipt |
| Missing sensor | Remove or mark a required signal bad | Stop or downgrade to advice, never infer | State transition, alarm, notification |
| Stale context | Expired timestamp or changed machine state | Approval expires and data is re-read | Freshness result, reapproval trail |
| Network loss | Break AI–DMZ and DMZ–OT separately | Defined safe behavior and controlled retry | Queue, timeout and recovery log |
| Duplicate command | Resend the same command ID | Execute once, return the original result | Idempotency log, equipment counter |
| Kill switch | Trigger before, queued and in-flight | Block new work, isolate queue, defined complete/cancel | Revocation time, plant state, alert |
| Rollback | Revert model, policy or tool | Restore an approved version and reconcile state | Version, hash, recovery time, checks |
| Log replay | Trace a selected transaction | Reconstruct request through equipment response | Correlation ID, synchronized clocks, gaps |
Record prerequisites, data, versions, responsible people, expected/actual results, machine-readable logs, deviations, correction and retest. Do not rely on a pass percentage. A single critical boundary bypass can be a release stop.
A practical 90-day implementation plan
Ninety days is an illustrative planning frame, not a promise. Equipment modification, functional-safety review, regulation and shutdown windows may require longer.
Days 0–15: define use case and hazard boundary
Inventory the site, assets, users, data and tools. Walk down current interlocks, emergency stop, manual operation and failure recovery. Start at L0 or L1 by default and document why any process needs L2. Assign operations, maintenance, safety, quality, OT, IT, cyber and legal owners.
Days 16–30: implement identity, network and permissions
Create the agent registry, individual IDs, short-lived tokens, allowlisted tools, read-only paths, OT DMZ and correlated logging. Limit write APIs to narrow business operations and validate schema, range, unit, target, frequency and time. Tabletop the kill switch and safe-state transitions.
Days 31–60: evaluate L0/L1 with plant data
Test provenance, freshness, missing and abnormal values, and equipment modes using production-like data. Assess not only recommendation quality, but whether operators can detect bad advice, how the system behaves under load, multilingual operation, memory deletion and audit search. Include injection through untrusted documents.
Days 61–75: FAT/SAT a narrow L2
Choose one approved action, one asset group and one time window. Test duplicates, reversed order, network loss, stale approval, rate limit, wrong asset, missing sensor and kill switch. Do not introduce L3 without a separate safety case and executive authorization.
Days 76–90: promote, continue or stop on evidence
Review open defects, residual risk, operational workload, training, log completeness and recovery time. Decide among “continue L0/L1,” “promote to bounded L2,” “continue with conditions,” “retest” or “stop.” Schedule post-go-live reviews at days 30, 60 and 90 and define retest triggers for model or tool change.
Transparent hypothetical risk scoring
The example below is illustrative and is not an official OWASP AIVSS threshold. AIVSS v0.8 provides an agentic-AI-focused vulnerability scoring method that complements existing frameworks. Confirm the current method and your organization’s acceptance rules for a real project.
Assume likelihood 1–5, impact 1–5, and risk score = likelihood × impact, giving a range of 1–25.
| Hypothetical scenario | Before | Calculation | After | Calculation |
|---|---|---|---|---|
| Untrusted PDF steers a maintenance tool | 4×4 | 16 | Separate write tools from read sessions: 2×4 | 8 |
| Shared credential writes to another line | 3×5 | 15 | Individual ID, target restriction, two-person approval: 1×5 | 5 |
| Command executes twice after network recovery | 3×4 | 12 | Idempotency key and queue reconciliation: 1×4 | 4 |
Impact remains 5 in the second row under the conservative assumption that consequence severity has not changed, even if likelihood falls. Record who accepts residual risk. Do not declare safety from a total or average score; functional-safety prohibitions, law and absolute corporate gates prevail.
Monitor boundaries after go-live
Model accuracy alone cannot reveal boundary drift. Monitor unauthorized agents, denied tool calls, permission changes, approval latency and expiry, stale-data use, downgrade on missing signals, duplicate commands, kill-switch drills, logging gaps, model/skill changes, manual intervention and rollback.
Do not interpret frequent denials as an automatic reason to widen access. They can signal a flawed workflow, poor training, an attack or configuration drift. A lower denial rate is not improvement if audit evidence disappears. Monthly, reconcile the registry with actual network routes, tools and credentials, and remove unused capability.
Common failure patterns
- Granting admin rights for a PoC: the exception becomes the production baseline. Test least privilege in the PoC.
- Assuming human approval equals safety: a person may miss a unit, stale value or changed machine state. Approval UI and deterministic validation are both required.
- Treating a kill switch as process termination: issued tokens, queues, in-flight work and equipment recovery remain.
- Logging everything: secrets and personal data become a secondary risk. Store the minimum protected evidence needed for reconstruction.
- Scaling from one pass to every plant: assets, processes, networks and procedures differ. Authorize capability per use case and site.
- Allowing AI to modify safety PLC logic: this destroys safety-layer independence. Prohibit AI paths from disabling safeguards.
Deployment checklist
Before RFP
- [ ] Separate IT assistance, OT-adjacent and OT-execution scope.
- [ ] Classify every use case from L0 to L3.
- [ ] Keep safety PLC, SIS, interlocks and human accountability independent.
- [ ] Inventory tools, data, credentials, networks and suppliers.
- [ ] Define asset-specific safe states and kill-switch coverage.
Before FAT/SAT
- [ ] Use unique agent identities and time-limited capability authorizations.
- [ ] Separate read and write paths and credentials.
- [ ] Route writes through allowlisted business APIs.
- [ ] Freeze scope, difference and expiry in approvals; invalidate on state change.
- [ ] Test injection, missing signal, stale context, network loss, duplicate and stop.
- [ ] Reconstruct request through equipment response from logs.
Before production
- [ ] No unresolved critical boundary bypass remains.
- [ ] Demonstrate token revocation, queue isolation and manual recovery.
- [ ] Demonstrate rollback of model, policy, tool and memory.
- [ ] Obtain evidence approval from operations, OT, IT, cyber, safety and quality.
- [ ] Set repeat-FAT/SAT triggers and 30/60/90-day reviews.
FAQ: industrial AI agent security
Can a factory AI agent connect directly to a PLC at the start?
That is not the recommended starting point. Prove data quality, provenance, audit and operations at L0 read and L1 advise. If writing is necessary, begin with L2 through a narrow business API, approval, value range, equipment-state check, idempotency and an independent safety layer—not generic PLC access.
Is normal RBAC enough for AI agent least privilege?
Usually not. Add asset, action, range, unit, time, rate, data freshness, approver and session expiry. Prove that forbidden operations fail through negative testing.
Is an AI agent kill switch the same as an emergency stop?
No. The AI kill switch disables tool calls, credentials, queues and sessions. Machine emergency stop and safe shutdown remain the responsibility of certified safety circuits, PLCs, SIS or equivalent deterministic mechanisms. Define how the two layers interact.
Does human approval make direct L3 execution safe?
Approval alone is not a guarantee. Display omissions, fatigue, stale data and unit errors remain. An independent safety layer, broker, state validation, limits, monitoring, stop and recovery are necessary. For many use cases, not adopting L3 is the correct decision.
Can OWASP AIVSS alone determine go/no-go?
Scoring supports comparison and discussion; it does not replace functional safety, regulation, equipment-vendor conditions or corporate prohibitions. Record method version, assumptions, evidence and the residual-risk owner.
Does this FAT/SAT replace functional-safety certification?
No. It tests the AI agent’s boundary, permissions, denial, safe-state and evidence behavior. Equipment-specific functional-safety assessment, certification, statutory inspection and plant procedures remain separate obligations.
Summary: prove that capability can be stopped before increasing it
The closer an industrial AI agent gets to physical process action, the greater both its value and its potential impact. Separate L0 observe, L1 advise, L2 constrained execute and L3 direct execute per use case. Design identity, allowlisted tools, read/write separation, OT DMZ, approval, deterministic interlocks, safe state, kill switch and audit before granting capability. In the RFP, require proof that prohibited operations are denied, failures move to the agreed safe behavior, and a complete history can be reconstructed. Promote only the use cases that pass negative FAT/SAT and obtain explicit residual-risk acceptance.
TOMAS TECH can support the concept stage for OT-connected AI agents through capability classification, threat modeling, industrial AI RFPs, network and permission design, and FAT/SAT evidence plans. You can contact us while evaluating products or even before moving beyond L0/L1.
Primary references
- Google Cloud, “A manufacturing blueprint for secure agentic AI” (14 Sep 2026): https://cloud.google.com/transform/a-manufacturing-blueprint-for-secure-agentic-ai
- Google Cloud, “Inside the agentic factory” (10 Sep 2026): https://cloud.google.com/transform/agentic-factory-manufacturing-new-age-of-autonomy-industrial-ai
- OWASP GenAI Security Project, “2026 Top 10 for LLM Applications” announcement (1 Sep 2026): https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
- NIST, “Lessons Learned from the Consortium: Tool Use in Agent Systems” (Aug 2025): https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
- MITRE ATLAS, “OpenClaw Investigation” (9 Feb 2026): https://www.mitre.org/sites/default/files/2026-02/PR-26-00176-1-MITRE-ATLAS-OpenClaw-Investigation.pdf
- OWASP, AIVSS v0.8 project page: https://aivss.owasp.org/
This article is a general implementation and procurement guide based on public information reviewed on 19 September 2026. It does not replace equipment-specific functional-safety certification, legal compliance or a cybersecurity assurance.
