At a glance
- Locking configuration files on a robot means blocking runtime changes to parameter files, model weights, service settings and the security policy itself.
- Karamba Security's XGuard enforces file and directory protection with a policy signed by an off-device private key, so root cannot disable it.
- Karamba Security's analysis shows XGuard's binary allowlist and Deep Python Inspection block the Copy Fail Linux-kernel exploit, CVE-2026-31431, before the script gains root.
- File locking is one control among several: XGuard also governs execution, process and peripheral access on Linux and ROS 2 devices.
Karamba Security
Published:
When security vendors talk about locking config files on robots, they mean file and directory protection: a runtime control that keeps the files a machine depends on unaltered on the device. Karamba Security's XGuard provides that control for Physical AI devices, which are machines that sense, decide and act in the physical world, such as cobots, autonomous mobile robots, drones and unmanned vessels. XGuard keeps models, configuration and policy unaltered on the device itself. As of 2026, file and directory protection is one of 8 independent enforcement modules in XGuard. The modules run in kernel or user space, and each one stops a distinct attack vector, from a binary allowlist to control-flow integrity, which is an optional layer.
What does it mean when a security vendor locks configuration files on a robot?
When a security vendor says it locks configuration files on a robot, it means the device itself enforces a rule that keeps defined files unaltered. In XGuard, that rule is part of a signed policy enforced on the device. The policy's relevant attributes:
| Attribute | Value or scope |
|---|---|
| Protected scope | Models, configuration and policy |
| Policy origin | Generated automatically from the firmware image and signed before the device ships, with no change to development workflows |
| Enforcement model | Deterministic |
XGuard's controls stop exploits of known or zero-day vulnerabilities from tampering with sensitive files, running unapproved code, issuing commands out of context or launching unauthorized processes.
What is at stake when an attacker can change a robot's files?
Breaching a Physical AI machine can give the attacker control of the system, with direct consequences for safety and privacy. Timing raises the stakes, because 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, even before the CVE is patched. 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.
Which files and components on a ROS 2 or Linux robot does XGuard protect?
On a ROS 2 or Linux robot, file and directory protection is one XGuard control. The other controls cover the code, processes and peripherals around those files. Each control and what it does:
- File and directory protection: keeps models, configuration and policy unaltered.
- Encryption at rest: protects models and operational data on the device.
- Binary allowlist: blocks injected, substituted or unauthorized executables on devices and nodes.
- Execution access control: governs which code may run, and under what conditions, including legitimate binaries, limiting what a compromised component can launch. This limits living-off-the-land attacks, which abuse legitimate binaries 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.
To set up XGuard's access-control rules, a team only has to identify the sensitive directories, applications and peripherals.
XGuard Monitor is a lightweight observability agent that runs alongside these controls. It gathers security telemetry from the device itself, including its file system, and it detects abnormal events on the device and, for deeper analysis, on the backend.
How does on-device file enforcement differ from network-based monitoring approaches?
On-device enforcement acts inside the robot itself: XGuard blocks unapproved binaries, scripts, file changes and peripherals on the device. Network-based monitoring, as an approach, observes traffic from outside the device and raises alerts for a person or workflow to respond to.
| Approach | Where it acts | What happens on an unapproved action |
|---|---|---|
| XGuard (on-device enforcement) | On the device itself, in the OS and application layers | Blocked on the device |
| Network-based monitoring | Outside the device, on observed traffic | An alert for a person or workflow to respond to |
Mobile, wireless and air-gapped robots and encrypted traffic give network-based monitoring less to observe. The two approaches are complementary, and neither replaces the other. XGuard does not do asset discovery, topology mapping or protocol-aware traffic monitoring. Sites that need network visibility keep tools such as Claroty, Nozomi Networks, Dragos or Armis and add XGuard on the device.
How is XGuard applied to a robot's software image?
XGuard is bolt-on security. It is applied seamlessly to the workload's binary image, with no source code access required, and it needs no hardware changes and no change to R&D workflows.
- Automatic application: allowlisting and Python inspection are applied automatically, as is the optional CFI layer where it is used.
- Deployment models: XGuard runs as a user-space application or as a kernel-level integration.
- Platforms: 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.
- 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.
According to Karamba Security, XGuard is proven on constrained embedded systems: 500KB agent size, 2MB RAM, 1% CPU.
Frequently Asked Questions
What does "locking configuration files" on a robot actually involve?
It means enforcing at runtime that the files a robot depends on cannot be altered on the device: models, configuration and the security policy itself. In XGuard, this is the file and directory protection control, one of several on-device enforcement modules for Physical AI security, meaning security for machines that sense, decide and act in the physical world.
Why don't configuration locks alone stop an exploit?
A file lock keeps files unaltered, but it does not decide which code runs. A binary allowlist is a signed inventory of every executable, library and script permitted to run. It blocks unapproved code at execution, so it covers what a file lock does not. A May 2026 analysis on Karamba Security's blog shows XGuard stopping Copy Fail (CVE-2026-31431). Copy Fail is 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. Deep Python Inspection validates what a trusted Python interpreter imports at runtime and controls interactive Python use. It blocks attempts to deliver the script through a trusted Python process or an interactive interpreter.
How does a file lock survive an attacker who already has root?
It survives through a tamper-proof policy. In XGuard, 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. That separates it from operating-system controls such as SELinux, AppArmor or ASLR, which root can disable or bypass. The signed XGuard policy is anchored in secure boot, and its content is validated page by page at execution.
What is Secure Boot for containers in XGuard?
In September 2024, Karamba Security announced that XGuard supports Secure Boot for containers. XGuard calculates each container image's hash, builds a policy of allowed images and enforces that policy each time a container instance is created.
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