At a glance
- On-device runtime enforcement blocks unauthorized binaries, scripts and processes at launch; network-based monitoring is a complementary approach that observes and alerts.
- Karamba Security's XGuard enforces a signed policy locally, so an attacker holding root access cannot modify or disable the controls.
- Check offline operation: XGuard's signed policy is enforced on the device with no cloud, backend or learning period.
- Check platform fit early: ROS 2, embedded Linux, container images, and whether integration demands source code access.
- Work the rest of the checklist: Python coverage, footprint on constrained compute, and evidence from production devices.
Karamba Security
Published:
Vendors that block unauthorized processes on robots work in one place: on the device, where a runtime enforcement agent decides whether a given binary, script or process may execute at all and stops the attack on the robot's own compute. Network-monitoring platforms such as Claroty and Nozomi Networks, and others in that class such as Dragos and Armis, are a different layer: they observe traffic from outside the device, and an on-device control complements them rather than replacing them. Karamba Security's XGuard is an on-device control. It locks a Physical AI device — a robot, drone, humanoid or other autonomous system that senses, decides and acts in the physical world — against non-allowed binaries, actions and workflows, and its 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. This article is a checklist for working through the options available as of 2026, one check per section, with what a good result looks like. Platform coverage is one of the first checks, and on that point XGuard 3.0 added distro-agnostic Linux protection in March 2024, according to Karamba Security's release announcement: native integration into embedded build pipelines such as Yocto and Buildroot, plus bolt-on security for stock distributions such as Ubuntu and Red Hat. XGuard is applied to the workload's binary image, with no source code access required.
What does "blocking unauthorized processes on a robot" actually mean on the device itself?
Blocking unauthorized processes on a robot means that code which is not in the device's approved inventory is refused at launch — the execution attempt fails, rather than being recorded and reviewed afterwards. The phrase is used for two different approaches, and they act at different points in the attack.
Network-based monitoring. As an approach, network-based monitoring observes a robot from outside the device and raises alerts for a person or a response workflow to act on.
On-device runtime process control. Enforcement sits in the robot's own operating system and decides, at the moment of execution, whether a given binary, script or interpreter session is permitted. A dropped exploit script fails at launch with no network, backend or cloud connection involved. This article uses this second meaning throughout.
On a Linux or ROS 2 robot, that control surface covers more than executables:
- Allowlisted executables and libraries — a binary allowlist, meaning a signed inventory of every executable, library and script permitted to run, blocks injected, substituted or unauthorized executables on devices and nodes.
- Scripts and interpreters — in Python-heavy AI and robotics stacks, XGuard's Deep Python Inspection validates imports, protects the Python cache and restricts interactive sessions, covering code that binary controls would miss.
- Process relationships and context — execution access control governs which code may run, and under what conditions, which constrains living-off-the-land attacks that abuse legitimate binaries already on the device.
- Process memory and debug access — process access control limits lateral movement between components of the AI stack.
- Attached devices — peripheral access control admits only approved cameras, sensors and other attached devices.
According to Karamba Security's published May 2026 analysis, 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.
Have you checked whether the control enforces on the robot or only reports from the network?
When you have checked a vendor's architecture, confirm whether the control actually blocks execution on the robot itself or observes traffic from the network and raises an alert. On-device runtime enforcement means the policy is evaluated in the robot's own kernel or user space at the moment a binary, script or process tries to run, and the attempt fails there. Network-based monitoring is a different approach, and asset discovery, topology mapping and protocol-aware traffic monitoring remain the work of network tools such as Claroty and Nozomi Networks, which XGuard does not do.
XGuard enforces its signed policy locally on the device, with no network, backend or cloud connection and no learning period required, so enforcement continues on mobile, wireless and air-gapped robots.
| Check this | What a good answer looks like |
|---|---|
| Where the allow/deny decision is made | On the device, in kernel or user space, without a cloud verdict |
| Behaviour with no network connection | The signed policy keeps being enforced locally on mobile, wireless and air-gapped robots |
| How on-device control fits next to network monitoring | Sites that need network visibility keep those tools and add XGuard on the device |
| Where security telemetry originates | XGuard Monitor gathers telemetry from the application, file system, network stack, operating system, CPU, I/O and memory on the device, and events flow to a central dashboard with fleet, network and per-device views |
A good result for a disconnected robot: the unapproved process is blocked at launch on the device itself.
Does the vendor support your robot's Linux stack and ROS 2 build without a rewrite?
A vendor that cannot support your robot's existing Linux stack and ROS 2 build is asking you for a port, so platform coverage belongs early in the evaluation rather than at integration time. ROS 2 (Robot Operating System 2) is a robotics framework that runs on top of Linux, which means the real question is how the security layer attaches to the Linux image underneath it and to the build pipeline that produces that image.
Work through these attributes and record the answer you get:
| Platform attribute | What to ask the vendor | What XGuard offers |
|---|---|---|
| ROS 2 on Linux | Is it supported out of the box? | Supported out of the box |
| Yocto / Buildroot | Does it integrate into the embedded build pipeline you already run? | Supported out of the box, with native integration into embedded build pipelines |
| Pre-built Linux | Is there a ready path for a pre-built distribution? | A ready add-on for pre-built Linux, and bolt-on security for stock distributions such as Ubuntu and Red Hat |
| Custom Linux | Is there an adaptation path? | Adaptation for custom Linux |
| Kernel versions | Which kernels are covered, and how? | Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode) |
| Deployment model | Does it run in user space, at kernel level, or both? | A user-space application or a kernel-level integration |
According to Karamba Security, XGuard covers ROS 2, Buildroot and Yocto out of the box, and it is applied to the workload's binary image with no source code access required, so the robotics team's build process stays as it is. XGuard requires no hardware changes and no change to R&D workflows.
How is the allowlist policy built, and what does it ask of your R&D team?
The allowlist policy in XGuard is built automatically from the device's own firmware image and signed before the device ships, with no change to development workflows. That policy is the signed inventory of every executable, library and script permitted to run, and it is anchored in secure boot, with content validated page by page at execution. Enforcement is deterministic: code either matches the signed policy or it does not execute.
| Ask this | What a good answer looks like |
|---|---|
| Who writes the allowlist? | XGuard generates the policy automatically from the firmware image and signs it before the device ships |
| What does R&D have to do? | Allowlisting and Python inspection are applied automatically, as is the optional control-flow integrity layer where used; access-control rules only require identifying the sensitive directories, applications and peripherals |
| Is interpreted code covered, not only compiled binaries? | Deep Python inspection covers payloads delivered through a trusted interpreter |
| How are container images on the device handled? | Karamba Security's September 2024 announcement describes Secure Boot for containers: XGuard calculates each container image's hash, builds a policy of allowed images and enforces it each time a container instance is created |
| Can memory-corruption exploits that bypass an allowlist be stopped? | Control-flow integrity, an optional layer inside the binaries, stops ROP and JOP memory-corruption exploits deterministically, and its violation events carry forensic data |
A good result: the policy comes out of the image you already build, and the only manual input is the list of sensitive directories, applications and peripherals.
What proof should you ask for that the agent runs inside a robot's compute budget?
Ask for proof that the agent's footprint fits a robot's compute budget, and treat a datasheet assertion as a starting point for questions rather than as the whole answer. Karamba Security states that XGuard is proven on constrained embedded systems at a 500KB agent size, 2MB RAM and 1% CPU.
| Attribute to verify | What to ask for |
|---|---|
| Agent footprint | RAM, CPU and storage with the enforcement modules you will actually enable |
| Deployment model | Whether the agent runs in user space or as a kernel-level integration |
| Hardware impact | Whether any hardware or bill-of-materials change is needed; XGuard requires none |
| Maturity evidence | Named, published production references you can read and verify yourself |
For published references, HP renewed its multi-year agreement to license XGuard across HP's business printer families with a 3-year renewal announced in February 2026, and 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 device firmware that runs Ubuntu. These are constrained embedded systems, not robot deployments.
Frequently Asked Questions
What should a checklist cover when comparing vendors that block unauthorized processes on robots?
Vendors that block unauthorized processes on robots should be checked against a few concrete items: where enforcement runs, whether a root-level attacker can switch it off, which execution paths are covered, and what integration asks of the engineering team. XGuard answers the first two with a tamper-proof policy — one cryptographically signed with a private key held outside the device — so an attacker holding root cannot modify or disable it. Coverage should also include scripts and interpreted code, not only compiled executables.
How does on-device enforcement relate to network-based monitoring?
On-device enforcement and network-based monitoring answer different questions on a robot fleet. Network-monitoring platforms such as Claroty and Nozomi Networks, with Dragos and Armis in the same class, do asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. XGuard is a complementary on-device layer: it blocks unapproved code, out-of-context commands, tampering with sensitive files and unauthorized processes on the device itself, and sites that need network visibility keep those tools and add XGuard on the device.
Which robot operating systems and Linux builds can be covered?
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 and adaptation for custom Linux. It runs as a user-space application or as a kernel-level integration.
Will runtime enforcement cost performance on constrained robot compute?
Constrained compute is a standing objection from architects, so footprint belongs on the checklist. Karamba Security states that XGuard is proven on constrained embedded systems at a 500KB agent size, 2MB RAM and 1% CPU, and XGuard requires no hardware or bill-of-materials changes.
What happens between a CVE disclosure and the next firmware release?
AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks, and that gap is what drives emergency patch campaigns. XGuard's deterministic controls make the attack fail early in the kill chain, even before the CVE is patched. The vulnerability still needs fixing; with XGuard on the device, the fix can wait for the next planned firmware release.
What track record should a buyer ask a Physical AI security vendor to show?
Ask for production evidence and for the vendor's own history. Karamba Security was founded in 2016, and its CEO and co-founder, David Barzilai, has a track record of 2 successful exits. According to Karamba Security's XGuard page, 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