Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real

Un escaneo limpio no equivale a confianza

El problema para un usuario no empieza cuando una habilidad de agente parece claramente peligrosa. Empieza cuando parece normal. Un complemento puede tener una descripción útil, un nombre razonable y una revisión automática sin alertas graves, pero aun así comportarse de otra manera cuando el agente lo ejecuta con contexto real. Por eso la seguridad de habilidades de agentes de IA no debe confundirse con una etiqueta de aprobado en el momento de instalación.

El 6 de julio de 2026, The Hacker News informó sobre SkillCloak, una técnica descrita por investigadores para que habilidades maliciosas de agentes de IA evadan revisiones estáticas mediante empaquetado autoextraíble. La señal no es que todo plugin sea malicioso ni que todo escáner sea inútil. La señal es más concreta: una revisión que solo mira archivos, manifiestos o patrones antes de ejecutar puede no ver lo que una habilidad hará después.

El trabajo asociado, publicado como preprint en arXiv bajo el título Cloak and Detonate, propone SkillDetonate como un enfoque centrado en observar comportamiento durante la ejecución. Al ser un preprint, sus resultados deben leerse como hallazgos de investigación, no como garantías generales para toda la industria. Aun así, la dirección es valiosa: la confianza no debe terminar en el escaneo inicial. La regla práctica es exigir controles durante la acción, especialmente si el agente puede leer datos, llamar herramientas o modificar algo en nombre del usuario.

Lo importante es cómo se comporta al actuar

Una habilidad puede declarar una intención inocente y comportarse de forma distinta cuando recibe instrucciones, archivos, credenciales, contexto del usuario o acceso a herramientas. Por eso los controles de permisos en tiempo de ejecución son tan importantes: miran qué intenta hacer el agente en el momento concreto, con qué datos y bajo qué autorización. No sustituyen a la revisión previa, pero cubren una zona que el análisis estático no ve bien.

En la práctica, esto significa aislamiento, límites de datos y observación de comportamiento. Si una habilidad para resumir notas intenta acceder a contactos, exportar archivos o invocar una herramienta no relacionada, el sistema debería detenerse o pedir una aprobación explícita. Si un plugin cambia de comportamiento después de desempaquetarse, la revisión debería mirar llamadas, flujos de información y acciones solicitadas, no solo el archivo original. La pregunta correcta no es solo si la habilidad parece segura, sino si actúa dentro del propósito que el usuario aceptó.

Los registros también son parte del control. Un historial revisable permite saber qué permiso se usó, qué dato se leyó, qué herramienta se llamó y qué resultado dejó la tarea. Este patrón se parece a los registros de permisos de agentes de IA usados para explicar consentimiento e historial visible: no basta con confiar en una promesa general, hay que poder revisar eventos concretos. En agentes móviles, esa revisión debe ser simple, porque el usuario no debería leer trazas técnicas para entender si un mensaje fue preparado, enviado o descartado.

Por qué el riesgo crece cuando el agente toca el móvil

Un agente en un entorno de pruebas puede equivocarse y generar texto incorrecto. Un agente en un teléfono puede tocar vida personal. Mensajes, contactos, notificaciones, calendario, archivos, cámara, micrófono, ubicación, ajustes y cuentas tienen consecuencias distintas. Una habilidad que parece útil para organizar tareas podría pedir leer notificaciones; otra que promete responder mensajes podría necesitar contactos; otra que automatiza ajustes podría cambiar preferencias del sistema. Cada paso requiere una frontera clara.

OWASP Top 10 for LLM Applications describe categorías relevantes para este escenario, como inyección de instrucciones, vulnerabilidades en componentes externos, diseño inseguro de plugins, exceso de autonomía y exposición de información sensible. Estas categorías no dicen que todo agente móvil sea inseguro, pero ayudan a pensar en riesgos de plugins de IA cuando el agente tiene herramientas y permisos. El peligro no es solo una respuesta mala; es que una instrucción manipulada lleve a una acción no deseada.

Android trata muchos accesos como capacidades concedidas por el usuario y controladas por el sistema. La documentación de Android Developers sobre permisos muestra que no todos los permisos tienen el mismo nivel de sensibilidad. Para un agente de teléfono, eso implica respetar permisos de agentes en el móvil como límites reales, no como trámites. Además, la decisión entre procesar contexto en el dispositivo o fuera de él cambia el perfil de riesgo; por eso el debate sobre agente de IA en la nube frente a uno local importa cuando el contexto incluye mensajes, notificaciones o cuentas personales.

El modelo práctico: permisos mínimos, confirmación y registros

