Warehouse robots and AI agents: how the threat model changes

When AI agents and robots run a warehouse, a software compromise can cause physical effects: moved loads, blocked aisles, stopped lines. The threat model shifts from protecting data to protecting safe operation. Start with network zones, narrow agent permissions, human approval for actions with physical consequences, and a tested manual fallback.

We describe no incidents here, because we did not find sources we could verify for this post. What follows is how the standards and guidance we reviewed apply.

What is different from an office network?

In an office, the worst outcome of a compromised system is usually data loss or downtime. In a warehouse with automated vehicles, conveyors and robotic arms, the same compromise may affect equipment near people. Availability and safety become the main concerns, and patching is harder because stopping a system stops the business.

Add AI agents and a second change appears. An agent that can plan routes, reassign tasks or call control interfaces turns text and data into actions. If it reads untrusted input, that input can influence it.

Which standard speaks to industrial control security?

ISA/IEC 62443 is a family of standards for industrial automation and control systems. It addresses stakeholders who share responsibility: asset owners, automation product suppliers, integrators and service providers. Its parts cover general concepts, policies and procedures (including patch management and requirements for service providers), system requirements and security levels, and secure product development for components.

For a warehouse operator, the useful idea is the split of responsibility. The operator, the integrator who installed the robots and the supplier who built them each have duties, and a contract should say which.

What does AI add?

OWASP's guidance on LLM applications names Excessive Agency, which arises from excessive functionality, excessive permissions or excessive autonomy. Its mitigations translate directly: give the agent only the tools it needs, prefer narrow tools over open ended ones, grant only the permissions the task requires, require user approval for high impact actions, and enforce authorization in downstream systems instead of trusting the model's judgment.

For a robot fleet this means the agent can propose a route change, and a deterministic safety layer decides whether it is allowed. The agent should not be able to override safety interlocks, ever.

OWASP also describes indirect prompt injection, where an LLM accepts input from external sources and hidden instructions change its behavior. A label, a document in a shipment or a message from a supplier system could carry such text. Treat all of it as data.

NIST's AI Risk Management Framework, released in January 2023, is a voluntary framework for managing AI risks, and a companion Generative AI Profile followed in July 2024. They are useful for structuring a review of where AI sits in your operation.

How should you structure the controls?

Separate zones. Keep the robot control network apart from office systems and from the internet, with a controlled path between them. Keep agents that read external data away from agents that can issue motion commands.

Keep a safety layer independent of the AI. Hardware and certified safety functions should stay in force whatever a software component asks for. We are not citing a standard for robot safety here, because we did not retrieve one; ask your integrator which robot safety standards apply to your equipment.

Plan a manual fallback and rehearse it. If the system must stop, how do people keep goods moving, and who authorizes a restart?

Where does software supply chain risk enter?

Robots run firmware and software built from third party components. Ask suppliers for a software bill of materials, track vulnerabilities in it, and agree how patches are delivered and tested. Safeguard can build and monitor inventories for software you ship, but you will need suppliers to give you theirs for the equipment you buy.

What to do

1. Map the systems that can cause physical movement and who can command them.
2. Separate those networks from office and internet access.
3. Give each AI agent narrow tools and read only access by default.
4. Require human approval for any action with physical consequences.
5. Keep safety functions independent of AI and confirm them with your integrator.
6. Ask suppliers for component inventories and a patch process.
7. Rehearse a manual fallback and a safe restart.

Quick check

Sources

• ISA/IEC 62443 series of standards, ISA
• OWASP LLM06 Excessive Agency
• OWASP LLM01 Prompt Injection
• NIST AI Risk Management Framework

Last reviewed: 18 October 2026.