At a glance
- Offline runtime protection means on-device enforcement: a locally signed policy, no cloud, no backend lookup and no learning period before protection starts.
- Karamba Security's XGuard signs its policy with a private key kept off the device, so root access alone cannot disable enforcement.
- XGuard controls include a binary allowlist, Deep Python inspection and execution access control, blocking unapproved code on Linux and ROS 2 stacks.
- Karamba Security states XGuard runs on constrained embedded compute with a 500KB agent, 2MB RAM and 1% CPU.
Karamba Security
Published:
For an autonomy software supplier shipping onto autonomous mobile robots (AMRs), robots that move through a warehouse, yard or plant floor autonomously, runtime protection that works offline means enforcement that lives entirely on the device: a signed policy checked locally, with no network, backend or cloud connection and no learning period required. Karamba Security's XGuard is built on that model, so enforcement continues on mobile, wireless and air-gapped robots. Among the on-device options available as of 2026, this is the dividing line a chief architect can test quickly: ask whether the product still blocks an unapproved binary when the radio is off.
XGuard's enforcement is deterministic and deny-access-by-default: only approved code and workflows run on the device. A binary allowlist, a signed inventory of every executable, library and script permitted to run, blocks anything outside it at execution; 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, process and peripheral access controls govern which code may run, shield process memory and debug access, and admit only approved cameras, sensors and other attached devices. The signed policy holds even if an attacker gains root, which is the difference from operating-system controls such as SELinux or AppArmor, which root can disable or bypass.
Platform fit is the second question for an AMR autonomy image. ROS 2, Buildroot and Yocto are supported out of the box, and XGuard is applied to the workload's binary image with no source code access required.
What does "offline runtime protection" actually mean on an AMR?
Offline runtime protection can mean two different things in robot procurement, and only one keeps acting when an AMR drives out of coverage. Runtime protection is any control that acts on the device while the workload is executing, refusing code, commands, file changes or process actions as they happen, as distinct from scanning an image before it ships. The ambiguity sits in the word "offline".
Monitoring that relies on a connection. 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.
On-device enforcement. The allow-or-block decision is made locally at execution time, against a policy already on the device. Example: an unapproved executable dropped into an AMR's filesystem is refused at launch whether or not the machine has a connection.
Air-gapped operation is the hard case: a device with no network path to any backend, by design.
This article uses the second meaning.
Why does a cloud-dependent security model leave an AMR exposed on the floor?
A cloud-dependent security model leaves an AMR exposed because the robot's protection then sits off the device, while the attack runs on it. Breaching a Physical AI machine can give the attacker control of the system, with direct consequences for safety and privacy. Monitoring solutions do not protect the device or the container, and incident response cycles are much slower than AI-powered attacks. The gap that matters, per Karamba Security's published analysis, is that AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks; XGuard's deterministic controls make the attack fail early in the kill chain, the sequence of steps an attack must complete, even before the CVE is patched.
| Do this | But watch out for, and how to handle it |
|---|---|
| Enforce the security policy on the device, locally | A local policy is only as strong as its protection against root. XGuard's policy is anchored in secure boot, and the agent and its policy protect themselves against a root attacker. |
| Keep network-based monitoring for site visibility | It observes traffic from outside the device and alerts; treat it as complementary to on-device enforcement. |
| Move the CVE fix into the next planned firmware release | The vulnerability still needs fixing. XGuard lets that fix wait for the planned cycle. |
How does XGuard enforce security on the device with no cloud connection?
XGuard enforces security on the device by evaluating a signed policy locally, through 8 independent enforcement modules that run in kernel or user space, each stopping a distinct attack vector.
The policy is generated automatically from the firmware image and signed before the device ships, so the inventory of permitted executables, libraries and scripts is derived from the robot's own build. Per Karamba Security, the signed policy is anchored in secure boot, and content is validated page by page at execution.
| Attribute | What it is | Why it matters to an AMR architect |
|---|---|---|
| Policy source | Generated automatically from the firmware image, signed before the device ships | The allowlist reflects the robot's own build, with no change to development workflows |
| Signing key | External private key, never held on the device | Even an attacker with full root access cannot modify or disable XGuard |
| Enforcement model | Deterministic, deny-access-by-default, in kernel or user space | Blocking decisions are made at execution time, locally |
| Deployment | User-space application or kernel-level integration; bolt-on to the workload's binary image | Zero BOM changes: no hardware changes and no change to R&D workflows |
| Footprint | Per Karamba Security, XGuard is proven on constrained embedded systems: 500KB agent size, 2MB RAM, 1% CPU | A production figure from constrained embedded systems |
| Access-control rules | Only require identifying the sensitive directories, applications and peripherals | Allowlisting and Python inspection are applied automatically |
XGuard Monitor, a lightweight observability agent that runs alongside the enforcement modules, gathers security telemetry from the application, file system, network stack, operating system, CPU, I/O and memory; events flow to a central dashboard with fleet, network and per-device views.
Which attack paths do on-device controls block on a robot's compute stack?
On-device controls block attack paths wherever an exploit must run code, issue a command, alter a file, reach into a process or use a peripheral on the robot's compute stack. For an AMR running Linux and ROS 2, that means mapping each XGuard control to the surface it governs.
| XGuard control | Acts on | AMR attack path it addresses |
|---|---|---|
| Binary allowlist | Executables on devices and nodes | An injected, substituted or unauthorized executable on a navigation or perception node |
| Deep Python inspection | Python imports, cache, interactive sessions | A payload delivered through a trusted Python process or an interactive interpreter |
| Execution access control | Which code may run, and under what conditions | Living off the land: an approved binary spawning a shell or calling curl, limited to permitted process pairs |
| Process access control | Process memory and debug access | Lateral movement between components of the AI stack |
| File and directory protection | Models, configuration and policy | Tampering with models, configuration or the policy itself |
| Encryption at rest | Models and operational data on the device | Reading stored models and operational data |
| Peripheral access control | Cameras, sensors and other attached devices | An unapproved camera, sensor or other attached device on a field or factory unit |
| Control-flow integrity (an optional layer) | The binary's legitimate call graph | ROP and JOP memory-corruption exploits, including exploits that bypass allowlists; violation events carry forensic data |
These controls act on code, commands, files, processes and peripherals on the device. They do not stop a manipulated prompt or a jailbroken AI model that acts through approved code.
How does on-device enforcement compare with a network-monitoring approach?
On-device enforcement and a network-monitoring approach sit at different layers, so the comparison is about what each layer does rather than which one wins.
| Criterion | On-device runtime enforcement (XGuard) | Network-based monitoring approach |
|---|---|---|
| Where it works | On the device, in the OS and application layers | From outside the device, observing traffic |
| Action taken | Blocks unapproved binaries, scripts, commands, file changes, processes and peripherals at execution | Alerts for a person or workflow to respond |
| Mobile, wireless and air-gapped robots | Signed policy enforced locally on each unit | These robots and encrypted traffic give it less to observe |
| Network changes | Needs no network changes | Observes the network the devices sit on |
| Asset discovery, topology mapping, protocol-aware traffic monitoring | Not something XGuard does | The approach's strength |
Karamba Security's XGuard 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, where it keeps blocking locally after a root compromise.
Frequently Asked Questions
Does XGuard runtime protection work offline, with no cloud connection?
Yes. XGuard runtime protection works offline: 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. Runtime protection here means enforcement on the device while the workload executes, rather than analysis performed elsewhere after the fact. Karamba Security brings that local-enforcement model to Physical AI, meaning AI systems that sense, decide and act in the physical world.
Which Linux and ROS 2 configurations does XGuard support on an autonomy stack?
XGuard supports 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). According to Karamba Security's release announcement, XGuard 3.0 (March 2024) added distro-agnostic Linux protection: native integration into embedded build pipelines such as Yocto and Buildroot, and bolt-on security for stock distributions such as Ubuntu and Red Hat.
Can an attacker with root access switch XGuard off?
No. Per Karamba Security's XGuard page, XGuard uses a tamper-proof policy: it 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. That is the practical difference from operating-system controls such as SELinux, AppArmor or ASLR, which root can disable or bypass. Each control is described by what it blocks: unauthorized binaries, out-of-context commands, file tampering, unapproved processes and peripherals.
How much compute does XGuard consume, and where has it run in production?
According to Karamba Security, XGuard is proven on constrained embedded systems with a 500KB agent size, 2MB RAM and 1% CPU. The XGuard product page states that XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries. Karamba Security, founded in 2016, lists adopters including Samsung, HP, Volvo, Hitachi and Stellantis; these adoptions are not robot deployments.
What protects an AMR fleet between a CVE disclosure and the next firmware release?
Deterministic on-device controls make the exploit fail early in the kill chain, so the fix for a newly disclosed vulnerability can wait for the next planned firmware release instead of an emergency patch campaign across the fleet. Karamba Security's May 2026 analysis shows how 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. The vulnerability still needs fixing; XGuard lets that fix follow the planned release.
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