Gli agenti AI nel browser hanno bisogno di un browser tutto loro

Affidare a un agente autonomo il browser di tutti i giorni gli consegna i tuoi cookie, i tuoi accessi e il tuo dispositivo. Ecco perché gli agenti appartengono a un profilo isolato e come dargliene uno.
Il modo più rapido per dare a un agente AI vere capacità sul web è lasciargli guidare un browser. Il modo più rapido per pentirsene è lasciargli guidare il tuo. Un browser di uso quotidiano porta con sé ogni sessione a cui hai mai effettuato l'accesso, e un agente che sa cliccare può cliccare su tutto ciò che quelle sessioni raggiungono.
Il problema del raggio d'azione
Un agente a cui si chiede di cercare dei fornitori non ha intenzione di aprire la scheda della tua banca. Ma il browser in cui gira non fa distinzioni: un solo contenitore di cookie, un solo insieme di accessi memorizzati, una sola identità della macchina. Ovunque l'agente possa navigare, è già autenticato. Le misure a cui si ricorre per prime — un profilo Chrome separato, una finestra in incognito — spostano i cookie senza spostare nient'altro.
Che cosa deve coprire davvero l'isolamento
- Archiviazione: un proprio contenitore di cookie, Local Storage e IndexedDB, in una directory su cui nient'altro scrive
- Credenziali: solo gli accessi che hai deliberatamente effettuato in quel profilo, e nessun altro
- Rete: un proprio percorso, così il traffico dell'agente e il tuo non provengono dallo stesso indirizzo
- Identità del dispositivo: stabile per quel profilo, e non una copia della macchina su cui lavori
- Estensioni: solo quelle che servono all'agente, non il tuo gestore di password
Quell'elenco è lo stesso che un profilo isolato del browser già soddisfa. Un agente è, dal punto di vista del browser, soltanto un altro utente della tua macchina che non dovrebbe poter vedere il resto del tuo lavoro.
Dare un profilo a un agente
In PowerOps lo schema è breve. Crea un profilo per l'agente, assegnagli il percorso su cui vuoi il suo traffico e accedi solo agli account che servono per quell'attività. Poi avvialo dalla Local API, che restituisce l'endpoint di debug del browser, e punta il tuo framework per agenti a quell'endpoint anziché a un browser che ha lanciato da solo.
# 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"}'
Qualunque cosa parli il Chrome DevTools Protocol si collega a ciò che quella chiamata restituisce — Puppeteer, Playwright o un framework per agenti che ne incapsula uno. Il codice dell'agente non cambia; cambia il browser in cui approda.
Un profilo per attività, non per agente
L'istinto è dare all'agente un profilo. L'unità migliore è l'attività. Un profilo per la ricerca di fornitori, un profilo per l'account da cui è autorizzato a pubblicare, un profilo per la dashboard che legge. Se un'esecuzione va storta, il danno è limitato a ciò che quel singolo profilo poteva raggiungere, e puoi buttare via la directory e ricominciare.
Mantenere le esecuzioni confrontabili
Gli agenti sono difficili da debuggare perché due esecuzioni raramente sono la stessa esecuzione. Un profilo che riporta lo stesso dispositivo a ogni avvio, dallo stesso percorso, con lo stato in cui l'hai lasciato, elimina un'intera classe di differenze tra i tentativi. Quando un'esecuzione si comporta in modo diverso, l'ambiente non è più tra i sospettati.
Il limite
Niente di tutto questo è un modo per aggirare i termini di un sito, i suoi limiti di frequenza o la sua policy robots, e non viene venduto come tale. Ciò che offre a un agente è un browser che appartiene all'attività anziché a te.
