A research team from the School of Computer Science and Technology at Shandong University has published a systematic study on what it calls “action semantic integrity” in cloud-driven embodied intelligence robots, showing that a robot’s final physical behavior is determined not by any single network packet or by ordinary natural-language text, but by the action-bearing content that the local program reassembles and parses after receiving a streamed cloud response. The work appears in the 2026 fourth issue of AI-VIEW, spanning pages 46 to 57, with the digital object identifier 10.16453/j.2096-5036.202635 and the article number 2096-5036(2026)04-0046-12.
The authors — Li Junchao, Huang Yuhang, Zhang Yue, and Cheng Xiuzhen, the corresponding author — conducted packet capture analysis, controlled man-in-the-middle modification experiments, and local capability-chain observation across three robot platforms: the Unitree GO2-W, the Unitree Go2, and the Unitree G1. Their central finding is that when action-bearing content is deleted, modified, replaced, or inserted during transmission and the altered content still satisfies local parsing requirements, the embodied intelligence system will execute behavior that differs from the original cloud-returned decision. Conversely, when only the natural-language feedback is altered while the action content is preserved, robot behavior does not change accordingly.
- Why embodied intelligence changes the security conversation
The rapid development of large language models and multimodal models has given embodied intelligence robots stronger capabilities in language understanding, task planning, and motion generation. Research in this field has expanded along several directions, including multimodal perception, task planning, and vision-language-action mapping. Unlike traditional robots that mainly rely on local fixed programs or preset commands, cloud large-model-driven robots can accept voice, text, or application-side instructions from users, forward those requests to a cloud model for processing, and then have the local robot program receive and parse the returned content.
This architecture lowers the difficulty of implementing natural-language interaction and complex task planning, and it allows embodied intelligence systems to respond to user needs in a more flexible manner. It also, however, introduces a new class of risk that does not fit neatly into existing categories of model security or communication security.
Prior work has shown that jailbreak attacks and prompt injection can cause models to break through established constraints and produce unexpected output. Evaluation efforts have analyzed these risks from perspectives such as Chinese-language jailbreak attacks and general model safety capability. When large models are further connected to tools, applications, and agent frameworks, external input can also interfere with model judgment and influence tool invocation or task execution. As a result, the security impact of large models is no longer confined to the text output itself. For embodied intelligence robots, once model output is connected to task planning, action selection, or local capability invocation, anomalous results generated on the model side may continue to propagate to the level of robot behavior.
Robot systems carry other security risks as well. Existing research has separately examined physical adversarial attacks and sensor spoofing against perception devices such as LiDAR, as well as communication and interface security issues in ROS, ROS 2, DDS middleware, and robot software. The risk sources for embodied intelligence systems are therefore dispersed: they may originate from model input and model output, and they may also appear in environmental perception, network transmission, and local software interfaces.
Existing studies, however, tend to concentrate on individual modules such as the large model itself, perception, or execution, and there is a shortage of end-to-end link analysis. When a cloud model generates an action based on user input, the question of whether that action enters the robot’s actuators completely and safely has not been adequately answered. If the action is tampered with during transmission, the consequences may be unexpected.
The question the authors pursue is precise: is the action content that the robot locally receives and uses for execution always consistent with the original return result of the cloud large model? If the action-bearing content is deleted, modified, replaced, or inserted during transmission, and the altered content still satisfies local parsing requirements, the robot may execute an action different from the one originally returned by the cloud. Encryption, session isolation, syntax checking, and parameter limits can reduce some risk, but these measures cannot directly determine whether the action content has changed during transmission and parsing. On that basis, the study experimentally verifies the process by which action content is passed from the cloud response to local execution.
- The architecture of a cloud-driven embodied intelligence system
A cloud large-model-driven embodied intelligence robot typically comprises four parts: a cloud large-model service, a local robot runtime program, local middleware, and robot execution modules. The cloud service receives user input and generates natural-language feedback or action-related content. The local runtime program receives the cloud response and performs caching, reassembly, discrimination, and parsing. Local middleware connects capability modules for motion, voice, and status. The execution modules translate higher-level capability invocations into actual motion or state changes.
A user issues an instruction through voice, text, or an application. The robot sends the request to the cloud large model. After the cloud returns a response, the local program does not simply display all of the content. Instead, the content may be divided into two classes. One class enters the voice broadcast or interface display path as natural-language feedback. The other class is recognized as action-bearing content and enters the action parsing and capability invocation path. Only the latter, once accepted by the local program, may further influence robot motion, voice, or state changes.
Accordingly, the paper does not focus on whether the robot directly executes all content returned by the cloud, but on the specific portion of the cloud response that the local program can recognize as an action. The analysis and modification targets in the experiments are likewise not all network communication data, but the action-bearing content directly related to action execution within the current legitimate session.
The transformation from text to action semantics in embodied intelligence differs fundamentally from ordinary large-model applications. In a conventional large-model application, model output is mostly displayed directly to the user as text or images. In an embodied intelligence robot, the cloud response may be further processed by the local program and ultimately converted into physical-world action. If a harmful action is generated, it causes direct harm in the physical world.
After receiving a user instruction, the large model extracts the action request from that instruction and determines whether it possesses the corresponding action capability. If it does, the model invokes the corresponding action function from a preset action command library, fills in the relevant parameters, and synthesizes the action semantics with the textual reply into a single response. The cloud response, however, is usually not returned all at once. It is composed of multiple fragments. Within the same request, the text, action name, parameters, and end marker may be distributed across different fragments. The local robot program therefore needs to reassemble them according to request identifier, fragment order, and end state. After reassembly, the local program distinguishes the returned content. Ordinary natural-language text is typically used for voice broadcast or interface display, while action content with a specific structure enters the action parsing flow. Only when the action content conforms to local parsing rules, the action name can be recognized, and the relevant parameters fall within the permitted range may it be converted into a concrete capability invocation for motion, voice, or state.
The robot therefore does not execute a particular packet in the network, nor an entire segment of natural-language text, but rather the action content that the local program identifies and parses from the complete response. The packet capture and modification experiments in the study take this portion of content as their primary observation target.
- Defining action semantic integrity for embodied intelligence
The paper defines action semantic integrity as whether the action content that the robot locally receives and uses for execution remains consistent with the action content originally returned by the cloud large model. The comparison is not limited to parameters such as distance, angle, or duration. It also includes whether an action is retained, whether the action type has changed, and whether the order and number of actions remain consistent.
It is important to note that action semantic integrity is not equivalent to the safety of the cloud large model output itself. If the cloud model generates an unreasonable action because of hallucination, jailbreak, or prompt injection, that problem belongs to the domain of upstream model safety and task policy safety. The concern here is a different boundary: after the cloud has already returned a given action content, does the action content that the robot locally receives and parses still remain consistent with the original cloud return?
From generation to execution, a cloud action must pass through network transmission, local reception, fragment reassembly, and action parsing. A content change at any of these stages may cause the local program to receive an action different from the original cloud result. For example, the original action may be deleted, a parameter may be altered, the action type may be replaced, or a new action may be added to the original action sequence. If the modified content still satisfies local parsing requirements, the robot may execute according to the altered content.
This problem cannot be entirely subsumed under what is usually called communication security. Encryption primarily protects transmitted data, session isolation distinguishes different connections, and format checking and parameter limits reject structurally erroneous or out-of-range actions. But for content that is correctly formatted and whose parameters remain within the permitted range, these mechanisms may not be able to identify whether the action itself has been trimmed, replaced, or inserted. On this basis, the study designs five categories of experiments — action deletion, parameter modification, action replacement, action insertion, and text-only modification — to compare the effects of different content changes on robot behavior.
- The threat model applied to embodied intelligence experiments
The experiments assume that an attacker or test component is located within the current legitimate cloud-to-robot communication path and is able to observe and forward the cloud response content within that session. The attacker does not, however, possess control over the vendor cloud service, control over the user account, control over the robot firmware, or the ability to invoke arbitrary local middleware.
The experimental node operates only within an authorized network and on authorized devices. Modification targets are limited to action-bearing content within the current legitimate session. The attacker does not forge an independent robot identity, does not disrupt the session establishment process, and does not access sensitive data such as accounts, tokens, or audio and video.
The attacker capability is further constrained as follows: the attacker can identify the action-bearing region in the cloud response and can perform controlled changes to action existence, parameters, type, order, and number without breaking the basic session structure, request-response relationship, or streaming response flow. The attacker cannot generate arbitrary executable code, cannot bypass the local parser whitelist, cannot bypass underlying parameter boundaries, and cannot directly invoke arbitrary DDS services.
This threat model is used to verify whether action content possesses semantic integrity binding before it enters the local parser. It is not intended to demonstrate public-network remote control or arbitrary code execution.
- Analyzing the cloud large-model communication link for embodied intelligence
The study first analyzes the communication traffic generated during robot operation through packet capture, observing the data exchange relationships among the robot, cloud services, local devices, and middleware. During robot operation, multiple categories of communication occur simultaneously, including device discovery, state synchronization, voice services, remote interaction, large-model dialogue, and local middleware communication. Without distinguishing these communication channels in advance, ordinary state synchronization, voice services, or remote signaling could easily be mistaken for the source of action content.
The analysis of the cloud large-model communication process comprises five steps. The first is collecting network traffic during voice interaction, text instruction, and action execution. The second is distinguishing different communication channels according to connection peer, data flow direction, message fields, and runtime behavior. The third is locating the large-model dialogue channel that carries user input, model response, and action-bearing content. The fourth is analyzing the uplink requests and downlink responses on that channel, observing request identifiers, content fields, streaming state, and similar information. The fifth is confirming whether the cloud response is returned as multiple fragments and whether the action-bearing content must be reassembled locally before forming complete content. The purpose of this experiment is to determine the communication link in which the action-bearing content resides and to define the modification target for the subsequent man-in-the-middle experiments.
Analysis dimensions applied to the cloud communication process Analysis target Method Purpose Network connection Packet capture and peer identification Distinguish communication channels Data flow direction Uplink and downlink traffic analysis Determine request-response relationships Message fields Field structure analysis Locate content fields and request identifiers Streaming response Fragment order and end state analysis Determine local reassembly behavior Action content Content region observation Define the subsequent modification target The broader implication for embodied intelligence security is that action semantic integrity analysis cannot be limited to whether a network connection has been established, nor can a single packet be equated with a robot action command. What actually enters the execution flow is the locally reassembled action content. The modification target for subsequent experiments should therefore be the action-bearing portion of the cloud response, not an arbitrary communication field. The focus is on whether action content has been changed before entering local execution, not on network connectivity or single-packet tampering in the general sense.
- Man-in-the-middle modification and controlled variation experiments
After confirming the communication link in which the action-bearing content resides, the study applies controlled modification to the communication data between the robot and the cloud large model by means of a man-in-the-middle approach. This method can verify whether the robot’s final behavior changes accordingly when the action-bearing portion of the cloud return content is altered, under the premise that the legitimate session remains valid. Because the cloud response is returned as streaming fragments, the modification target is not an isolated data packet but the action-bearing region that, after buffering, forms a complete semantic unit.
The procedure follows a defined sequence. A man-in-the-middle observation position is established in an authorized network environment so that communication between the robot and the cloud large model passes through the experimental node. The communication data is decrypted and reassembled to locate the action-bearing portion of the cloud return content. The action content is then subjected to controlled modification without breaking the basic session structure, the request-response relationship, or the streaming response flow. The modified response is forwarded to the local robot program. Finally, the robot’s ultimate behavior is recorded for subsequent determination of the experimental result.
Five categories of controlled variation were designed. Deleting an action serves to observe whether the presence of action content affects the execution flow. Modifying parameters serves to observe the effect of changes in fields such as distance, angle, and duration on robot behavior. Replacing an action serves to observe whether a change in action type triggers a change in capability selection. Inserting an action serves to observe whether changes in action order and number can extend a behavior sequence. Text-only modification serves to distinguish the effects of natural-language feedback and action-bearing content on robot behavior.
Design of the man-in-the-middle controlled variation experiments Variation type Modification target Purpose Action deletion Action block Verify the effect of action presence or absence Parameter modification Distance, angle, duration, and similar fields Verify the effect of parameter changes Action replacement Action name or action type Verify whether capability selection changes Action insertion Action sequence Verify the effect of changes in order and number Text-only modification Natural-language feedback Distinguish the text feedback path from the action execution path All communication observation and modification experiments were completed on authorized devices and in a controlled debugging environment. The experimental environment used a controlled certificate trust configuration so that the test proxy node could observe, reassemble, and forward response content within the current legitimate session. This setting was used to construct a semantic difference between the original cloud action content and the locally received action content. It does not demonstrate that TLS or HTTPS protection can be bypassed under ordinary external network conditions. The experiments did not break the vendor cloud authentication process, did not obtain third-party accounts, tokens, or sensitive data, and do not support the conclusion that a public-network attacker or ordinary network neighbor could directly modify communication with a real robot. The purpose of this step is not to demonstrate remote control or arbitrary code execution, but to verify the relationship between changes in action-bearing content and the robot’s final behavior.
- Observing the local capability chain after action parsing in embodied intelligence
In addition to observing whether changes in action content affect robot behavior, the study observes the capability chain that action content enters after being received locally. This part analyzes which local capability modules the action content may connect to once it enters the local program. The authors do not use this to prove that any middleware interface can be invoked. Rather, it is used to show that action content, once accepted locally, does not remain at the text layer but may further enter local capability chains for motion, voice, and status.
The observation method proceeds in five steps. The first is a static scan of themes, interfaces, and processes in the robot’s local system to obtain possible capability entry points. The second is observing DDS topics and participants during robot operation to supplement dynamic topics and runtime communication relationships that static scanning cannot cover. The third is comparing static scan results with runtime observation results to distinguish permanently present interfaces from those that appear at runtime. The fourth is selecting low-risk capabilities such as volume settings for verification, observing whether the middleware channel can trigger an actual capability change. The fifth is treating high-risk interfaces involving motion control, system execution, configuration writing, or low-level control purely as audit objects, recording them without actively invoking them.
Methods used to observe the local capability chain Method Observation target Purpose Static scan Topics, interfaces, processes Obtain possible capability entry points Runtime observation DDS topics, participants Discover dynamic capability channels Result comparison Static and runtime results Distinguish fixed and dynamic interfaces Low-risk verification Volume settings and similar capabilities Verify that some capabilities can be triggered High-risk exclusion Motion control, system execution, and similar interfaces Record only, with no active invocation The purpose of this step is to observe the range of local capabilities that action content may enter after being accepted locally, providing supplementary evidence for the subsequent analysis of robot behavior impact. It is not a demonstration that arbitrary DDS interfaces can be invoked, nor that arbitrary code execution capability exists.
- Experimental environment and platforms
The experiments were conducted on authorized devices, within an authorized network, and in a controlled site. The experimental objects include the Unitree GO2-W robot, the Unitree Go2 robot dog, and the Unitree G1 humanoid robot. Experiments involving movement, turning, and posture changes were restricted to low speed, short distance, small angle, and short duration, with manual supervision and emergency stop measures in place.
Experimental environment and objects Item Configuration Experimental objects Unitree GO2-W, Unitree Go2, Unitree G1 System configuration 12th generation Intel Core i7, Windows 11, Ubuntu 22.04 Network environment Same local area network, controlled network Software tools Wireshark 4.6.6, ROS 2, CycloneDDS Observation content Communication process, action modification, local capability chain - Results from the communication process analysis of embodied intelligence systems
Packet capture analysis shows that a robot in operation does not possess a single “action communication channel.” Instead, multiple categories of communication occur simultaneously, including device discovery, time synchronization, status reporting, voice services, remote interaction, large-model dialogue, and local middleware communication. Different channels serve different functions. Device discovery, time synchronization, and status reporting mainly maintain device operating state. Voice services mainly support speech recognition and speech synthesis. The remote interaction channel supports application-side or remote-control-related functions. The channel directly relevant to this research is the large-model dialogue channel, which simultaneously carries user input, model response, and the action-bearing content within them.
Further analysis of the large-model dialogue channel reveals that the cloud response is not always returned as a complete action content in a single piece but may be split into multiple streaming fragments. The beginning of an action block, the action name, the parameters, and the end position may be distributed across different fragments. A single network packet or a single response fragment usually cannot directly represent the complete action content. The local robot program must cache, order, and reassemble these fragments, and then identify the executable action-bearing portion from the complete response.
The reported traffic analysis covers 19 WebSocket sessions and 4478 data frames. From these, 73 responses containing action content were identified. The analysis also identified the core channels carrying user input, model responses, and action content, and examined the streaming return of cloud responses together with the local reassembly method.
This result produces two direct findings for embodied intelligence security. First, action semantic integrity analysis cannot look only at whether a network connection has been established, nor can it treat a single packet as equivalent to a robot action command. What truly enters the execution flow is the locally reassembled action content. Second, the object of subsequent modification experiments should be the action-bearing portion of the cloud response, not an arbitrary communication field. In other words, the question of interest is whether action content has been changed before entering local execution, not network connectivity or single-packet tampering in general.
- Results from action content modification in embodied intelligence robots
In these experiments, only the action instruction portion of the cloud response packets was modified. Session identifiers, the request-response relationship, and the action format were all kept unchanged. If a modified packet could enter the robot’s internal execution environment correctly, the robot’s final executed action should correspond to the modified action.
After deleting the action block, the robot could still complete text or voice feedback, but the corresponding action was not executed. When fields such as distance, angle, or duration were adjusted, the action type did not change, but the robot’s movement extent, turning degree, or execution duration changed with the parameters. After replacing the original action with another recognizable action, the robot executed the replaced content. After adding a new action item following the original action, the robot continued to execute in the modified order, and the original single-step behavior became a continuous action as a result.
These results show that action-bearing content is not merely descriptive information. It is the actual input used by the local program for action parsing and capability invocation. The reason the experiments could observe behavior changes is not that the robot accepts arbitrary network data, but that the modified content still conformed to the local program’s format and parameter requirements and was therefore processed as a valid action.
When only the natural-language feedback was modified, the robot’s action did not change accordingly. This control result indicates that text feedback and action execution belong to different paths in local processing: the former is mainly used for broadcast or display, while the latter directly affects robot behavior. Therefore, checking action semantic integrity cannot rely solely on whether the session is valid or whether parameters are out of range. It should also confirm whether actions have been deleted, replaced, or inserted, and whether action order, number, and specific parameters remain consistent with the original cloud result.
- Results from local capability-chain observation
Local capability-chain observation was used to understand where action content goes after being accepted locally. CycloneDDS was then used to observe topics, participants, and related processes during robot operation. Static extraction yielded 43 candidate topics, while runtime observation found 104 active topics. Merging the two result sets and removing duplicates produced a total of 107 topics. Among these, 64 topics appeared only at runtime, and 3 topics existed only in the static extraction results. Runtime observation also identified 18 request-response API groups, 15 related processes, and 34 DDS participants.
Static and runtime DDS observation results for embodied intelligence platforms Observation item Count Explanation Statically extracted topics 43 Candidate topics obtained from local files, logs, and type information Topics found at runtime 104 Active topics observed during robot operation Merged topics 107 Total after merging and deduplicating static and runtime results Runtime-only topics 64 Runtime communication topics not covered by static analysis Static-only topics 3 Candidate topics not activated during observation or dependent on specific conditions Request-response APIs 18 API groups identified from topic structure Related processes 15 Running processes associated with DDS endpoints DDS participants 34 Participants discovered at runtime These figures indicate that after local parsing, action content may continue through middleware into the corresponding capability modules. However, the discovery of a topic or API is not equivalent to that topic or API being invokable by any participant. This part of the observation also delimits the scope of the paper’s conclusions. Only low-risk capabilities such as volume settings were verified. High-risk interfaces involving motion control, system execution, configuration writing, or low-level control were recorded only as audit objects and were not actively invoked. Therefore, local capability-chain observation cannot be interpreted as meaning that arbitrary DDS interfaces can be invoked, nor that arbitrary code execution capability exists. It can only show that after action content is accepted locally, there is indeed a possibility that it continues into part of the local capability chain.
It should further be noted that ROS 2 and DDS security mechanisms can limit the exposure scope of the middleware capability surface, but they cannot directly replace semantic integrity verification between cloud-returned content and local action objects. The two correspond to different security boundaries, one before and one after action content enters the local capability surface. DDS topic discovery results are mainly used to characterize the local capability boundary and are not directly equivalent to the action payload being able to trigger all actuators through an independent participant. In the study, only low-risk capabilities such as volume settings underwent message publish-subscribe matching and state-change verification, confirming that some local capability channels are indeed triggerable. For high-risk interfaces involving motion control, system execution, configuration writing, and low-level control, the study records only their topic, interface, and process relationships, does not actively publish payloads, and does not interpret them as completed invocation verification.
- Case studies across embodied intelligence robot platforms
To compare the manifestation of action content modification across different robot forms, the study selected the Unitree GO2-W, the Unitree Go2, and the Unitree G1 as case study platforms. Because the GO2-W and the Go2 both belong to the quadruped platform category, their action invocation methods and movement control logic are relatively similar. The study therefore treats them as samples for parameter modification and platform replication, without repeating the same action types. The G1 humanoid robot possesses more complex limb movements and action sequence organization relationships, so it serves as the key case for action type replacement, action insertion, and action sequence variation.
In the quadruped platform experiments, the action type remained unchanged while the robot still executed an action of the original category, but the actual displacement, turning extent, or execution duration changed with the locally received parameters. This indicates that the relevant parameters enter actual motion control rather than remaining as textual descriptions. Parameter range checking can limit the action magnitude, but it cannot determine whether the locally received value remains consistent with the original cloud value. If the two diverge, the robot may stop outside the expected position or change the planned motion trajectory. In scenarios with many obstacles, limited activity areas, or human-robot collaboration, such deviations increase the likelihood of collision, boundary violation, and task execution error.
On the Unitree G1 humanoid robot, the experiments mainly observed the effects of action type variation and action sequence variation on behavior. The study replaced a low-risk action in the original cloud response with another known safe action, or inserted an additional action after the original action, while keeping the session structure and response flow unchanged. The results show that when the action type is replaced and still belongs to the set of actions recognizable by the local program, the robot executes the replaced action. Considering the humanoid robot action execution process, action content includes not only individual action names but also the organizational relationships among actions. Changes in action type, action order, and action number can all alter the robot’s final behavior. When the robot operates in a human-environment interaction scenario, such changes may disrupt task execution order, trigger additional actions unexpectedly, or even produce limb movement that the user did not anticipate, leading to equipment damage, task failure, or personal injury.
These cases verify the same phenomenon across different robot forms within the embodied intelligence landscape: the robot’s final behavior depends on the locally received and locally parsed action content. Parameter modification affects action magnitude, action deletion affects whether an action occurs, action replacement and insertion affect action type and behavior sequence, and modifying only natural-language text does not directly change action execution. This shows that action semantic integrity involves not only parameter consistency but also whether action existence, action type, action order, and action number remain consistent. Once any of these elements undergoes unauthorized modification during transmission or parsing, the robot may execute behavior inconsistent with the original cloud decision even if the communication link remains legitimate and the action format is entirely correct. Ensuring action semantic integrity is therefore not merely a matter of communication consistency. It is a key security foundation for ensuring that robot behavior remains trustworthy, predictable, and verifiable.
- Scope limitations and interpretation boundaries
The study is careful to define what its findings do and do not establish. The communication observation and modification experiments were completed on authorized devices and in a controlled debugging environment. The environment used a controlled certificate trust configuration that allowed the test proxy node to observe, reassemble, and forward response content within the current legitimate session. This setup was used to construct a semantic difference between the original cloud action content and the locally received action content. It is not evidence that TLS or HTTPS protection can be bypassed under ordinary external network conditions.
The experiments did not break the vendor cloud authentication process, did not obtain third-party accounts, tokens, or sensitive data, and do not support the conclusion that a public-network attacker or ordinary network neighbor could directly modify communication with a real robot. The purpose of the modification step is not to demonstrate remote control or arbitrary code execution, but to verify the relationship between changes in action-bearing content and the robot’s final behavior.
Similarly, the local capability-chain observation should not be read as a claim that arbitrary DDS interfaces can be invoked. The study verified only low-risk capabilities such as volume settings, through message publish-subscribe matching and state-change verification. High-risk interfaces involving motion control, system execution, configuration writing, and low-level control were recorded only, without active invocation. The observation shows only that after action content is accepted locally, there is a possibility that it continues into part of the local capability chain.
The relationship between this work and existing ROS 2 and DDS security research also deserves clarification. Existing research mainly focuses on identity authentication, communication protection, access control, and configuration defects for nodes, participants, topics, and services. The core question there is whether a local capability interface can be accessed by an unauthorized principal. This study focuses instead on whether, within a legitimate cloud-to-robot session, action-bearing content remains consistent with the original cloud return before it enters the local parser. In the experiments, when action-bearing content was modified and still passed local parsing, the robot’s behavior changed according to the modified content. When only the natural-language feedback was changed while the original action content was preserved, the robot’s action did not change accordingly. This confirms that the actual execution result depends on the action content that the local program ultimately receives and parses. Once a large-model-issued instruction is tampered with on the link, it will affect the robot’s final execution state.
- Protective recommendations for securing embodied intelligence action pipelines
To reduce the risk described, the authors argue that a system should not rely solely on communication encryption, session isolation, and parameter range checking. It should also treat action-bearing content as an independent protection object. Five feasible mechanisms are proposed.
The first is to separate natural-language feedback from action objects, requiring the cloud to output structured action objects rather than mixing action content into free text. The second is to apply action-level signing or message authentication to action objects, binding together the action name, parameters, order, number, robot identity, session identifier, and time freshness. The third is to establish a hash chain for continuous actions so that action insertion, deletion, and reordering can be detected by the local runtime. The fourth is for the local program to perform a semantic policy check before execution, confirming that the action type, parameters, and action sequence conform to the current task and environmental constraints. The fifth is to implement least-privilege authorization at the local middleware layer, such as DDS, to limit the range of capabilities that action content can trigger.
These recommendations reflect the study’s core observation that existing protections address different layers of the embodied intelligence stack. Session isolation, syntax checking, and parameter limits offer meaningful protection, but they remain insufficient to fully guarantee that action content stays consistent before it enters local execution. Communication encryption protects data in transit, session isolation distinguishes connections, and format and parameter checks reject structurally erroneous or out-of-range actions. None of these mechanisms, however, can directly determine whether the action itself has been trimmed, replaced, or inserted when the modified content remains correctly formatted and within permitted parameter ranges.
- Conclusions and implications for embodied intelligence security
The study examines action semantic integrity in cloud large-model-driven embodied intelligence robots and analyzes the process by which cloud-returned content moves from the communication link into the local execution flow. Through network packet capture, man-in-the-middle modification, and local capability-chain observation, the research verifies the effect of changes in action-bearing content on the robot’s final behavior.
The experimental results show that the robot ultimately executes neither a single network packet nor ordinary natural-language text, but the action content that has been locally reassembled and parsed. Under conditions in which the current legitimate session remains valid, the action format is acceptable to the local program, and parameters remain within the safe range, deleting an action, modifying parameters, replacing an action, and inserting an action can all cause the robot’s behavior to deviate from the original cloud return result. When only the natural-language text is modified without changing the action-bearing content, the robot’s behavior is still determined by the action content.
This finding indicates that if action-level integrity verification is missing between cloud action content and local execution, the robot may still execute behavior inconsistent with expectations even when the communication session is valid and the action format is legitimate. Cloud large-model-driven robot systems should therefore, in addition to strengthening communication encryption, session management, and parameter limits, treat action-bearing content as an independent protection object, verify consistency between cloud-returned actions and locally executed actions, and constrain the range of local capabilities that action content can trigger.
The central conclusion is that robot safety depends not only on whether communication has been established and whether parameters are out of range, but also on whether the action content returned by the cloud remains complete before it enters local execution. For the emerging field of embodied intelligence, where model output is increasingly connected to physical actuation, this distinction between link-level security and action-level semantic integrity represents a meaningful shift in how safety boundaries should be drawn and verified.
The research was supported by the National Natural Science Foundation of China under project 62672277, the Qingdao Professional Technology Research and Industrialization Demonstration Project under 26-1-1-gjgg-30-gx, the Shandong Provincial Natural Science Foundation under ZR2026ZD40, and the Quancheng Laboratory under QCL20250106.