When Software Starts Walking: Microduck and the New Security Frontier of Robotics

From tiny open-source robots to networked machines, physical AI gives software vulnerabilities a path to physical consequences.

For decades, cybersecurity has focused primarily on protecting information: databases, servers, endpoints, applications, and networks.

But the next generation of connected systems introduces a different challenge.

What happens when vulnerable software can move?

A compromised web application might expose customer records. A compromised server might become part of a botnet. A compromised robot could potentially move, manipulate objects, interfere with an environment, or act against its operator’s intentions.

The transition from software that processes information to software that controls physical behavior deserves much more attention from the security community.

And surprisingly, some of the most interesting platforms for exploring this transition are small robots that fit on a desk.

Meet Microduck: Physical AI at Desktop Scale

Pollen Robotics describes Microduck as a small bipedal robot whose movements use reinforcement-learning policies.

The 25-centimeter robot has 15 motors, a camera, LiDAR, and two inertial measurement units. Pollen Robotics lists walking, sitting, standing, grasping and other trained behaviors. These product descriptions are not a safety evaluation.

But the most interesting part is not its appearance.

It is the software.

Microduck runs learned motion policies, trained in simulation and transferred to physical hardware. Its public runtime repository includes Rust services responsible for motor control, communication, configuration, media, and software updates. Its reinforcement-learning repository documents the simulation and training pipeline.

This is a small but meaningful example of physical AI becoming accessible to ordinary developers.

It also creates an opportunity for security researchers to study a system where software decisions produce physical motion.

Microduck’s software and training stack are published as open source. That does not, by itself, establish that the complete production hardware design is released under an open-hardware license.

Related projects extend the experimentation possibilities. XGO-Duck, an adaptation by Luwu Dynamics, provides a 3D-printable robot architecture using Arduino UNO Q and 15 servos. The earlier Open Duck Mini project also demonstrates how makers can build and train small walking robots.

For robotics education, this is exciting.

For cybersecurity, it raises an equally important question: what exactly are we trusting when we let software control a machine?

A Robot Is More Than an IoT Device With Motors

Consider the architecture of a modern connected robot.

It may include a Linux-based onboard computer, wireless communication interfaces, local APIs, sensors, motion controllers, trained AI policies, remote software updates, and sometimes cloud-connected services.

Each component introduces potential attack surfaces.

A vulnerability in a communication interface might allow unauthorized control. A compromised software update could alter the robot’s behavior. Manipulated sensor data could change how an autonomous system understands its surroundings.

The critical difference is the final output.

Instead of returning a response through an API, the system may move a motor.

This changes the impact of a security failure.

Confidentiality and integrity remain important, but physical safety, operational continuity, and the integrity of actuator commands become central concerns.

The traditional distinction between application security and operational technology security begins to blur.

A local-network control path deserves the same scrutiny as a remote one

A useful security question surfaced in Microduck’s public development discussion. As of October 29, issue #443 and the linked documentation-only pull request #453 remain open. The current LAN signaling source and project discussion describe that path as unauthenticated; remote rendezvous uses authentication, while LAN pairing relies on a shared factory PIN. PR #453 scopes a documentation claim and does not change the authentication mechanism. This describes the public development branch, not proof that every shipped unit uses this build or that anyone has exploited it.

That report is a development-time observation, not evidence of a confirmed attack or a security audit of shipping robots. But it illustrates why teams must distinguish local access from trusted access. A home Wi-Fi network can include guest devices, compromised laptops and internet-of-things products. If a local path can reach a camera or movement control, the design should state clearly what authenticates that path, how pairing credentials are unique, and whether production configuration differs from development defaults.

Before relying on any mitigation, check the current source, release and owner guidance. A documentation fix can prevent a false sense of protection, but only a verified implementation and tested configuration establish what a device actually permits.

What Microduck’s Architecture Reveals About Security

One of the most interesting aspects of Microduck is how much of its engineering reasoning is publicly documented.

Its developers describe the boundaries between services responsible for communication, configuration, software updates, perception, and motor control.

The architecture describes separate services for the control loop, networking, camera, configuration and updates. That separation makes it possible to review which components can communicate and what commands each interface accepts. It should not be read as proof that the robot enforces every safety property an operator may expect.

The project’s updater design documents signed software updates and rollback mechanisms intended to reduce the risk of installing invalid or malfunctioning releases.

These are important security engineering decisions.

The repository and issue thread document an evolving development system. They are useful for reviewing design assumptions, but they are not an independent security audit of a shipped Microduck.

But they illustrate something valuable: security assumptions become easier to examine when architectural decisions are documented in public.

Open source does not automatically make a robot secure.

It does, however, create opportunities to inspect implementation choices, identify weaknesses, improve protections, and reproduce security research.

