At a glance
- Karamba Security's XGuard blocks unapproved binaries, scripts and workflows directly on the robot, with enforcement that persists even against an attacker holding root.
- Its policy is signed off-device and enforced locally, so protection works offline on mobile, wireless and air-gapped robots.
- Deep Python inspection covers Python-heavy robotics and AI stacks that binary-level allowlisting alone would miss.
- Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis address a different layer and remain complementary to on-device enforcement.
Karamba Security
Published:
As of 2026, Karamba Security's XGuard is an on-device option that blocks unapproved binaries and scripts on the robot itself, even when your AI software ships onto robots you do not own or operate. For a software supplier, what matters is who can switch the control off. Root can disable or bypass operating-system controls such as SELinux, AppArmor or ASLR. 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 XGuard.
Karamba Security's May 2026 analysis shows how this works against a live flaw: 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. XGuard's 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.
This matters because, according to Karamba Security, AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks. 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.
Where does XGuard's on-device layer sit next to other security tools on a robot?
XGuard's on-device layer runs on the robot's own compute and blocks unapproved binaries and scripts there. Karamba Security focuses on Physical AI security, the part of cyber-physical systems (CPS) security that protects robots, drones and autonomous machines. XGuard comprises 8 independent enforcement modules in kernel or user space, each stopping a distinct attack vector, from a binary allowlist to control-flow integrity (CFI), an optional layer that enforces a program's legitimate call graph at runtime and blocks code-reuse exploits such as ROP and JOP. Against Exein, XGuard's edge is documented depth on the device, including those 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.
Claroty and Nozomi Networks work at a different layer: their strength is asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. XGuard is a complementary on-device layer: sites that need network visibility keep those tools, or others in the same class such as Dragos and Armis, and add XGuard on the device.
How does on-device enforcement differ from network-based monitoring for a robot fleet?
On a robot fleet, on-device enforcement blocks unapproved code at execution on the robot, while network-based monitoring, as an approach, observes traffic from outside the device.
| Criterion | On-device runtime enforcement (XGuard) | Network-based monitoring approach |
|---|---|---|
| Where the control runs | On the robot itself, in kernel or user space | Outside the device, observing traffic |
| When unapproved code starts | XGuard blocks the unapproved binary or script at execution | Traffic is observed and an alert goes to a person or workflow to respond |
| What it acts on | Code, commands, files, processes and peripherals on the device | Network traffic |
How is an XGuard policy built and enforced on the robot?
An XGuard policy is generated automatically from the firmware image and signed before the device ships, with no change to development workflows. XGuard is applied as bolt-on security to the workload's binary image, with no source code access required. 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 each XGuard control blocks on the robot:
- Binary allowlist — injected, substituted or unauthorized executables on devices and nodes.
- Deep Python Inspection — validates imports, protects the Python cache and restricts interactive sessions, covering code that binary controls would miss in Python-heavy AI and robotics stacks.
- Execution access control — which code may run and under what conditions, including legitimate binaries, limiting what a compromised component can launch.
- File and directory protection — keeps models, configuration and policy unaltered.
- 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.
- Encryption at rest — protects models and operational data on the device.
XGuard runs as a user-space application or as a kernel-level integration, and it requires no hardware changes: zero BOM changes.
Which robot platforms and runtimes does XGuard cover?
XGuard covers Linux in general, with ROS 2 first. 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). ROS 2 (Robot Operating System 2) is a robotics framework that runs on top of Linux. 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 (September 2024): it calculates each container image's hash, builds a policy of allowed images and enforces it each time a container instance is created.
What does XGuard need from R&D, and how large is its footprint?
XGuard is transparent to R&D: allowlisting and Python inspection are applied automatically, as is the optional CFI layer where used, and access-control rules only require identifying the sensitive directories, applications and peripherals.
- Footprint. XGuard is proven on constrained embedded systems: 500KB agent size, 2MB RAM, 1% CPU.
- Production scale. XGuard runs on millions of deployed embedded devices, and Karamba Security adapts that production-proven technology to Physical AI.
Frequently Asked Questions
Why does a breach of a robot matter more than a data breach?
Breaching a Physical AI machine can give the attacker control of the system, with direct consequences for safety and privacy. Physical AI, Karamba Security's focus market, is AI that senses, decides and acts in the physical world: robots, drones, unmanned vessels and autonomous machines. XGuard locks the device against unauthorized binaries, scripts or workflows, so an exploit that tries to run unapproved code, issue commands out of context or tamper with sensitive files is blocked on the device.
How does on-device enforcement stop an exploit for a vulnerability that is still unpatched?
Enforcement acts on execution, not on the vulnerability: XGuard's deterministic controls make the attack fail early in the kill chain, even before the CVE is patched.
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-15