Sandbox de agentes de IA y permisos del teléfono: por qué aún hacen falta límites

Por qué el sandbox de agentes de IA importa ahora

El sandbox de agentes de IA se ha convertido en un tema práctico porque los agentes modernos ya no viven solo en una ventana de chat. Pueden escribir código, leer y modificar archivos, usar herramientas, mantener una tarea durante más tiempo y volver a un estado anterior cuando algo cambia. Ese tipo de trabajo necesita un entorno separado y controlado, sobre todo cuando entran credenciales, datos de usuario, conexiones de red y tareas que se ejecutan en varios pasos.

El 15 de julio de 2026, Perplexity Research presentó SPACE como una plataforma segura y eficiente para flujos largos de agentes e ejecución de código aislada. Su explicación parte de una necesidad clara: los agentes necesitan entornos que puedan ejecutar código, editar sistemas de archivos, completar tareas de varios pasos, conservar estado duradero y proteger hosts, usuarios, organizaciones y credenciales sensibles.

La señal no está en que Perplexity haya lanzado una función más. Está en que la infraestructura para agentes empieza a parecerse menos a una sesión temporal y más a un espacio de trabajo persistente. Si un agente va a analizar datos, probar código, preparar archivos o coordinar acciones durante minutos u horas, el sistema necesita separarlo del host y controlar qué recursos toca. Esa separación es especialmente importante cuando el agente puede cometer errores, llamar herramientas en mal orden o encontrarse con contenido no confiable.

Para un phone agent, la lección es directa: aislar el trabajo del agente es necesario, pero es solo una parte del diseño. En un teléfono Android, además de aislar razonamiento o tareas técnicas, hay que decidir qué permisos se conceden, qué acciones están soportadas, qué ve el usuario y qué requiere confirmación. En FoneClaw, esa segunda parte es central: modelos configurables pueden impulsar el agente, mientras FoneClaw mantiene las acciones Android dentro de recorridos visibles y autorizados.

Qué resuelve un entorno aislado para agentes largos

Un entorno aislado bien diseñado resuelve problemas que aparecen cuando un agente trabaja más allá de una respuesta breve. Puede crear un espacio temporal para ejecutar código, separar archivos de una sesión, limitar recursos, conservar estado y recuperar una tarea si el proceso se pausa. También permite que varias sesiones convivan sin mezclarse, algo crítico cuando los agentes trabajan para usuarios u organizaciones distintas.

Perplexity Research describe SPACE con varios componentes: un plano de control, servicios locales en el nodo y un sandbox implementado como máquina virtual con un servicio interno que coordina la sesión. En términos sencillos, el agente no trabaja directamente sobre el host principal. Trabaja dentro de un entorno separado que puede arrancar, pausarse, reanudarse, duplicarse o cerrarse con más control.

Las credenciales son otro punto clave. Según Perplexity Research, las credenciales permanecen fuera de los límites del sandbox; el acceso se media mediante un almacén de credenciales, una pasarela, un sistema de resguardo, caducidad, límites de uso y registro de actividad. Esa arquitectura reduce la exposición directa de secretos dentro del espacio donde el agente ejecuta tareas. El agente puede necesitar usar una credencial, pero el sistema decide cómo y cuándo se entrega acceso.

SiliconANGLE informó sobre Perplexity SPACE destacando aislamiento estilo microVM Firecracker, pausa y reanudación, bifurcación de sesiones, aislamiento de credenciales, reenvío y orquestación. Perplexity también indicó que SPACE se desplegó en Computer y reportó millones de creaciones de sandbox, junto con creación más rápida durante la semana de lanzamiento. Para el mercado, esto confirma que la seguridad de agentes ya no es solo una política: también es una cuestión de rendimiento, recuperación y operación a escala.

Qué no autoriza un sandbox en un teléfono Android

El error habitual es pensar que si un agente corre dentro de un entorno aislado, ya está listo para actuar sobre cualquier sistema. En realidad, el sandbox protege el espacio donde trabaja el agente; no concede autoridad sobre el teléfono. Puede aislar código, archivos, red y credenciales, pero no convierte automáticamente una intención en una llamada, un mensaje, un pago, un cambio de ajustes o una acción dentro de otra app de Android.

Un teléfono tiene reglas propias. Las llamadas requieren rutas autorizadas por Android y la app correspondiente. Los mensajes necesitan permisos y revisión de destinatario y contenido. Los pagos piden confirmación del usuario y controles de la app financiera. Los ajustes del sistema están protegidos por permisos concretos. Las acciones entre apps pueden depender de intents, accesibilidad, APIs de la app o pasos visibles en pantalla. Un sandbox no sustituye ese marco; opera en otro nivel del problema.

Esto importa porque muchos anuncios de agentes mezclan seguridad de cómputo con autoridad sobre acciones. Un agente puede estar bien aislado y aun así necesitar una confirmación humana para enviar algo. Puede mantener credenciales fuera de su entorno y aun así requerir permiso para leer notificaciones. Puede ejecutar código de forma separada y aun así no tener un camino Android compatible para cambiar una configuración. La seguridad del entorno y el permiso del teléfono se complementan, pero no son lo mismo.

En FoneClaw, tratamos las acciones Android como un recorrido visible y autorizado. Si un modelo configurable propone una tarea, FoneClaw valida si esa acción está soportada, muestra el resultado, solicita permisos cuando hacen falta y pide confirmación en pasos sensibles. Para profundizar en por qué las habilidades de agentes móviles necesitan permisos en tiempo real, nuestra guía sobre Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real desarrolla esa diferencia desde el punto de vista del usuario.

