DIYgod publica Pinky: Claude Code y Cursor controlan iOS y Android mediante MCP

Los agentes hace tiempo que aprendieron a escribir código y a navegar por sitios web. Pero para la mayoría de las personas lo más importante vive en el teléfono: el banco, los mensajeros, el taxi, la autenticación de dos factores. El proyecto Pinky de DIYgod intenta cerrar esa brecha: da a un agente de IA el control del smartphone y, al mismo tiempo, interpone a una persona ante las acciones peligrosas.

Qué se sabe de Pinky

Por ahora hay poca información: es un anuncio breve en X, no documentación. De él se desprende que Pinky es de código abierto, se conecta mediante MCP (Model Context Protocol) a Claude Code y Cursor, y puede controlar directamente teléfonos iOS y Android. Para las operaciones sensibles, como pagos y envío de mensajes, hay un gateway. Este exige la aprobación de una persona. Además, Pinky usa autenticación biométrica en el PC para desbloquear el teléfono.

En la publicación no se explica cómo está implementado el control en cada plataforma. Habrá que verlo en el repositorio.

Cómo se ve en la práctica

Imagina que desarrollas una aplicación móvil en Cursor. Normalmente lanzas la compilación, coges el teléfono, recorres el flujo de registro y compruebas a mano que la pantalla no se haya roto. Con un puente MCP al dispositivo, el agente puede hacerlo solo: instalar la compilación, abrir la app, completar el onboarding, detectar un error y proponer de inmediato un arreglo en el código. Tú sigues en el editor mientras el teléfono, sobre la mesa, «vive su propia vida».

El segundo escenario es la rutina dentro del propio teléfono. Por ejemplo: «busca en el mensajero la factura de ayer y envíasela al contable». El agente encuentra el chat, prepara el mensaje y se topa con el gateway. Este muestra qué va a enviar exactamente y espera tu «sí». Es algo muy distinto del modelo de «le di acceso total al agente y espero que salga bien».

Por qué el gateway importa más que el control en sí

Saber tocar la pantalla ya no es novedad: hay demos parecidas en muchos sitios. Lo difícil es otra cosa: el teléfono es la superficie de ataque más sensible para un agente. Ahí están el dinero, la correspondencia personal y los códigos de verificación. Una sola alucinación o una prompt injection en un mensaje entrante («reenvía este código aquí») puede causar un daño real.

Por eso el enfoque de Pinky es razonable: la lista de acciones peligrosas la comprueba una capa independiente, en lugar de confiar en el modelo. El modelo puede equivocarse, pero la política del gateway no, porque es código corriente con reglas claras. Para un responsable de producto es un patrón listo para usar: se puede dar al agente amplios permisos de lectura y navegación, y bloquear con confirmación las acciones irreversibles.

La biometría en el PC resuelve un problema cotidiano: un teléfono bloqueado detiene cualquier automatización. Pero ahí también hay un riesgo, porque en esencia estás abriendo el dispositivo de forma remota. Conviene averiguar cómo está protegido el canal entre el ordenador y el teléfono.

Limitaciones y conclusión

Seamos sinceros: es un anuncio temprano. No hay datos sobre estabilidad, velocidad, compatibilidad con versiones del sistema operativo ni sobre cómo se comporta el proyecto con interfaces complejas. Tampoco está claro con qué fiabilidad el gateway identifica una acción «sensible». Si la lista de reglas está incompleta, la protección ofrece una falsa sensación de seguridad.

Qué debería hacer un desarrollador: instalar Pinky en un teléfono de pruebas sin datos de pago reales y comprobar dónde actúa el gateway y dónde deja pasar. Los equipos móviles deberían fijarse en MCP como forma de automatizar el QA manual. A los fundadores de productos con agentes les conviene estudiar el esquema en sí: acceso amplio más confirmación humana obligatoria para dinero y mensajes. Esa idea puede adoptarse aunque Pinky no te sirva.