Humanoid robots are entering open environments like airport tarmacs, where perception errors have physical consequences. Standard IT/OT security models miss model-level risks. In physical AI, security must be established during simulation — before behaviors transfer to the physical system.
On April 28, 2026, Japan Airlines ran a public demonstration at Haneda Airport that marked a new threshold for physical AI deployment: a humanoid robot pushing cargo onto a conveyor belt beside a live aircraft, coordinating with a human handler on an active tarmac. Beginning May 2026, these units are expected to support baggage and cargo handling as part of a multi-year trial at one of Asia's busiest operational environments, processing more than 60 million passengers annually.
The robot's perception and decision-making capabilities are developed in simulation, trained inside Nvidia Isaac Sim, and transferred to the physical system through Unitree's Sim2Real pipeline. This approach enables rapid iteration and scalable training.
The security question this raises: where in the development lifecycle are model-level risks evaluated, and is that point early enough to prevent them from reaching deployment?
For cybersecurity leaders at OEMs and Tier 1 suppliers now evaluating physical AI exposure, the Haneda deployment offers a useful reference point. The risk profile of open-environment physical AI is distinct from standard IT or OT systems, and the intervention point is earlier than most security frameworks currently assume.
Why open-environment deployments change the risk profile
Physical AI systems operating in controlled industrial settings, such as factory floors with fixed safety fencing and predictable layouts, face a relatively constrained range of inputs. Open environments change that calculus significantly.
Haneda's tarmac is a dynamic, shared space: aircraft in motion, ground vehicles on variable schedules, and human handlers working without fixed spatial boundaries relative to automated systems. Even where safety-critical decisions remain under human oversight, the robot performs continuous perception tasks, determining where to move, identifying objects, and responding to nearby workers.
Those decisions are shaped by a vision-language model (VLM) trained through repeated simulation cycles. The relevant security question is not only how the system behaves under expected conditions, but how it responds to inputs that fall outside its training assumptions, including edge cases and failure modes that may not surface during standard functional testing.
The core distinction: in open environments, perception errors are not abstract. They directly influence physical outcomes, and the proximity to humans and high-value assets increases the consequence of any misinterpretation. These conditions introduce risks that standard IT or OT security models are not designed to capture.
Three risk layers that standard security audits miss
The security profile of a physical AI system extends beyond firmware versions and network configurations. Three distinct layers require different evaluation approaches, none of which are covered by a conventional IT security audit.
Perception layer: adversarial inputs to vision-language models
Physical AI systems interpret their environment through VLMs, processing visual, spatial, and linguistic inputs to guide behavior. Adversarial inputs to VLMs are a documented class of risk: carefully designed visual patterns, when introduced into the robot's field of view, can influence how objects are classified or how spatial relationships are interpreted.
In operational environments, this can affect how the system responds to obstacles, equipment, or nearby personnel, without producing any network anomaly or system-level alert that conventional detection tools would flag.
Simulation pipeline: Real2Sim, Sim2Sim, and Sim2Real transfer
In physical AI development, engineers first reconstruct real-world environments into a digital twin using motion capture, sensor data, and recorded environments. Once that Real2Sim environment is established, learned behaviors and perception models can be evaluated across varied simulated conditions through Sim2Sim validation before being transferred to the physical system through the Sim2Real pipeline.
This process enables efficient training at scale, but it also means that any untested assumptions or failure modes that remain in simulation can carry forward into deployment.
Sim2Real transfers learned behavior. It does not inherently distinguish between expected and unexpected outcomes.
Sensor input chain
Physical AI systems rely on LiDAR, cameras, and depth sensors to build spatial awareness. Research has demonstrated that sensor data can be altered in ways that affect how systems perceive distance, obstacles, or motion. LiDAR spoofing techniques, for example, have shown that carefully introduced signals or reflective surfaces can modify the point cloud used for spatial awareness, producing incorrect interpretations of the environment.
In dynamic, open environments, even small deviations in sensor interpretation can influence system behavior in ways that are not immediately visible to surrounding operators.
What human oversight does and does not cover
Human oversight is a critical component of safe deployment. It provides governance, situational awareness, and the ability to intervene when observable issues arise.
However, human supervision operates at the level of visible behavior. It does not catch adversarial inputs operating within the robot's normal behavioral envelope. If a perception model misclassifies an object or misinterprets spatial context, the system may continue to behave as expected from an external perspective, even when its internal understanding of the environment is incorrect.
Consider a routine ground operation: a robot working alongside human operators, moving cargo in a shared environment. A small visual pattern, subtle and consistent with normal labeling, is introduced on a nearby object. To a human observer, nothing appears unusual. To the robot's VLM, that pattern may be interpreted differently depending on how the model was trained, potentially influencing how it classifies nearby objects or interprets spatial relationships.
The robot continues to operate as designed. The misinterpretation is invisible to surrounding operators. In open settings where movement and proximity matter, that gap between visible behavior and internal model state is where the risk lives.
For operators, this shifts the focus from the presence of oversight to the conditions under which the system was validated before deployment.
The simulation window: Where security testing belongs
The physical AI development pipeline creates a specific and accessible window for security evaluation: after the real environment has been reconstructed into a digital twin, during simulation-based validation, and before learned behaviors are transferred to the physical system. At this stage, the simulation environment provides a controlled setting where a wide range of inputs can be tested without operational risk.
This is where adversarial input testing should run — beginning once the Real2Sim environment is established, continuing through Sim2Sim validation across varied simulated conditions, and serving as a gate before Sim2Real transfer. Rather than relying solely on post-deployment controls, operators can assess how perception systems respond to adversarial inputs, edge cases, and sensor data variations while corrective action is still possible before deployment.
After transfer, corrective action requires re-entering the training cycle. The simulation window is not just the most efficient intervention point; for model-level failure modes, it is often the only accessible one.
VicOne's Lab R7 physical AI security research focuses on this stage of the lifecycle, applying adversarial testing within simulation environments to map how perception models respond under varied conditions. This approach generates a pre-deployment view of potential failure modes before behaviors reach physical systems.
In physical AI, what is not tested in simulation is not controlled in deployment.
As physical AI systems move into open and safety-critical environments, simulation-phase validation is a foundational requirement, not an optional assurance layer.
Key questions for operators evaluating Physical AI systems
Why does physical AI security require a different approach than standard OT or IoT security?
Standard OT and IoT security focus on protecting communication protocols, network interfaces, and software configurations. Physical AI systems introduce an additional risk layer within the robot's perception and decision architecture.
Adversarial inputs to a VLM do not exploit a network vulnerability; they exploit the model's learned behavior. The relevant control point therefore shifts earlier in the development lifecycle, to the simulation and training pipeline rather than the network boundary. Traditional monitoring tools have limited visibility into these model-level failure modes.
Why is the pre-Sim2Real stage the critical security intervention point?
Sim2Real transfers behaviors learned in simulation to the physical system. Any assumptions or failure modes that remain unresolved before transfer can move with them. Evaluating adversarial inputs after the Real2Sim environment is established and throughout Sim2Sim validation allows issues to be identified and addressed before deployment, without requiring physical access to the system, and enables corrective actions such as retraining before behaviors are operationalized.
Can conventional security monitoring detect adversarial visual attacks on VLMs?
In most cases, no. Adversarial inputs are delivered through the robot's normal sensor channels as valid data. They do not produce network anomalies or system-level indicators that traditional detection tools rely on. The attack operates entirely within the model's inference process, producing incorrect outputs without triggering a conventional security alert. Addressing such inputs requires model-level security testing, conducted during the simulation phase before deployment.
What security artifacts should operators request before approving a co-located deployment?
Operators should request three types of validation artifacts from robot developers:
- Adversarial input test report covering the VLM perception layer, including visual, spatial, and voice input attack classes against the deployed model version
- Simulation validation and transfer integrity assessment documenting which behaviors were tested during Real2Sim and Sim2Sim validation, what failure modes were identified, and what remained before Sim2Real transfer
- Sensor spoofing evaluation covering the specific sensor configuration of the deployed unit under conditions that approximate the target environment
Traditional network or software certifications do not address these areas directly.
Going deeper on Physical AI security
VicOne CEO Max Cheng demonstrated live attack scenarios against vision-language-action (VLA) and VLM-powered robots at CYBERSEC 2026, showing how pre-deployment simulation testing surfaces failure modes before they reach physical systems.
For a comprehensive look at the cybersecurity risks and defense strategies shaping autonomous robotics, download VicOne Lab R7's whitepaper, Securing the Rise of AI Robots: Cyber Risks, Real-World Threats, and Defense Strategies.
