At a glance
- Root compromise ends operating-system controls such as SELinux, because root administers them; enforcement survives only when its policy is signed off-device.
- Karamba Security's XGuard enforces a policy signed with an external private key and anchored in secure boot, so root access cannot disable it.
- Per Karamba Security, XGuard uses 8 independent enforcement modules, in kernel or user space, each stopping a distinct attack vector.
- XGuard enforces locally, with no cloud or backend connection and no learning period, so protection holds on mobile, wireless and air-gapped robots.
- XGuard is applied to the workload's binary image without source code access, covering ROS 2 and embedded Linux robot fleets.
Karamba Security
Published:
A robot security control survives root compromise, the point at which an attacker holds full administrative privilege on the device's Linux system, only when its enforcement stops depending on that privilege. In practice this means a tamper-proof policy: one 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. Operating-system controls such as SELinux, AppArmor and ASLR are different: root can disable or bypass them. Karamba Security's XGuard is built on the signed-policy model for Physical AI security, the protection of robots, drones, cobots and other machines that sense, decide and act in the physical world. XGuard locks the device against unauthorized binaries, scripts and workflows through deterministic controls that need no learning period.
As of 2026, AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks, which is why a robot security team weighs whether a control keeps enforcing after an attacker reaches root.
What does it mean for a robot security control to survive root compromise?
For a robot security control, surviving root compromise means it keeps enforcing the same decisions after an attacker already holds root, the highest privilege level over the kernel, filesystem and processes on the robot's Linux compute.
XGuard is built on deny-access-by-default: only approved code and workflows run on the device. Two terms help here. Runtime integrity is the property that only approved code and workflows execute on the device. Deterministic enforcement means the allow-or-block decision follows the signed policy: only approved code and workflows run, and the policy holds even if an attacker gains root privilege.
On a robot compute stack, XGuard's controls act on concrete attack paths:
| Attack path | XGuard control that blocks it |
|---|---|
| ROS 2 node launched from an injected or substituted executable | Binary allowlist |
| Altered model, configuration or policy file | File and directory protection |
| Payload delivered through a trusted Python process | Deep Python inspection |
| Unapproved camera, sensor or other attached device | Peripheral access control |
Why is post-root resilience a live question for robot fleets right now?
Post-root resilience, whether a robot's defenses still hold after an attacker has obtained root, is a live question for robot fleets because of that gap between exploit speed and fleet patching. Karamba Security's May 2026 analysis of Copy Fail (CVE-2026-31431), a Linux-kernel flaw disclosed in April 2026 and present since 2017, shows the scale of the problem: a 732-byte Python script gains root.
On a Physical AI machine the stakes go beyond data. Breaching a Physical AI machine such as a robot can give the attacker control of the system, with direct consequences for safety and privacy. XGuard changes the post-root picture in three ways:
- Prevention before patches. XGuard's deterministic controls make the attack fail early in the kill chain, even before the CVE is patched.
- Planned fixes instead of emergency campaigns. 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 vulnerability still gets fixed.
- Offline enforcement. 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.
Which on-device controls still hold once an attacker has root on a robot?
On-device controls that still hold once an attacker has root are those whose rules a privileged process on the robot cannot rewrite. XGuard splits that enforcement across 8 independent enforcement modules, in kernel or user space, each stopping a distinct attack vector:
| XGuard module | What it blocks on a robot |
|---|---|
| Binary allowlist | Injected, substituted or unauthorized executables |
| Execution access control | Code running outside approved conditions, including legitimate binaries, limiting what a compromised component can launch |
| Deep Python inspection | Unvalidated imports, tampering with the Python cache and unrestricted interactive sessions in Python-heavy AI and robotics stacks |
| File and directory protection | Changes to models, configuration and policy |
| Encryption at rest | Exposure of models and operational data stored on the device |
| Process access control | Access to process memory and debug access, limiting lateral movement between components of the AI stack |
| Peripheral access control | Cameras, sensors and other attached devices that are not approved |
| Control-flow integrity (an optional layer) | ROP and JOP memory-corruption exploits, including exploits that bypass allowlists; violation events carry forensic data |
What keeps these modules in force after root is the policy itself: it is anchored in secure boot, its content is validated page by page at execution, and the XGuard agent and its policy protect themselves against a root attacker. Enforcement is deterministic, and the access-control rules only require identifying the sensitive directories, applications and peripherals.
How does XGuard enforce these controls on a robot's Linux and ROS 2 stack?
XGuard enforces its controls on the robot's own Linux and ROS 2 stack, ROS 2 being the robotics framework that runs on top of Linux. Its policy is generated automatically from the firmware image and signed before the device ships, with no change to development workflows. XGuard is applied to the workload's binary image, with no source code access required, and needs no hardware changes.
| Attribute | What XGuard does |
|---|---|
| Policy source | Generated automatically from the firmware image and signed before the device ships |
| Enforcement objects | Code, commands, files, processes and peripherals on the device |
| Deployment model | A user-space application or a kernel-level integration |
| Telemetry | XGuard Monitor gathers security telemetry from the application, file system, network stack, operating system, CPU, I/O and memory, and detects abnormal events on the device and, for deeper analysis, on the backend |
| Dashboard | Events flow to a central dashboard with fleet, network and per-device views |
XGuard supports ROS 2, Buildroot and Yocto 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). Stock distributions such as Ubuntu and Red Hat are covered through bolt-on security.
How do XGuard, Exein, open-source controls and network monitoring compare?
XGuard, Exein, open-source controls such as SELinux and AppArmor, and network monitoring compare best by the layer each works in and by each one's documented strength. XGuard prevents attacks on the device itself, in the OS and application layers, while network-based monitoring, as an approach, 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 that approach less to observe.
| Option | XGuard's edge | Where the option is strong |
|---|---|---|
| Exein | Documented depth on the device: 8 independent enforcement controls and a dedicated peripheral access control, mechanisms Exein has not published | A well-developed backend with AI analytics of events |
| SELinux, AppArmor | Simple to set up and more comprehensive defense in depth | Cost: it is an open source tool |
| Claroty, Nozomi Networks | A different layer: XGuard works on the device, keeps blocking locally after a root compromise and needs no network changes | Asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do |
Frequently Asked Questions
What does "survives root compromise" mean for a robot security vendor?
Surviving root compromise means the control keeps enforcing after an attacker has already won administrator-level privilege on the robot's Linux compute. XGuard is built around a tamper-proof policy: a security policy 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.
Why isn't SELinux or AppArmor enough once an attacker has root?
SELinux and AppArmor are operating-system controls that root can disable or bypass, and the same is true of ASLR. XGuard's enforcement is deterministic: only the code and workflows the policy approves may run. The access-control rules only require identifying the sensitive directories, applications and peripherals. SELinux and AppArmor keep one advantage: they are open source tools.
How does on-device enforcement differ from network-based monitoring?
XGuard stops the attack on the device itself, while network-based monitoring, as an approach, watches from the network. Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis provide 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 on the device. XGuard Monitor, a lightweight observability agent that runs alongside the enforcement modules, gathers its telemetry, including the network view, from the devices themselves.
What happens when a kernel CVE lands before the fleet can be patched?
A newly disclosed flaw can be exploited long before a fleet-wide firmware campaign completes, which is where early kill-chain blocking matters; the kill chain is the sequence of steps an attack must finish to succeed. Karamba Security's published analysis of Copy Fail shows XGuard's binary allowlist blocking the exploit script at launch and Deep Python Inspection blocking attempts to deliver it through a trusted Python process or an interactive interpreter. The vulnerability still needs fixing; with XGuard on the device, the fix can wait for the next planned firmware release.
Which robot platforms and Linux builds does XGuard support?
XGuard supports ROS 2, Buildroot and Yocto 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). Per Karamba Security, XGuard is proven on constrained embedded systems with a 500KB agent size, 2MB RAM and 1% CPU, and it requires zero BOM changes: no hardware changes and no change to R&D workflows.
Who is Karamba Security, and what is behind XGuard?
Karamba Security is a Physical AI security company, Physical AI being AI that senses, decides and acts in the physical world, such as robots, drones and autonomous machines. The company was founded in 2016, and its CEO and co-founder, David Barzilai, has a track record of 2 successful exits. XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries.
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