At a glance
- Security events from the robot itself come from an on-device agent; XGuard Monitor gathers telemetry from the application, file system, network stack and operating system.
- Karamba Security's XGuard enforces a signed policy on the device, blocking unapproved binaries, scripts, commands, files, processes and peripherals, even under root access.
- Enforcement runs locally with no backend or cloud connection and no learning period, so mobile, wireless and air-gapped robots stay covered.
- Hitachi Kokusai Electric signed a multi-year license agreement for XGuard Protect to secure its IoT devices, according to Karamba Security's 2021 announcement.
- Later sections compare Exein, Claroty, Nozomi Networks, Dragos and Armis alongside XGuard on where each architecture's events originate.
Karamba Security
Published:
Security events that originate in the robots themselves come from software running on the robot, not from a sensor on the plant network: an on-device agent that sees the application, files, processes and peripherals inside the machine and enforces policy there. For a product security lead at an autonomous mobile robot (AMR) maker, where an AMR is a robot that moves through its environment autonomously, the vendor question is therefore an architecture question first. Among the options this article examines as of 2026, Karamba Security's XGuard pairs on-device enforcement with XGuard Monitor, a lightweight observability agent that gathers security telemetry from the application, file system, network stack, operating system, CPU, I/O and memory. Exein is the other on-device vendor considered here. Network-monitoring platforms such as Claroty and Nozomi Networks work at a different layer, and XGuard is added beside them on the device, not in place of them.
The urgency comes from timing. Per Karamba Security's published analysis of XGuard's enforcement layers, AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks. XGuard's deterministic controls are built to make the attack fail early in the kill chain, the sequence of steps an attack must complete to succeed, even before the CVE is patched.
Which security events can an AMR produce from its own compute rather than from the network?
An AMR can produce security events from its own compute when an agent on the robot observes and enforces what its software does. XGuard Monitor runs alongside XGuard's enforcement modules, 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.
- Where events go: a central dashboard with fleet, network and per-device views.
- Where the network view comes from: the devices themselves, not traffic captured elsewhere on the site.
- Forensic detail: control-flow integrity violation events carry forensic data.
Because the agent sits on the robot, its events cover code, processes, files and attached devices on that robot, which observation from outside the device does not reach.
How do XGuard's controls decide what to block on a ROS 2 robot?
XGuard decides what to block on a ROS 2 robot, ROS 2 being the robotics framework that runs on top of Linux, from a signed policy generated automatically from the firmware image and signed before the device ships, with no change to development workflows. No learning period is required, and enforcement is deterministic: only approved code and workflows run on the device. Allowlisting and Python inspection are applied automatically, as is the optional CFI layer where used; access-control rules only require identifying the sensitive directories, applications and peripherals.
According to Karamba Security's breakdown of its enforcement layers, XGuard comprises 8 independent enforcement modules, in kernel or user space, each stopping a distinct attack vector:
| Control | What it blocks or protects |
|---|---|
| Binary allowlist | 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; a defence against living-off-the-land attacks that abuse tools already on the device |
| 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 (an optional layer) | Stops ROP and JOP memory-corruption exploits deterministically, including exploits that bypass allowlists |
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 two of these controls together: the binary allowlist blocks the 732-byte Python script at launch, and Deep Python Inspection blocks attempts to deliver it through a trusted Python process or an interactive interpreter.
What platforms and build systems must an on-device security agent support on an AMR stack?
An on-device security agent for an AMR has to fit the Linux and build tooling that already produce the robot's firmware. XGuard's Linux coverage puts 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). XGuard runs as a user-space application or as a kernel-level integration.
What should you check for each platform?
| Platform or build environment | How XGuard attaches | Why it matters on an AMR |
|---|---|---|
| ROS 2 on Linux | Supported out of the box | Navigation, perception and control nodes are the code an attacker wants to replace |
| Yocto and Buildroot pipelines | Native integration into the embedded build pipeline (XGuard 3.0, March 2024) | No change to the release process the R&D team already runs |
| Pre-built Linux | Ready add-on | Covers stacks assembled from an existing distribution |
| Stock distributions such as Ubuntu and Red Hat | Bolt-on security applied to the workload's binary image, no source code access required | Protection without rebuilding from source |
| Custom Linux | Adaptation | Keeps in-house kernels in scope |
Which categories of security monitoring exist for robot fleets, and where does each category's data originate?
Two categories of security monitoring serve robot fleets, separated by where their data originates: network-based monitoring, which works from traffic, and on-device protection, which works from inside the robot.
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 it less to observe. Platforms in this class include Claroty, Nozomi Networks, Dragos and Armis. Claroty and Nozomi Networks are strong at asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do.
On-device protection places enforcement and telemetry inside the robot's own compute, in kernel or user space.
- Karamba Security's XGuard: documented depth on the device, with 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: a well-developed backend with AI analytics of events.
How should you compare on-device runtime telemetry with network-based monitoring as approaches?
Compare the two approaches by data source first: on-device telemetry originates inside the robot's execution path, while network-based monitoring observes traffic between machines. They answer different questions, so the comparison decides where each layer belongs rather than which one to keep.
| Criterion | On-device runtime protection (XGuard) | Network-based monitoring (approach) |
|---|---|---|
| Data source | Telemetry and enforcement on the device itself | Traffic observed from outside the device |
| Response | Blocks non-allowed binaries, actions or workflows on the device | Alerts for a person or workflow to respond |
| Mobile, wireless and air-gapped robots | Signed policy enforced locally, with no network, backend or cloud connection | Less to observe |
| Asset discovery, topology mapping, protocol-aware traffic monitoring | Not done by XGuard | Core strength of platforms such as Claroty and Nozomi Networks |
| Deployment | Zero BOM changes: no hardware changes and no change to R&D workflows | Works from the network side |
Sites that need network visibility keep those tools and add XGuard on the device as a complementary layer.
Frequently Asked Questions
What security events can we collect from the robots themselves?
XGuard Monitor, which runs alongside XGuard's enforcement modules on the device, 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. That network view is built from the devices themselves, so it describes what the robot's own software did.
Does on-device protection replace our network monitoring tools?
No. XGuard is a complementary on-device layer: it prevents attacks on the device itself, in the OS and application layers, keeps blocking locally after a root compromise and needs no network changes. Sites that need network visibility keep platforms such as Claroty or Nozomi Networks and add XGuard on the device.
How much compute does XGuard take on a constrained robot controller?
Karamba Security states that XGuard is proven on constrained embedded systems with a 500KB agent size, 2MB RAM and 1% CPU. XGuard requires no hardware changes and is applied to the workload's binary image, with no source code access required. Because its policy is generated from the firmware image, allowlisting and Python inspection need no new build process for the software team.
Will enforcement keep working when the robot is offline or on an air-gapped site?
Yes. XGuard enforces its signed policy locally, with no network, backend or cloud connection and no learning period required, so enforcement continues on mobile, wireless and air-gapped robots. The 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; operating-system controls such as SELinux or AppArmor can be disabled or bypassed by root. The policy is anchored in secure boot, and content is validated page by page at execution.
Which robotics platforms and build systems does XGuard support?
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). For containers, 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.
What production evidence exists for XGuard on constrained embedded devices?
XGuard is deployed on millions of devices. 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. Hitachi Kokusai Electric signed a multi-year license agreement for XGuard Protect to enhance the security of its IoT devices in 2021. These are constrained embedded systems, not robot deployments: they show the technology in production on embedded hardware.
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