For a physical system, that visibility can be particularly important.

AI Introduces Another Attack Surface: Perception

Traditional cybersecurity often focuses on manipulating code, credentials, protocols, or data.

Embodied AI adds another possibility.

What if an attacker does not need to modify the robot’s software?

What if manipulating what the robot sees is enough?

In January 2026, the University of California, Santa Cruz announced research on environmental indirect prompt injection attacks against embodied AI systems. The underlying paper, CHAI: Command Hijacking against embodied AI, written with researchers at Johns Hopkins University, was first posted to arXiv in September 2025.

The researchers investigated how malicious instructions embedded in physical-world text could influence autonomous systems that interpret visual information using language-based models. They tested driving decisions on real road photos, drone tasks in high-fidelity simulators, and a small robotic car driving autonomously through a university building.

A sign, label, or other visible object could become an unintended instruction channel.

This is a different trust-boundary problem.

The robot must distinguish between environmental information it should observe and authoritative instructions it is permitted to execute.

A visual model that reads a sign is not necessarily authorized to obey it.

The distinction is especially important for robots that combine vision-language models with navigation, manipulation, or task planning.

Microduck’s standard motion policies are not themselves examples of language-model prompt injection. But platforms like Microduck make it easier to experiment with additional perception and planning layers where these issues may arise.

The lesson is broader than any single robot.

When AI systems operate in the physical world, untrusted environmental inputs must never automatically become trusted commands.

Conceptual review model, not Microduck’s implemented architecture.

Robotics Needs Security Across Three Boundaries

I believe robotic security needs to be understood through three distinct trust boundaries.

The communication boundary: Who is authorized to connect to the robot, access its sensors, change its configuration, or issue commands?

The intelligence boundary: Which inputs can influence the robot’s decisions, and how do we prevent untrusted information from becoming authoritative instructions?

The physical boundary: Which actions may the robot execute, regardless of what a remote operator or AI policy requests?

These boundaries require different protections.

Network authentication and encryption protect communication. Software signing and supply-chain controls protect updates. Permission models and service isolation restrict access to sensitive functionality.

But physical safety requires additional enforcement.

Motion limits, emergency stops, watchdogs, and independent safety controls should not depend entirely on the correctness of a high-level AI model.

A robot that receives an unsafe instruction should still have a lower-level mechanism capable of refusing it.

That is not simply an AI-safety problem or a cybersecurity problem.

It is a systems-engineering problem involving both.

Why Small Open Robotics Projects Matter

Large humanoid robots are expensive, complex, and potentially dangerous research platforms.

Small robots offer a different opportunity.

They make it possible to study sensor trust, software-update integrity, wireless security, authorization boundaries, and AI behavior in a more accessible environment.

Projects such as Microduck, XGO-Duck, and Open Duck Mini bring hardware, software, and machine learning closer together.

They could also serve as useful platforms for developing repeatable, controlled security-testing methodologies.

Researchers can explore systems in simulation, inspect source code, and validate defensive designs without immediately experimenting on large industrial machines.

Of course, a small robot is not a perfect substitute for an industrial manipulator or humanoid. The mechanical risks, computing environments, communications systems, and operational requirements can be very different.

But the underlying security questions are often similar.

Who controls the machine?

What information does it trust?

What happens when its software behaves unexpectedly?

And what stops a cyberattack from becoming a physical incident?

The Next Security Frontier Has a Physical Body

Robotics is evolving from isolated industrial automation toward increasingly programmable, connected, and AI-assisted machines.

This transition presents enormous opportunities.

It also means cybersecurity needs to expand its assumptions about what a successful attack can affect.

The future threat is not simply that someone might steal data from a robot.

It is that attackers may be able to influence what a robot perceives, what it decides, and ultimately what it does.

The good news is that the security community does not need to start from zero.

We already understand authentication, isolation, secure boot, update integrity, vulnerability management, and least privilege.

The challenge is applying those principles to systems where failures can have physical consequences.

Microduck is an interesting reminder of how accessible robotics has become.

And emerging research on embodied-AI manipulation suggests the next set of attack surfaces may be very different from those we are used to.

We have spent decades learning how to secure software. Now we need to secure what software can do.

Follow the jpalanco.com blog for more writing on AI, engineering and security. For complementary application-security research, visit the Plexicus blog. If you build robotics software, make each trust boundary visible and test the controls that enforce it.

Sources

• Pollen Robotics: Microduck
• Pollen Robotics: Microduck source repository
• Pollen Robotics: signed updater and rollback design
• Microduck PR #453: documentation-only LAN-auth clarification
• UC Santa Cruz: embodied-AI security research
• CHAI: Command Hijacking against embodied AI
• Microduck issue #443: LAN authentication and documentation scope