Permisos, confirmaciones y huella visible en el móvil

En un teléfono, la confianza se construye con señales que el usuario puede comprobar. El agente debe mostrar qué va a hacer, qué app toca, qué permiso usa y qué resultado se espera. Si la tarea afecta a otra persona, dinero, datos privados, cuenta, ubicación o ajustes, el flujo debe detenerse para que el usuario confirme. Esa revisión no es un obstáculo: es la forma de convertir una instrucción de IA en una acción responsable.

El registro visible también importa. En un entorno técnico, SPACE habla de mediación de credenciales, caducidad, límites de uso y registro de actividad. En el móvil, la idea equivalente para el usuario es saber qué acción se preparó, qué permiso intervino y dónde terminó el recorrido. Un agente telefónico que solo dice hecho deja demasiada incertidumbre. Uno que muestra el paso, el contenido y la confirmación genera una experiencia mucho más clara.

La confiabilidad operativa también tiene una dimensión práctica. El historial de estado de Perplexity para Computer sandbox mostró incidencias de sandbox a comienzos de julio de 2026, recordando que estos entornos también son sistemas vivos. Pausa, reanudación y recuperación son funciones útiles, pero cualquier infraestructura puede tener interrupciones. Cuando un agente quiere actuar sobre un teléfono, el producto debe prever cómo reanudar, cancelar o dejar al usuario en un punto seguro del recorrido.

Esta es la razón por la que comparamos aislamiento de agente con permisos del teléfono sin confundirlos. El aislamiento protege el trabajo interno. Los permisos, confirmaciones y estados visibles protegen la acción sobre el móvil. Para una comparación más amplia entre control local, seguridad en la nube y confianza operativa, puede ser útil leer Confianza en agentes de IA: control local en Android frente a seguridad en la nube, que sitúa estas decisiones en un mapa más amplio de producto.

La lectura de FoneClaw: modelos configurables y acciones compatibles

FoneClaw es un phone agent. Puede ser impulsado por modelos configurables para entender instrucciones, razonar sobre pasos y planificar una tarea. FoneClaw es el entorno que realiza acciones Android compatibles, no una promesa de control universal sobre cualquier app. Esta separación permite aprovechar modelos cada vez más capaces sin perder el marco de permisos, confirmación y visibilidad que exige el móvil.

Desde nuestra perspectiva de producto, un sandbox de agentes de IA resuelve muy bien una parte del problema: cómo aislar trabajo técnico, credenciales y estado prolongado. FoneClaw se ocupa de otra parte: cómo llevar una intención a una acción Android soportada que el usuario pueda ver y aprobar. Cuando una acción requiere permiso, FoneClaw lo trata como parte del flujo. Cuando la acción toca algo sensible, FoneClaw solicita confirmación. Cuando una acción no está soportada, FoneClaw ofrece una ruta práctica dentro de lo posible.

Esto también evita confusiones con modelos configurables. FoneClaw más un modelo significa usar ese modelo para impulsar el agente de FoneClaw, no dos experiencias separadas cooperando una al lado de la otra. El modelo ayuda a comprender y planificar; FoneClaw organiza la acción en Android. Así el usuario obtiene flexibilidad de IA sin delegar decisiones sensibles a un componente invisible.

El debate sobre herramientas abiertas y agentes móviles más sueltos muestra por qué esta distinción importa. En nuestra guía sobre Riesgos de seguridad de OpenClaw: cómo compararlo con un agente Android más acotado, el punto central es parecido: la potencia de un agente debe venir acompañada de límites comprensibles. En FoneClaw, esos límites se expresan como acciones compatibles, permisos visibles, confirmaciones y continuidad cuando el teléfono necesita intervención del usuario.

Checklist para evaluar agentes aislados que quieren actuar en un teléfono

Para evaluar cualquier agente que presume de aislamiento y quiere actuar en un teléfono, empieza por separar dos preguntas. Primera: ¿cómo protege su propio trabajo? Aquí importan máquina virtual, separación de archivos, control de red, estado duradero, pausa y reanudación, manejo de credenciales y registro de actividad. Segunda: ¿cómo obtiene permiso para actuar sobre Android? Aquí importan permisos del sistema, acciones soportadas, confirmación del usuario y resultados visibles.

Revisa también qué ocurre con credenciales y datos sensibles. Un buen diseño evita que las credenciales vivan sin control dentro del entorno del agente. Debe haber caducidad, límites de uso y mediación. En el teléfono, esa misma filosofía se traduce en pedir solo los permisos necesarios para la tarea, mostrar por qué se necesitan y permitir que el usuario confirme antes de completar pasos con impacto.

El tercer criterio es la recuperación. Si un agente falla a mitad de tarea, ¿puede reanudar sin repetir acciones peligrosas? Si una app de Android no permite un paso, ¿el producto prepara el contenido y deja al usuario en la pantalla correcta? Si un permiso cambia, ¿el flujo explica qué falta? La resiliencia no consiste solo en volver a iniciar una sesión; consiste en no perder claridad cuando la tarea toca un dispositivo personal.

Para organizaciones, suma una pregunta de gobierno interno: quién puede configurar modelos, qué acciones están permitidas y qué historial queda disponible. Nuestra guía sobre Seguridad de agentes de IA empresariales: cómo evaluar un agente local en el teléfono ayuda a llevar esa evaluación al terreno empresarial. La conclusión para usuarios y equipos es la misma: un sandbox mejora el entorno de trabajo del agente; los permisos y confirmaciones del teléfono siguen siendo el centro cuando la IA quiere realizar acciones reales en Android.