Sandbox de agentes de IA y permisos Android: tres capas que no se sustituyen
Distingue aislamiento del agente, permisos Android y aprobación de acciones con un ejemplo de análisis remoto convertido en borrador revisable en el teléfono.
- Un sandbox de agente, los permisos Android y la aprobación de una acción responden a preguntas distintas: dónde corre el trabajo, qué puede tocar la app y qué decide hacer el usuario.
- Android ya aísla apps con su propio modelo de sandbox y permisos; autorizar un permiso no valida automáticamente el destinatario, el texto o el resultado de una acción.
- Un sandbox como gVisor puede limitar el contacto con el host, pero los archivos mapeados y la red permitida siguen siendo recursos disponibles si la política los habilita.
- FoneClaw ayuda con acciones Android compatibles y revisables; introducir texto en un campo no envía el mensaje y un resultado incierto debe inspeccionarse antes de repetir la acción.
Tres protecciones responden a preguntas distintas
Hablar de sandbox de agentes de IA y permisos Android como si fuera una sola barrera lleva a malas decisiones. En la práctica hay tres capas. La primera es el entorno donde trabaja el agente: archivos, red, proceso, memoria y recursos disponibles. La segunda es el modelo de Android: aislamiento de apps, permisos de sistema y rutas aprobadas para compartir datos. La tercera es la aprobación de una acción concreta: a quién se envía algo, qué texto se coloca, qué app se abre y qué resultado ve el usuario.
| Capa | Qué controla | Qué no decide | Comprobación útil |
|---|---|---|---|
| Sandbox de ejecución | Dónde corre el trabajo del agente y qué recursos puede usar | No autoriza acciones sobre el teléfono | Archivos accesibles, red permitida, estado y recuperación |
| Permisos Android | Datos o acciones restringidas que una app puede solicitar | No valida destinatario, contenido ni intención comercial | Permiso necesario, app correcta y alcance mínimo |
| Aprobación de acción | Si el usuario acepta un paso visible o sensible | No reemplaza el aislamiento del entorno | Destino, texto, cuenta y resultado final |
Android ya tiene su propio sandbox de aplicaciones. Las apps se aíslan mediante usuarios y procesos Linux, con aplicación a nivel de kernel, y normalmente no pueden acceder a datos privados de otras apps salvo por rutas aprobadas de uso compartido, como resume la documentación oficial del sandbox de aplicaciones Android. FoneClaw no sustituye esa capa del sistema: trabaja dentro de acciones Android compatibles y resultados revisables.
Un sandbox también necesita límites de archivos y red
Un sandbox reduce el alcance de un agente, pero no significa “sin internet”, “sin archivos” o “sin salida de datos”. gVisor sirve como ejemplo de ejecución aislada: añade una barrera entre aplicaciones dentro del sandbox y el kernel del host, y también contempla que las aplicaciones aisladas usen archivos mapeados y recursos de red permitidos si la configuración lo habilita, según su guía de arquitectura de seguridad.
La conclusión práctica es sencilla: el aislamiento es parte de una arquitectura de seguridad, no una decisión automática sobre qué datos conviene compartir. Si un flujo de agente recibe un archivo de cliente y tiene red habilitada, hay que preguntar qué archivo se montó, qué destino de red está permitido, qué credenciales intervienen y qué registro queda. La contención técnica y la política de acceso deben revisarse por separado.
En móviles ocurre lo mismo con otra forma: una app puede tener permiso para una categoría de datos y aun así necesitar controles de producto para decidir cuándo usarla, qué mostrar al usuario y cómo evitar pasos invisibles.
El acceso Android y la aprobación de acciones son cosas separadas
Los permisos Android protegen datos restringidos y acciones restringidas, pero no son una aprobación universal de todo lo que una app quiera hacer después. Android distingue permisos en instalación, permisos en tiempo de ejecución y permisos especiales, y recomienda pedir solo el acceso necesario en el momento adecuado en la guía oficial de permisos Android.
Ese detalle importa en un agente móvil. Conceder acceso a una función no significa que el usuario haya aprobado un destinatario, un importe, una cuenta, una dirección o un mensaje concreto. Por ejemplo, una app puede tener una ruta compatible para colocar texto en un campo visible, pero el usuario aún debe revisar el contenido y decidir si lo envía.
En FoneClaw tratamos esas capas por separado. Podemos identificar el estado visible de una pantalla compatible, ayudar a preparar una acción Android admitida y colocar texto en un campo editable cuando el flujo lo permite. La entrada de texto no pulsa Enviar, no publica y no presiona Enter. Las aprobaciones dependen de la configuración global y de la política de cada acción, de modo que las tareas sensibles deben configurarse con revisión explícita.
Para profundizar en permisos por habilidad y revisión en tiempo real, Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real desarrolla esta capa desde el punto de vista del producto móvil.
Convierte un análisis en un borrador revisado en el teléfono
Este flujo es un ejemplo ilustrativo de trabajo seguro entre capas. Supón que tienes un análisis remoto no sensible: “El proveedor confirma retraso de dos días; conviene avisar al cliente y ofrecer nueva fecha de recogida”. Ese análisis puede venir de una herramienta externa, un documento o una conversación. No hay traspaso automático de sandbox a FoneClaw: el usuario aporta manualmente el texto necesario y decide qué parte debe llegar al teléfono.
- Reduce el análisis a lo mínimo: proveedor, retraso, nueva fecha ya confirmada por el usuario y tono deseado.
- Elige el destinatario dentro de la app de mensajería o correo que vas a usar.
- Pide un borrador: “Prepara un mensaje breve para Laura: el pedido se retrasa dos días y, según confirmamos, estará listo el viernes. No lo envíes”.
- FoneClaw puede ayudar a leer la pantalla visible compatible y colocar el texto en un campo editable si la app lo permite.
- Revisa destinatario, conversación, texto completo y cualquier promesa antes de enviar manualmente o aprobar el siguiente paso si tu configuración lo requiere.
El resultado correcto no es “el agente dijo hecho”. El resultado correcto es un borrador visible en el lugar adecuado, con contenido revisado y una decisión de envío separada. Si el modelo online configurado procesa el contexto suministrado, ese procesamiento sigue las condiciones de ese proveedor; ejecutar el paso en el teléfono no demuestra por sí solo que todo el razonamiento haya sido local.
Esta separación es la base de un agente Android útil. Controlar un teléfono Android con agente de IA: de intención a acción verificada explica cómo pasar de una intención a una acción visible sin convertir cada recomendación del modelo en una operación automática.
Recupérate sin repetir una acción incierta
La recuperación importa tanto como la aprobación. Un sandbox puede volver a un estado interno anterior, pero eso no revierte una acción externa que ya salió del entorno, como un mensaje enviado o un cambio guardado en una app. En un teléfono, la regla segura es inspeccionar el estado real antes de repetir.
| Fallo | Qué significa | Recuperación segura |
|---|---|---|
| Permiso denegado | La app no tiene la autoridad necesaria | Detén el flujo, explica qué falta y permite una ruta manual |
| La pantalla cambió | El objetivo visible ya no es el mismo | Vuelve a leer la pantalla antes de tocar o escribir |
| Envío incierto | No se sabe si la acción externa ocurrió | Abre la app y revisa estado enviado, pendiente o borrador antes de intentar de nuevo |
| Checkpoint restaurado | Se recupera el entorno del agente | No asumas que se deshizo lo que ya salió a otra app o persona |
En FoneClaw, cuando el resultado es incierto, conviene inspeccionar la app real antes de repetir una acción visible para otra persona. Para una guía más detallada de investigación y recuperación, consulta Cómo depurar y recuperar fallos de un agente móvil Android sin repetir acciones peligrosas.
Pide evidencia en cada capa
La checklist final debe cubrir tres preguntas. En el entorno de agente: ¿qué archivos, red, credenciales y estado tiene disponibles? En Android: ¿qué permiso o pantalla concreta necesita y por qué? En la acción: ¿qué destinatario, cuenta, texto o resultado va a quedar después?
También pregunta qué ocurre con el contexto. Un modelo online puede procesar información suministrada para la tarea, mientras que una app del teléfono puede ejecutar solo el paso visible. Esa diferencia entre control local, nube y confianza se desarrolla en Confianza en agentes de IA: control local en Android frente a seguridad en la nube.
Para revisar el alcance actual de nuestras acciones Android, consulta las funciones de FoneClaw. La evaluación sólida no busca una palabra mágica como “sandbox” o “permiso”; busca evidencia en cada capa y un resultado que el usuario pueda comprobar.