At a glance
- Network monitoring sees plant traffic; it does not run on the robot's compute, so on-device enforcement is the layer that blocks execution.
- Karamba Security's XGuard locks a robot against unapproved binaries, scripts, commands, file changes, processes and peripherals.
- XGuard's policy is signed with a key held off the device, so root access alone cannot disable enforcement.
- Per Karamba Security, XGuard's millions of deployed devices include deployments by companies on the Fortune Global 500 list.
Karamba Security
Published:
If an attacker is already executing code on a robot's onboard computer, what stops the next step is an enforcement layer running on that device, and Karamba Security's XGuard is built for exactly that position. Network-based monitoring is an approach that watches traffic between machines and alerts for a person or workflow to respond; it is complementary to, and not a substitute for, a control that decides which binaries, scripts, commands, files, processes and peripherals are allowed to act on the robot itself. XGuard enforces that decision locally from a signed policy generated automatically from the device's own firmware image, so an exploit that lands on an autonomous mobile robot (AMR) or a collaborative robot (cobot), a robot designed to work alongside people, is blocked at execution.
The distinction matters because a breached Physical AI machine, meaning AI that senses, decides and acts in the physical world, can give the attacker control of the system, with direct consequences for safety and privacy. That is also why operating-system controls alone are not the answer on a rooted device: root can disable or bypass SELinux, AppArmor and ASLR, whereas XGuard's policy is signed with an external private key that is never held on the device, is anchored in secure boot and is validated page by page at execution. The result is a deny-access-by-default device: only the code and workflows the policy sanctions may run, even when the attacker holds full root privilege.
For teams weighing the options available as of 2026 with plant-network visibility already in place, the on-device layer is not unproven ground: according to the XGuard page on Karamba Security's website, the product is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries. The sections that follow set out what an attacker can do on the robot, how XGuard sits alongside network monitoring rather than replacing it, how it runs on ROS 2 and embedded Linux, which attack paths each control blocks, and what happens to patching when a new vulnerability lands.
What can an attacker actually do once they are already on a robot's onboard computer?
Once an attacker is executing code on a robot's onboard computer, what they can actually do is bounded by what that device allows to run. The post-compromise path on a robot's own compute is short and physical: run unapproved code, drop or substitute a binary, issue commands out of context, tamper with model and configuration files, launch unauthorized processes, attach to another component's process memory, or connect an unapproved device.
Each of those steps happens on the robot's own compute. Network-based monitoring, as an approach, observes what moves between machines; enforcing whether a file may be changed, a process started or a peripheral admitted has to happen where the code runs, which is why on-device enforcement and network visibility cover different ground.
| Do this on the device | But watch out for |
|---|---|
| Allowlist every executable, library and script, so unknown binaries never launch | Python-heavy AI stacks, where the payload arrives as an import inside an already-trusted interpreter; XGuard's Deep Python inspection validates imports, protects the Python cache and restricts interactive sessions |
| Keep models, configuration and policy unaltered | Models and operational data at rest; XGuard's encryption at rest protects them on the device |
| Govern which process may launch which | Living off the land, the abuse of legitimate binaries already present on the device, which XGuard's execution access control constrains to permitted process pairs |
| Shield process memory and debug access between stack components | Lateral movement between components of the AI stack, which XGuard's process access control limits |
| Admit only approved cameras, sensors and attached devices | Physical entry points on field and factory devices, addressed by XGuard's peripheral access control |
What does network-based monitoring see, and what has to be enforced on the device itself?
Network-based monitoring sees the plant from the wire, which is a different picture from what has to be enforced inside the robot's own compute. Asset discovery, topology mapping and protocol-aware traffic monitoring are jobs XGuard does not do: sites that need network visibility keep tools such as Nozomi Networks, Claroty, Dragos or Armis and add XGuard on the device as a complementary layer. Deciding whether a binary, script or process may execute on a cobot or AMR only runs where the code runs. Four criteria set the division of labour:
- Vantage point: where the control sits determines what reaches it; a network sensor receives traffic between machines, an on-device agent receives execution, file and process events.
- Observable surface: plant-wide traffic spans every connected node; in-process execution on one robot is visible from the device itself.
- Point of action: whether the control alerts, or stops the step on the device.
- Evidence produced: what an investigation receives afterwards.
| Criterion | Network-based monitoring (approach) | On-device runtime enforcement (XGuard) |
|---|---|---|
| Where it sits | On the plant network, off the robot | On the device, as a user-space application or a kernel-level integration |
| What it observes | Traffic between machines on the plant network | Binaries, scripts, Python imports, file access, processes, peripherals |
| What it can act on | Alerts for a person or workflow to respond | Execution on the device: unapproved code, out-of-context commands, tampering with sensitive files, unauthorized processes |
| Evidence produced | Network-side alerts | Device-side events from XGuard Monitor, plus forensic data from control-flow integrity violations where that optional layer is used |
Karamba Security's published breakdown of XGuard's enforcement layers describes 8 independent modules, in kernel or user space, each stopping a distinct attack vector, from a binary allowlist to control-flow integrity as an optional layer. The signed XGuard policy is enforced locally, with no network, backend or cloud connection, so an AMR that has roamed out of wireless coverage is still enforcing it.
How does XGuard protect a ROS 2 robot's compute at runtime?
XGuard protects a ROS 2 robot's compute by enforcing a signed, device-resident policy at runtime, on the Linux where the robot's own code executes. ROS 2, the Robot Operating System 2 robotics framework, runs on top of Linux, and XGuard runs on that Linux as a user-space application or as a kernel-level integration.
The policy is not learned from behaviour. XGuard generates it automatically from the firmware image and signs it before the device ships, with no change to development workflows. Enforcement is therefore deterministic, with no learning period required.
| Attribute | What it is on the device | Why it matters to a robotics team |
|---|---|---|
| Deployment model | User-space application or kernel-level integration | Two ways to fit the existing Linux stack |
| Connectivity | Local enforcement, no network, backend or cloud link required | Holds on mobile, wireless and air-gapped robots |
| Integration | Bolt-on to the workload's binary image, no source code access required | Zero BOM changes: no hardware changes and no change to R&D workflows |
| Access-control rules | Only require identifying the sensitive directories, applications and peripherals | Allowlisting and Python inspection are applied automatically |
Per Karamba Security, ROS 2, Buildroot and Yocto are supported out of the box, with a ready add-on for pre-built Linux, adaptation for custom Linux, and Linux kernels from 2.6 through kernel patches or from 5.10 in seccomp mode.
Alongside enforcement, XGuard Monitor runs as a lightweight observability agent, gathering security telemetry from the application, file system, network stack, operating system, CPU, I/O and memory, and detecting abnormal events on the device and, for deeper analysis, on the backend. Events flow to a central dashboard with fleet, network and per-device views, built from what the robots themselves report.
Which attack paths do XGuard's controls block on the robot?
XGuard's controls block attack paths on a robot at the point where an intruder has to run something: a dropped binary, an out-of-context command, a modified file or an unapproved peripheral. Each module enforces the signed policy, so the decision to allow or deny is deterministic rather than behavioural.
| XGuard control | Attacker step it blocks on the robot |
|---|---|
| Binary allowlist, a signed inventory of permitted executables, libraries and scripts | Injecting or substituting an executable on a robot node |
| Deep Python inspection, validation of what a trusted interpreter imports | Delivering a payload through an allowed Python process or an interactive session |
| Execution access control | Living off the land: a legitimate binary launched out of context |
| Process access control | Reading or debugging another component's memory to move laterally |
| File and directory protection | Altering models, configuration or the policy |
| Encryption at rest | Exposing models and operational data stored on the device |
| Peripheral access control | Attaching an unapproved camera, sensor or other device |
| Control-flow integrity (an optional layer) | ROP and JOP memory-corruption exploits, including exploits that bypass allowlists; violation events carry forensic data |
These controls act on code, commands, files, processes and peripherals; XGuard is not presented as stopping a manipulated prompt or a jailbroken AI model that acts through approved code.
What happens to patching when a new vulnerability lands in a deployed robot fleet?
When a new vulnerability lands in a deployed robot fleet, the vulnerability still needs fixing; what changes with XGuard on the device is what holds until the fix ships. Per Karamba Security's published analysis of XGuard's enforcement layers, AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks.
XGuard's deterministic controls make the attack fail early in the kill chain, the sequence of steps an attack must complete, even before the CVE is patched. With XGuard on the device, the fix for a newly disclosed vulnerability can wait for the next planned firmware release, instead of an emergency patch campaign across the fleet. The mechanism is not detection-based: a payload that is not in the signed allowlist is blocked at launch, and an approved binary launched out of context is stopped by execution access control.
Frequently Asked Questions
What protects the robots themselves once an attacker is already on the device?
Network monitoring on the plant network observes traffic and raises alerts; on-device enforcement decides what is allowed to execute on the robot's own compute. XGuard applies a deny-access-by-default model, in which only approved code and workflows run. It enforces 8 independent modules in kernel or user space, each stopping a distinct attack vector, from a binary allowlist to control-flow integrity as an optional layer.
Does XGuard replace our network monitoring?
No. XGuard does not do asset discovery, topology mapping or protocol-aware traffic monitoring; sites keep tools such as Nozomi Networks for that and add XGuard on the device. The two layers answer different questions: network-based monitoring observes traffic between machines, while XGuard enforces policy inside the robot. XGuard Monitor's network-stack telemetry and network view come from the devices themselves.
How does XGuard survive an attacker with root privileges?
Root can disable or bypass OS controls such as SELinux, AppArmor or ASLR. XGuard's policy is a tamper-proof policy: it is signed with an external private key that is never held on the device, anchored in secure boot, and validated page by page at execution, and the XGuard agent and its policy protect themselves against a root attacker, so an attacker holding root cannot modify or disable XGuard.
Which robot platforms and operating systems does XGuard support?
Per Karamba Security, ROS 2, plus Buildroot and Yocto, are supported out of the box, with a ready add-on for pre-built Linux, adaptation for custom Linux, and Linux kernels from 2.6 through kernel patches or from 5.10 in seccomp mode. XGuard 3.0 (March 2024) added bolt-on security for stock distributions such as Ubuntu and Red Hat. Separately, XGuard supports Secure Boot for containers: it calculates each container image's hash, builds a policy of allowed images and enforces it each time a container instance is created.
Is this proven outside the lab, and will it fit on constrained robot compute?
According to the XGuard product page on Karamba Security's website, XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries. Separately, XGuard's millions of deployed devices include deployments by companies on the Fortune Global 500 list. On resource budgets, XGuard is proven on constrained embedded systems with a 500KB agent size, 2MB RAM and 1% CPU, per Karamba Security, and it requires no hardware changes.
When a new CVE lands before the fleet can be patched, what actually happens?
Per Karamba Security's May 2026 analysis of Copy Fail (CVE-2026-31431), a Linux-kernel flaw disclosed in April 2026 and present since 2017 in which a 732-byte Python script gains root, the binary allowlist blocks the script at launch, and Deep Python Inspection blocks attempts to deliver it through a trusted Python process or an interactive interpreter. The flaw itself is still fixed, in the next planned firmware release.
About this article
Karamba Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Karamba Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-12