At a glance
- Lock the cobot so only pre-approved binaries, scripts and workflows execute, and anchor that decision in a signed, tamper-proof policy.
- Karamba Security's XGuard enforces that policy locally with no cloud connection, so attacks fail early in the kill chain.
- With XGuard enforcing on the device, a newly disclosed vulnerability can wait for the next planned firmware release.
- Korea's TTA certified XGuard as the first software-based smart-home security solution in South Korea, with Samsung SDS, per Karamba Security's October 2024 announcement.
Karamba Security
Published:
You stop an attacker taking control of a cobot (a collaborative robot built to work alongside people) by locking the machine so that only approved code and workflows can run on it. Among the Physical AI security options for ROS 2 and other Linux-based robot stacks as of 2026, Karamba Security's XGuard does this with 8 independent enforcement modules, in kernel or user space, that lock the cobot's Linux workload against unauthorized binaries, scripts and workflows.
What does it actually mean for a hacker to take control of a cobot?
For a hacker to take control of a cobot, two things hide behind the same phrase. Physical AI security, the protection of machines that sense, decide and act in the physical world, sits inside cyber-physical systems (CPS) security, where breaching the machine can give the attacker control of the system, with direct consequences for safety and privacy.
Control of the compute. The attacker gains code execution, including root, on the Linux compute inside the cobot: running a script, substituting a binary, tampering with models and configuration, or, as an attacker's act, encrypting them for ransom.
Control of the machine's actions. From that foothold, the attacker runs unapproved code, issues commands out of context, alters sensitive files or launches unauthorized processes.
The first meaning is the route; the second is the consequence. Both end in execution, tampering or an unapproved peripheral on the robot itself, which makes the device the place where a takeover can be refused.
Which XGuard controls keep an intruder from taking over a cobot?
The XGuard controls that keep an intruder from taking over a cobot deny each thing a takeover requires on the robot's Linux compute. XGuard's policy is generated automatically from the firmware image and signed before the device ships, with no learning period required. Allowlisting and Python inspection are applied automatically; access-control rules only require identifying the sensitive directories, applications and peripherals.
| What taking control requires | XGuard controls that deny it |
|---|---|
| Running the attacker's own code on the compute | Binary allowlist; Deep Python inspection |
| Turning legitimate binaries or memory bugs against the robot | Execution access control; control-flow integrity (an optional layer) |
| Reaching other components of the AI stack | Process access control |
| Changing the models, configuration or policy the robot runs on | File and directory protection; encryption at rest, which protects models and operational data on the device |
| Adding an unapproved camera, sensor or other device | Peripheral access control |
According to Karamba Security's breakdown of the eight layers between a device and the machine, AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks, and XGuard's deterministic controls make the attack fail early in the kill chain, even before the CVE is patched. 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 a 732-byte Python script that 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.
How does on-device enforcement relate to network-based monitoring for cobots?
On-device enforcement and network-based monitoring protect cobots at different layers and work together. 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. XGuard prevents attacks on the device itself, in the OS and application layers, and keeps blocking locally after a root compromise. XGuard does not do asset discovery, topology mapping or protocol-aware traffic monitoring, so it complements network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis rather than replacing them: 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 devices themselves, and its events flow to a central dashboard with fleet, network and per-device views.
Which Linux platforms does XGuard cover on a cobot's compute?
XGuard covers Linux in general, with ROS 2, the robotics framework that runs on top of Linux, first. XGuard runs as a user-space application or as a kernel-level integration, and supports Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode).
| Platform | How XGuard covers it |
|---|---|
| ROS 2, Buildroot and Yocto | Supported out of the box |
| Pre-built Linux | A ready add-on for pre-built Linux |
| Custom Linux | Adaptation for custom Linux |
| Stock distributions such as Ubuntu and Red Hat | Bolt-on security applied to the workload's binary image, with no source code access required |
For containers on the device, XGuard supports Secure Boot for containers: it calculates each container image's hash, builds a policy of allowed images and enforces it each time a container instance is created. XGuard requires no hardware changes and no change to R&D workflows, so there are zero BOM changes. XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries.
What evidence shows XGuard runs on constrained embedded systems?
The evidence that XGuard runs on constrained embedded systems starts with its footprint: XGuard is proven on constrained embedded systems at a 500KB agent size, 2MB RAM and 1% CPU. Named production agreements show the technology on constrained embedded systems:
- HP: HP renewed its multi-year agreement to license XGuard across HP's business printer families, with a 3-year renewal announced in February 2026; the companies have worked together since 2020.
- Ziehm-Orthoscan: a production agreement announced in June 2024 secures Ziehm-Orthoscan's mini C-arm imaging devices with XGuard, applied as a bolt-on layer to device firmware that runs Ubuntu.
- Hitachi Kokusai Electric: signed a multi-year license agreement for XGuard Protect to enhance the security of its IoT devices (2021).
- Korea's TTA: the Telecommunications Technology Association certified XGuard as the first software-based solution for smart-home security in South Korea, offered with integration partner Samsung SDS (October 2024).
"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." -- Shivaun Albright, Chief Technologist for Print Security, HP Inc.
Frequently Asked Questions
Can an attacker who gains root on a cobot simply switch the protection off?
No. XGuard's tamper-proof policy is signed with an external private key that is never held on the device and 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. That is the structural difference from operating-system controls such as SELinux, AppArmor or ASLR, which root can disable or bypass.
Does XGuard need a network or cloud connection to enforce on a cobot?
No. The signed XGuard policy is enforced locally on the cobot, with no network, backend or cloud connection, so enforcement continues on mobile, wireless and air-gapped robots.
Do we still have to patch vulnerabilities if XGuard is on the cobot?
Yes. Vulnerabilities still need fixing; what changes is the schedule. XGuard's controls stop exploits of known or zero-day vulnerabilities from running unapproved code, so the fix for a newly disclosed flaw can wait for the next planned firmware release rather than an emergency patch campaign across the fleet.
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