Los agentes de IA en el navegador necesitan un navegador propio
Darle a un agente autónomo tu navegador de uso diario le entrega tus cookies, tus inicios de sesión y tu dispositivo. Por qué los agentes pertenecen a un perfil aislado y cómo dárselo.
La forma más rápida de dar a un agente de IA una capacidad real en la web es dejarle manejar un navegador. La forma más rápida de arrepentirse es dejarle manejar el tuyo. Un navegador de uso diario guarda todas las sesiones en las que has iniciado sesión alguna vez, y un agente que puede hacer clic puede hacer clic en cualquier cosa a la que esas sesiones den acceso.
El problema del radio de impacto
Un agente al que se le pide investigar proveedores no tiene intención de abrir la pestaña de tu banco. Pero el navegador en el que se ejecuta no distingue: un único almacén de cookies, un único conjunto de inicios de sesión guardados, una única identidad de equipo. Dondequiera que el agente pueda navegar, ya está autenticado. Las medidas a las que se recurre primero (otro perfil de Chrome, una ventana de incógnito) mueven las cookies sin mover nada más.
Qué tiene que cubrir realmente el aislamiento
- Almacenamiento: su propio almacén de cookies, Local Storage e IndexedDB, en un directorio en el que no escribe nada más
- Credenciales: solo los inicios de sesión que hayas puesto deliberadamente en ese perfil, y ninguno más
- Red: su propia ruta, para que el tráfico del agente y el tuyo no salgan por la misma dirección
- Identidad del dispositivo: estable para ese perfil y no una copia del equipo en el que trabajas
- Extensiones: solo las que el agente necesita, no tu gestor de contraseñas
Esa lista es la misma que ya cumple un perfil de navegador aislado. Un agente es, desde el punto de vista del navegador, un usuario más de tu equipo que no debería poder ver el resto de tu trabajo.
Cómo darle un perfil a un agente
En PowerOps el patrón es corto. Crea un perfil para el agente, dale la ruta por la que quieres que salga su tráfico e inicia sesión solo en las cuentas que esa tarea necesita. Luego arráncalo desde la Local API, que devuelve el endpoint de depuración del navegador, y apunta tu framework de agentes a ese endpoint en lugar de a un navegador que haya lanzado él mismo.
# Start the agent's profile and take the endpoint it returns.
curl -s -X POST http://127.0.0.1:50326/v1/browsers/start \
-H "Authorization: Bearer $POWEROPS_KEY" \
-H "Content-Type: application/json" \
-d '{"profileId": "agent-research-01"}'Cualquier cosa que hable el Chrome DevTools Protocol se conecta a lo que devuelve esa llamada: Puppeteer, Playwright o un framework de agentes que envuelva cualquiera de los dos. El código del agente no cambia en nada; lo que cambia es el navegador en el que aterriza.
Un perfil por tarea, no por agente
El instinto es dar un perfil al agente. La mejor unidad es la tarea. Un perfil para la investigación de proveedores, otro para la cuenta desde la que se le permite publicar, otro para el panel que lee. Si una ejecución sale mal, el daño queda acotado por lo que ese único perfil podía alcanzar, y puedes tirar el directorio y empezar de nuevo.
Mantener las ejecuciones comparables
Los agentes son difíciles de depurar porque dos ejecuciones rara vez son la misma ejecución. Un perfil que informa del mismo dispositivo en cada arranque, desde la misma ruta y con el estado en que lo dejaste, elimina toda una clase de diferencias entre intentos. Cuando una ejecución se comporta de otra manera, el entorno deja de estar entre los sospechosos.
El límite
Nada de esto es una forma de saltarse las condiciones de un sitio, sus límites de peticiones o su política de robots, y no se vende como tal. Lo que da a un agente es un navegador que pertenece a la tarea y no a ti.
