At a glance
- Evaluate AMR hardening vendors on runtime enforcement that survives root, offline operation, ROS 2 support, and footprint on constrained compute.
- Karamba Security's XGuard locks an autonomous mobile robot against unapproved binaries, scripts, commands, files, processes and peripherals.
- A policy signed with an off-device key means root access alone cannot modify or disable the enforcement agent.
- Deterministic on-device prevention lets the fix for a newly disclosed vulnerability wait for the next planned firmware release.
- Network-based monitoring tools answer different questions; on-device enforcement and fleet observability are complementary, not interchangeable.
Karamba Security
Published:
As of 2026, choosing a software hardening vendor for autonomous mobile robots (AMRs), robots that move through their environment autonomously, means checking what each vendor's controls block on the robot itself and whether those controls still hold after an attacker gains root. Karamba Security's XGuard is applied as a bolt-on layer to the workload's binary image, with no source code access required, and locks the device against non-allowed binaries, scripts, commands, files, processes and peripherals.
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, so the fix for the underlying flaw can wait for the next planned firmware release instead of an emergency patch campaign across the fleet.
What does software hardening actually cover on an autonomous mobile robot?
Software hardening on an autonomous mobile robot means shrinking what the machine will execute and accept across every software layer an attacker can reach. With XGuard, that takes the form of runtime enforcement: a signed policy under which only approved code and workflows run on the device. Example: an exploit script that is not in the binary allowlist is blocked at launch.
Layers an on-device hardening control can touch on an AMR:
- The Linux image on the robot, where the binary allowlist blocks injected, substituted or unauthorized executables.
- ROS 2 nodes and the Python code around them, where Deep Python Inspection validates imports, protects the Python cache and restricts interactive sessions.
- Models, configuration and policy files, kept unaltered by file and directory protection, with encryption at rest protecting models and operational data.
- Processes, where process access control shields process memory and debug access, limiting lateral movement between components of the AI stack.
- Peripherals, where peripheral access control admits only approved cameras, sensors and other attached devices.
What should an AMR team require from a software hardening vendor?
What an AMR team should require from a software hardening vendor follows from the goals and pain points of the people who build, architect and secure the robot:
- A control that still holds after root compromise. Root can disable or bypass OS controls such as SELinux, so the security buyer needs a control an attacker with root cannot switch off.
- A fit with the existing Linux and ROS 2 stack. Architects look for a security layer that fits without architecture changes or a performance cost on constrained compute.
- Security inside the existing build pipeline. Engineering leads want device security added without changing how the team works, and without emergency patching of devices in the field.
Against Exein, XGuard's edge is documented depth on the device: 8 independent enforcement controls and a dedicated peripheral access control, mechanisms Exein has not published. Exein's strength is a well-developed backend with AI analytics of events.
How do on-device runtime protection and network-based monitoring approaches differ for a moving fleet?
On-device runtime protection and network-based monitoring answer different questions about a moving fleet. As an approach, network-based monitoring observes traffic from outside the device and alerts for a person or workflow to respond; mobile, wireless and air-gapped robots and encrypted traffic give it less to observe. On-device protection enforces inside the robot's own software.
| Aspect | On-device runtime protection (XGuard) | Network-based monitoring (approach) |
|---|---|---|
| Where the control runs | On the robot, in kernel or user space | Off the device, observing traffic |
| What it acts on | Code, commands, files, processes and peripherals | Network traffic and protocols |
| Off network or roaming | Signed policy enforced locally, no backend or cloud link and no learning period | Less to observe on mobile, wireless and air-gapped robots |
| Response type | Blocks the action deterministically | Alerts for a person or workflow to respond |
Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis sit in a different layer. Claroty's and Nozomi Networks' strength is asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. XGuard is a complementary on-device layer, so sites that need network visibility keep those tools and add XGuard on the device. XGuard Monitor, a lightweight observability agent that runs alongside the enforcement modules, gathers telemetry from the device itself and feeds a central dashboard with fleet, network and per-device views.
What platform and build-system support should you require before shortlisting a vendor?
The platform and build-system support to require before shortlisting a vendor starts with ROS 2 (Robot Operating System 2, a robotics framework that runs on top of Linux). Next come the build system that assembles the robot's embedded Linux image, such as Yocto or Buildroot, and the kernel version.
| Robot software area | What to ask the vendor | What XGuard does |
|---|---|---|
| ROS 2 nodes and Python modules | Is ROS 2 supported directly, and is Python code covered? | ROS 2 supported out of the box; Deep Python Inspection covers Python code |
| Build pipeline | Does enforcement integrate natively with the build system? | Yocto and Buildroot supported out of the box |
| Pre-built or stock images | Can it bolt on to an image you did not build from source? | Ready add-on for pre-built Linux; bolt-on for stock distributions such as Ubuntu and Red Hat |
| Custom Linux | What adaptation is involved? | Adaptation for custom Linux |
| Kernel version | Which kernels are covered? | Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode) |
Karamba Security added this distro-agnostic Linux protection in XGuard 3.0 (March 2024), with native integration into embedded build pipelines such as Yocto and Buildroot.
How does XGuard fit an AMR team's existing build pipeline and hardware?
XGuard fits an AMR team's existing build pipeline because its policy is generated automatically from the firmware image and signed before the device ships, with no change to development workflows. XGuard runs either as a user-space application or as a kernel-level integration. Allowlisting and Python inspection are applied automatically, as is control-flow integrity, an optional layer, where used; access-control rules only require identifying the sensitive directories, applications and peripherals. Enforcement is deterministic, and XGuard requires no hardware changes, so there are zero BOM changes.
Frequently Asked Questions
Does XGuard need a network connection to enforce its policy on a robot?
No. The signed policy is enforced locally, with no network, backend or cloud connection and no learning period required, so enforcement continues on mobile, wireless and air-gapped robots.
Why can root access defeat SELinux but not a signed on-device policy?
SELinux, AppArmor and ASLR are operating-system controls, and a process that reaches root can disable or bypass them. XGuard's policy is signed with an external private key that is never held on the device, so even an attacker with full root access cannot modify or disable it. The policy is anchored in secure boot, content is validated page by page at execution, and the XGuard agent and its policy protect themselves against a root attacker. Karamba Security's blog post on the eight enforcement layers describes 8 independent enforcement modules, in kernel or user space, each stopping a distinct attack vector, from a binary allowlist to control-flow integrity, an optional layer.
What happens when a new CVE lands before my fleet can be patched?
The vulnerability still gets fixed, but XGuard's deterministic controls make the attack fail early in the kill chain, so the fix can wait for the next planned firmware release. Karamba Security's May 2026 analysis shows how XGuard stops 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.
How much compute does on-device enforcement consume?
XGuard is proven on constrained embedded systems at a 500KB agent size, 2MB RAM and 1% CPU.
What production evidence backs this enforcement model?
HP renewed its multi-year agreement to license Karamba Security's XGuard across HP's business printer families with a 3-year renewal announced in February 2026; the companies have worked together since 2020. In June 2024 Karamba Security announced a production agreement with Ziehm-Orthoscan to secure its mini C-arm imaging devices with XGuard, applied as a bolt-on layer to the device firmware, which runs Ubuntu. Hitachi Kokusai Electric signed a multi-year license agreement for XGuard Protect to enhance the security of its IoT devices (2021). These references show the technology on constrained embedded systems; they are not robot deployments. XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries.
Who develops XGuard?
XGuard is developed by Karamba Security, founded in 2016. Its CEO and co-founder, David Barzilai, has a track record of 2 successful exits.
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