At a glance
- You can add on-device runtime protection to third-party robots without firmware source code, because the policy is derived from the shipped binary image.
- Karamba Security's XGuard enforces 8 independent controls that root access cannot switch off, blocking unapproved binaries, scripts, commands, files and peripherals.
- Ask each vendor whether enforcement is deterministic, offline-capable, signed outside the device, and installable without rebuilding the robot vendor's OS.
- Network-based monitoring tools answer different questions: asset discovery and traffic analysis complement, rather than replace, on-device prevention.
Karamba Security
Published:
If your team trains applications on robots it does not build, the on-device security vendors to evaluate are runtime-enforcement vendors such as Karamba Security, whose XGuard is applied to the robot's binary image, and Exein; ask each one where enforcement runs, whether root can change the policy, whether it works offline and what it needs from your build. XGuard locks a Physical AI device (a machine that senses, decides and acts in the physical world: robots, drones, unmanned vessels, autonomous machines) against non-allowed binaries, actions and workflows, using 8 independent enforcement modules in kernel or user space, according to Karamba Security's published explanation of its eight enforcement layers. Network-monitoring platforms work at a different layer and complement an on-device control rather than compete with it.
The timing question is what makes this urgent as of 2026. Per Karamba Security, 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 a newly disclosed vulnerability can wait for the next planned firmware release instead of an emergency patch campaign across the fleet.
What does adding security on-device mean for robots you train but don't build?
Adding security on-device means placing an enforcement layer on the robot itself, so the device decides at runtime which code, commands, files, processes and peripherals are permitted. For a team that does not own the firmware, XGuard is applied seamlessly to the workload's binary image.
The XGuard policy is generated automatically from the firmware image and signed before the device ships. The 8 enforcement modules each stop a distinct attack vector:
- Binary allowlist — blocks injected, substituted or unauthorized executables on devices and nodes.
- Deep Python inspection — validates imports, protects the Python cache and restricts interactive sessions in Python-heavy AI and robotics stacks.
- Encryption at rest — protects models and operational data on the device.
- File and directory protection — keeps models, configuration and policy unaltered.
- Execution access control — governs which code may run, and under what conditions, including legitimate binaries.
- Process access control — shields process memory and debug access, limiting lateral movement between components of the AI stack.
- Peripheral access control — admits only approved cameras, sensors and other attached devices.
- Control-flow integrity (CFI) — an optional layer inside the binaries that stops ROP and JOP memory-corruption exploits deterministically.
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.
What should you ask an on-device security vendor?
Ask an on-device security vendor the same short set of questions about where enforcement runs, who can change the policy and what the vendor needs from your build. The right-hand column gives XGuard's answer to each.
| Question to ask the vendor | XGuard's answer |
|---|---|
| Where does enforcement run? | On the robot itself, as a user-space application or a kernel-level integration, enforcing a signed policy locally |
| Can an attacker with root change or disable the policy? | No: the signed policy is anchored in secure boot, and the XGuard agent and its policy protect themselves against a root attacker (details in the root-access row below) |
| Does enforcement keep working offline? | Yes: no network, backend or cloud connection and no learning period required |
| What does it need from our build? | The workload's binary image only: no source code access, no hardware changes (zero BOM changes) and no change to R&D workflows |
| What does each control block? | Each of the 8 independent enforcement modules stops a distinct attack vector, listed above |
| What does it cost on constrained compute? | 500KB agent size, 2MB RAM, 1% CPU on constrained embedded systems |
| Which Linux stacks are covered? | ROS 2, Buildroot and Yocto out of the box; see the platform table below |
Put the same questions to Exein. Against Exein, Karamba Security's comparison point is documented depth on the device, covered in the next section.
How does on-device enforcement compare with Exein and with network-monitoring platforms such as Claroty and Nozomi Networks?
On-device enforcement from XGuard is compared head-on with Exein, while network-monitoring platforms such as Claroty and Nozomi Networks sit at a different layer and complement it. Against Exein, XGuard's edge is documented depth on the device: 8 independent enforcement controls, a dedicated peripheral access control, and a policy signed with an external key that root access cannot switch off, mechanisms Exein has not published. Exein's strength is a well-developed backend with AI analytics of events.
Claroty and Nozomi Networks win on asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. Sites that need network visibility keep those tools and add XGuard as a complementary on-device layer. The difference is one of approach:
| What differs | XGuard on-device enforcement | Network-based monitoring (approach) |
|---|---|---|
| Layer | Inside the device, in the OS and application layers | Observes traffic from outside the device |
| What it acts on | Code, commands, files, processes and peripherals on the device | Traffic between machines |
| Response | Blocks the action on the device, and keeps blocking locally after a root compromise | Alerts for a person or workflow to respond |
| Role on site | Added on the device, with no network changes | Kept by sites that need network visibility |
Which Linux stacks does XGuard support on a robot?
XGuard supports Linux stacks on a robot with ROS 2 first: ROS 2, Buildroot and Yocto are supported out of the box, with a ready add-on for pre-built Linux and adaptation for custom Linux.
| Stack on the robot | XGuard support |
|---|---|
| ROS 2 on Linux | Supported out of the box |
| Yocto or Buildroot | Supported out of the box, with native integration into Yocto and Buildroot pipelines |
| Pre-built Linux | A ready add-on for pre-built Linux |
| Stock distributions such as Ubuntu and Red Hat | Bolt-on security, added in XGuard 3.0 |
| Custom Linux | Adaptation for custom Linux |
| Older or newer kernels | Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode) |
XGuard runs either as a user-space application or as a kernel-level integration. Per Karamba Security's March 2024 announcement of XGuard 3.0, the release added distro-agnostic Linux protection.
For containerized applications on the device, XGuard's Secure Boot for containers, announced in September 2024, calculates each container image's hash, builds a policy of allowed images and enforces it each time a container instance is created.
How does XGuard handle root access, false positives and patch timing?
On root access, false positives and patch timing, XGuard relies on a signed policy, deterministic enforcement and controls that make the attack fail early in the kill chain:
| Concern | What XGuard does |
|---|---|
| Root access | The policy is signed with an external private key that is never held on the device and is anchored in secure boot, so even an attacker with full root access cannot modify or disable XGuard |
| Policy and false positives | Enforcement is deterministic and the policy is generated from the device's own image; allowlisting and Python inspection are applied automatically, and access-control rules only require identifying the sensitive directories, applications and peripherals |
| A newly disclosed CVE | The controls make the attack fail early in the kill chain, so the fix can wait for the next planned firmware release |
| Security events | XGuard Monitor detects 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 |
Open-source controls such as SELinux, AppArmor and IMA have one clear strength: they are open source tools. XGuard's edge over them is that it is simple to set up, gives more comprehensive defense in depth, and root access can't tamper with its security policy, whereas SELinux and AppArmor can be disabled or bypassed by an attacker who reaches root.
Frequently Asked Questions
Does on-device enforcement replace our OT network monitoring?
No. XGuard does not do asset discovery, topology mapping or protocol-aware traffic monitoring, so sites that need network visibility keep those tools and add XGuard on the device.
Can XGuard stop an attack that uses a newly disclosed vulnerability?
XGuard's controls stop exploits of known or zero-day vulnerabilities from running unapproved code, issuing commands out of context, tampering with sensitive files or launching unauthorized processes.
What production track record does XGuard have?
Per Karamba Security, XGuard is deployed on millions of devices. According to Karamba Security's February 2026 press announcement, HP renewed its multi-year agreement to license XGuard across HP's business printer families with a 3-year renewal, and the two companies have worked together since 2020. HP's Shivaun Albright, Chief Technologist for Print Security, said: "Security remains a top priority for HP as our customers face increasingly sophisticated adversaries. Karamba Security's XGuard software delivers reliable runtime protection, helping our customers safeguard their printers against a broad range of cyberattacks, such as file-based and file-less malware."
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. Both are deployments of the technology on constrained embedded systems.
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