Cuando el software empieza a caminar: Microduck y la nueva frontera de seguridad de la robótica
De los pequeños robots de código abierto a las máquinas conectadas, la IA física da a las vulnerabilidades de software una vía hacia consecuencias físicas.
Durante décadas, la ciberseguridad se ha centrado sobre todo en proteger información: bases de datos, servidores, endpoints, aplicaciones y redes.
Pero los nuevos sistemas conectados plantean un reto distinto.
¿Qué ocurre cuando el software vulnerable puede moverse?
Una aplicación web comprometida podría exponer datos de clientes. Un servidor comprometido podría acabar formando parte de una botnet. Un robot comprometido podría moverse, manipular objetos, interferir en su entorno o actuar en contra de las intenciones de su operador.
El paso del software que procesa información al software que controla comportamientos físicos merece mucha más atención por parte de la comunidad de seguridad.
Y, sorprendentemente, algunas de las plataformas más interesantes para explorar esa transición son robots pequeños que caben en un escritorio.
Microduck: IA física a escala de escritorio
Pollen Robotics describe Microduck como un pequeño robot bípedo cuyos movimientos usan políticas de aprendizaje por refuerzo.
El robot, de 25 centímetros, tiene 15 motores, una cámara, LiDAR y dos unidades de medición inercial. Pollen Robotics enumera comportamientos entrenados como caminar, sentarse, levantarse y agarrar objetos. Estas descripciones del producto no equivalen a una evaluación de seguridad.
Pero lo más interesante no es su aspecto.
Es el software.
Microduck ejecuta políticas de movimiento aprendidas, entrenadas en simulación y transferidas al hardware físico. Su repositorio público del runtime incluye servicios en Rust para el control de motores, la comunicación, la configuración, el contenido multimedia y las actualizaciones de software. Su repositorio de aprendizaje por refuerzo documenta el flujo de simulación y entrenamiento.
Es un ejemplo pequeño pero significativo de cómo la IA física se vuelve accesible para cualquier desarrollador.
También ofrece a los investigadores de seguridad la oportunidad de estudiar un sistema en el que las decisiones del software producen movimiento físico.
El software y la pila de entrenamiento de Microduck se publican como código abierto. Eso no demuestra, por sí solo, que el diseño completo del hardware de producción se haya publicado con una licencia de hardware abierto.
Otros proyectos relacionados amplían las posibilidades de experimentación. XGO-Duck, una adaptación de Luwu Dynamics, ofrece una arquitectura de robot imprimible en 3D con Arduino UNO Q y 15 servos. El proyecto anterior Open Duck Mini también muestra cómo los makers pueden construir y entrenar pequeños robots que caminan.
Para la educación en robótica, esto es emocionante.
Para la ciberseguridad, plantea una pregunta igual de importante: ¿en qué estamos confiando exactamente cuando dejamos que el software controle una máquina?
Un robot es más que un dispositivo IoT con motores
Pensemos en la arquitectura de un robot conectado moderno.
Puede incluir un ordenador de a bordo basado en Linux, interfaces de comunicación inalámbrica, API locales, sensores, controladores de movimiento, políticas de IA entrenadas, actualizaciones remotas de software y, a veces, servicios conectados a la nube.
Cada componente introduce posibles superficies de ataque.
Una vulnerabilidad en una interfaz de comunicación podría permitir un control no autorizado. Una actualización de software comprometida podría alterar el comportamiento del robot. Unos datos de sensores manipulados podrían cambiar la forma en que un sistema autónomo entiende su entorno.
La diferencia crítica está en la salida final.
En lugar de devolver una respuesta a través de una API, el sistema puede mover un motor.
Eso cambia el impacto de un fallo de seguridad.
La confidencialidad y la integridad siguen siendo importantes, pero la seguridad física, la continuidad operativa y la integridad de las órdenes a los actuadores pasan a ser preocupaciones centrales.
La distinción tradicional entre la seguridad de aplicaciones y la seguridad de la tecnología operativa (OT) empieza a difuminarse.
Una vía de control en la red local merece la misma atención que una remota
Una conversación pública del desarrollo de Microduck planteó una pregunta de seguridad útil. A 29 de octubre, la incidencia #443 y la solicitud de cambios #453, limitada a documentación, siguen abiertas. El código actual de señalización LAN y la conversación del proyecto describen esa vía como no autenticada; el acceso remoto mediante rendezvous sí usa autenticación, mientras que el emparejamiento LAN depende de un PIN de fábrica compartido. La PR #453 delimita una afirmación documental y no modifica el mecanismo de autenticación. Esto describe la rama pública de desarrollo: no demuestra que todas las unidades comercializadas usen esta versión ni que alguien la haya explotado.
Ese informe es una observación durante el desarrollo, no una prueba de un ataque confirmado ni una auditoría de seguridad de robots comercializados. Pero muestra por qué los equipos deben distinguir entre acceso local y acceso de confianza. En una red doméstica puede haber dispositivos invitados, portátiles comprometidos y productos del Internet de las cosas. Si una vía local puede llegar a la cámara o al control de movimiento, el diseño debería explicar con claridad cómo se autentica, cómo se individualizan las credenciales de emparejamiento y si la configuración de producción difiere de los valores de desarrollo.
Antes de confiar en una mitigación, revisa el código, la versión y las instrucciones actuales para propietarios. Una corrección documental puede evitar una falsa sensación de protección, pero solo una implementación verificada y una configuración probada demuestran qué permite realmente un dispositivo.
Lo que la arquitectura de Microduck revela sobre seguridad
Uno de los aspectos más interesantes de Microduck es cuánto de su razonamiento de ingeniería está documentado públicamente.
Sus desarrolladores describen los límites entre los servicios responsables de la comunicación, la configuración, las actualizaciones de software, la percepción y el control de motores.
La arquitectura describe servicios separados para el bucle de control, la red, la cámara, la configuración y las actualizaciones. Esa separación permite revisar qué componentes se comunican y qué órdenes acepta cada interfaz. No debe interpretarse como prueba de que el robot aplique todas las propiedades de seguridad que un operador podría esperar.
El diseño del actualizador documenta actualizaciones de software firmadas y mecanismos de reversión pensados para reducir el riesgo de instalar versiones no válidas o defectuosas.
Son decisiones importantes de ingeniería de seguridad.
El repositorio y la conversación de la incidencia documentan un sistema de desarrollo en evolución. Sirven para revisar las suposiciones de diseño, pero no constituyen una auditoría de seguridad independiente de un Microduck comercializado.
Pero ilustran algo valioso: las suposiciones de seguridad son más fáciles de examinar cuando las decisiones de arquitectura se documentan en público.
El código abierto no hace que un robot sea seguro automáticamente.
Sin embargo, sí crea oportunidades para inspeccionar las decisiones de implementación, identificar debilidades, mejorar las protecciones y reproducir la investigación de seguridad.
En un sistema físico, esa visibilidad puede ser especialmente importante.
La IA introduce otra superficie de ataque: la percepción
La ciberseguridad tradicional suele centrarse en manipular código, credenciales, protocolos o datos.
La IA encarnada (embodied AI) añade otra posibilidad.
¿Y si un atacante no necesita modificar el software del robot?
¿Y si basta con manipular lo que el robot ve?
En enero de 2026, la Universidad de California en Santa Cruz anunció una investigación sobre ataques de inyección indirecta de prompts a través del entorno (environmental indirect prompt injection) contra sistemas de IA encarnada. El artículo en el que se basa, CHAI: Command Hijacking against embodied AI, escrito junto con investigadores de la Universidad Johns Hopkins, se publicó por primera vez en arXiv en septiembre de 2025.
Los investigadores estudiaron cómo instrucciones maliciosas incrustadas en textos del mundo físico podían influir en sistemas autónomos que interpretan información visual mediante modelos de lenguaje. Probaron decisiones de conducción con fotos reales de carreteras, tareas de drones en simuladores de alta fidelidad y un pequeño coche robótico que circulaba de forma autónoma por un edificio universitario.
Una señal, una etiqueta u otro objeto visible podría convertirse en un canal de instrucciones no previsto.
Es un problema distinto de límites de confianza.
El robot debe distinguir entre la información del entorno que debe observar y las instrucciones autorizadas que tiene permitido ejecutar.
Que un modelo visual lea una señal no significa que esté autorizado a obedecerla.
La distinción es especialmente importante en robots que combinan modelos de visión y lenguaje con navegación, manipulación o planificación de tareas.
Las políticas de movimiento estándar de Microduck no son, en sí mismas, ejemplos de inyección de prompts en modelos de lenguaje. Pero plataformas como Microduck facilitan experimentar con capas adicionales de percepción y planificación en las que pueden surgir estos problemas.
La lección va más allá de un robot concreto.
Cuando los sistemas de IA operan en el mundo físico, las entradas no confiables del entorno nunca deben convertirse automáticamente en órdenes de confianza.
Modelo conceptual de revisión, no representa la arquitectura implementada de Microduck.
La robótica necesita seguridad en tres fronteras
Creo que la seguridad robótica debe entenderse a través de tres fronteras de confianza distintas.
La frontera de la comunicación: ¿quién está autorizado a conectarse al robot, acceder a sus sensores, cambiar su configuración o darle órdenes?
La frontera de la inteligencia: ¿qué entradas pueden influir en las decisiones del robot y cómo evitamos que información no confiable se convierta en instrucciones con autoridad?
La frontera física: ¿qué acciones puede ejecutar el robot, independientemente de lo que pida un operador remoto o una política de IA?
Estas fronteras requieren protecciones diferentes.
La autenticación y el cifrado de red protegen la comunicación. La firma de software y los controles de la cadena de suministro protegen las actualizaciones. Los modelos de permisos y el aislamiento de servicios restringen el acceso a las funciones sensibles.
Pero la seguridad física exige controles adicionales.
Los límites de movimiento, las paradas de emergencia, los watchdogs y los controles de seguridad independientes no deberían depender por completo de que un modelo de IA de alto nivel funcione correctamente.
Un robot que recibe una instrucción insegura debería seguir teniendo un mecanismo de nivel inferior capaz de rechazarla.
No es solo un problema de seguridad de la IA ni solo un problema de ciberseguridad.
Es un problema de ingeniería de sistemas que implica a ambos.
Por qué importan los pequeños proyectos de robótica abierta
Los grandes robots humanoides son plataformas de investigación caras, complejas y potencialmente peligrosas.
Los robots pequeños ofrecen una oportunidad distinta.
Permiten estudiar la confianza en los sensores, la integridad de las actualizaciones de software, la seguridad inalámbrica, los límites de autorización y el comportamiento de la IA en un entorno más accesible.
Proyectos como Microduck, XGO-Duck y Open Duck Mini acercan el hardware, el software y el aprendizaje automático.
También podrían servir como plataformas útiles para desarrollar metodologías de pruebas de seguridad repetibles y controladas.
Los investigadores pueden explorar los sistemas en simulación, inspeccionar el código fuente y validar diseños defensivos sin experimentar de inmediato con grandes máquinas industriales.
Por supuesto, un robot pequeño no es un sustituto perfecto de un manipulador industrial o de un humanoide. Los riesgos mecánicos, los entornos de computación, los sistemas de comunicaciones y los requisitos operativos pueden ser muy diferentes.
Pero las preguntas de seguridad de fondo suelen ser parecidas.
¿Quién controla la máquina?
¿En qué información confía?
¿Qué ocurre cuando su software se comporta de forma inesperada?
¿Y qué impide que un ciberataque se convierta en un incidente físico?
La nueva frontera de la seguridad tiene cuerpo
La robótica evoluciona desde la automatización industrial aislada hacia máquinas cada vez más programables, conectadas y asistidas por IA.
Esta transición presenta enormes oportunidades.
También significa que la ciberseguridad debe ampliar sus suposiciones sobre lo que puede afectar un ataque con éxito.
La amenaza futura no es simplemente que alguien pueda robar datos de un robot.
Es que los atacantes puedan influir en lo que un robot percibe, en lo que decide y, en última instancia, en lo que hace.
La buena noticia es que la comunidad de seguridad no tiene que empezar de cero.
Ya entendemos la autenticación, el aislamiento, el arranque seguro, la integridad de las actualizaciones, la gestión de vulnerabilidades y el mínimo privilegio.
El reto es aplicar esos principios a sistemas en los que los fallos pueden tener consecuencias físicas.
Microduck es un recordatorio interesante de lo accesible que se ha vuelto la robótica.
Y la investigación emergente sobre la manipulación de la IA encarnada sugiere que las próximas superficies de ataque pueden ser muy distintas de las que conocemos.
Llevamos décadas aprendiendo a proteger el software. Ahora tenemos que proteger lo que el software puede hacer.
Sigue el blog de jpalanco.com para leer más sobre IA, ingeniería y seguridad. Para investigaciones complementarias sobre seguridad de aplicaciones, visita el blog de Plexicus. Si desarrollas software para robótica, haz visibles todos los límites de confianza y prueba los controles que los hacen cumplir.
Fuentes
- Pollen Robotics: Microduck
- Pollen Robotics: repositorio de Microduck
- Pollen Robotics: diseño del actualizador firmado y la reversión
- PR #453 de Microduck: aclaración documental sobre autenticación LAN
- UC Santa Cruz: investigación sobre seguridad de IA encarnada
- CHAI: Command Hijacking against embodied AI
- Incidencia #443 de Microduck: autenticación LAN y alcance de la documentación