Un buen modelo de permisos para agentes empieza con privilegio mínimo. Si una habilidad solo necesita preparar un borrador, no debería tener permiso para enviarlo. Si debe resumir notificaciones, no debería acceder a fotos, contactos o ubicación. Si una acción requiere leer un archivo, ese permiso debería limitarse al archivo o carpeta necesarios. Cuanto más amplia sea la capacidad, más fuerte debe ser la confirmación y más claro el registro posterior.

La segunda regla es pedir permiso en el momento adecuado. Una solicitud genérica al instalar todo no ayuda al usuario a decidir. Es más comprensible pedir confirmación cuando el agente va a leer mensajes, enviar una respuesta, modificar un ajuste, crear un evento o compartir información. La pantalla de aprobación debe explicar propósito, app afectada, dato usado y consecuencia. Confirmar preparar un mensaje no es lo mismo que confirmar enviarlo. Abrir ajustes no es lo mismo que cambiar un valor.

La tercera regla es dejar un historial entendible. Los controles empresariales son más amplios que las solicitudes de permiso de un agente móvil de consumo; incluyen políticas, aislamiento, inventario, revisiones y respuesta ante incidentes. Esa visión más amplia se conecta con la seguridad de agentes de IA en empresas, pero en el teléfono el usuario necesita algo más directo: qué habilidad actuó, qué permiso usó, qué acción quedó pendiente, qué se completó y cómo revocar o corregir cuando sea posible. Sin ese registro, no hay confianza práctica, solo una promesa.

Lista para evaluar habilidades y agentes móviles

No hace falta caer en alarmismo para evaluar una habilidad de agente. Empieza por la procedencia: quién la publica, qué permisos pide, qué función declara y si hay una forma razonable de desinstalarla o desactivarla. Después mira el alcance: una habilidad de notas no debería pedir acceso amplio a contactos; una habilidad de calendario no debería tocar mensajes sin explicación; una herramienta de búsqueda no debería necesitar permisos de ubicación si no los usa claramente.

El segundo bloque de preguntas aparece durante la acción. ¿El agente muestra qué va a hacer antes de hacerlo? ¿Distingue entre leer, preparar, enviar, borrar y cambiar? ¿Pide aprobación cuando hay datos sensibles? ¿Se detiene si falta permiso? ¿Explica cuándo una tarea no está soportada? Estas preguntas importan más que el nombre del escáner que aprobó el paquete, porque la seguridad real se decide cuando el agente usa contexto del usuario.

El tercer bloque mira el después. ¿Hay un registro legible? ¿Puedes ver qué habilidad participó? ¿Puedes revocar permisos? ¿Se registran errores y cancelaciones, no solo éxitos? ¿El sistema permite revisar acciones sin exponer más datos de los necesarios? Una habilidad no debe considerarse segura solo porque no disparó alertas al instalar. Debe mantenerse dentro de su propósito mientras actúa, y el usuario debe poder comprobarlo.

Qué debe aprender FoneClaw de esta discusión

FoneClaw es independiente de The Hacker News, arXiv, OWASP, Android, Google, Claude Code, OpenAI Codex, OpenClaw y cualquier proveedor de seguridad mencionado en esta discusión. No debe insinuar que fue afectado por SkillCloak, que escanea habilidades de terceros o que garantiza seguridad absoluta. La lección relevante es de diseño: un agente IA para Android debe hacer que las acciones compatibles sean visibles, conscientes de permisos y guiadas por confirmación.

Eso significa no tratar un permiso concedido como autorización permanente para todo. Si una tarea toca mensajes, contactos, notificaciones, ajustes, archivos o cuentas, FoneClaw debería mostrar estado, pedir aprobación en acciones sensibles y dejar registros revisables. También debería reconocer límites: si Android no concede un permiso, si una app no permite una acción o si una habilidad intenta salir de su propósito, el agente debe detenerse o pedir intervención humana.

La seguridad de habilidades de agentes de IA obliga a cambiar la pregunta. Ya no basta con preguntar si un paquete se ve limpio antes de instalar. Hay que preguntar qué hace cuando tiene contexto, qué permisos intenta usar, qué confirma el usuario y qué historial queda. En el móvil, esa pregunta pesa más porque las acciones ocurren sobre datos personales y apps reales. Un agente confiable no es el que promete que nada saldrá mal, sino el que reduce alcance, pide permiso a tiempo y permite revisar lo que pasó.

Fuentes: The Hacker News sobre SkillCloak, preprint Cloak and Detonate en arXiv, OWASP GenAI Security Project y Android Developers sobre permisos. Estas fuentes apoyan el análisis de escaneo, comportamiento, riesgos de plugins y permisos; no implican respaldo a FoneClaw ni eliminan la necesidad de controles propios.