Con la rapida evoluzione degli AI Agent, stiamo provando anche strumenti nuovi come Meta Muse, ChatGPT Dots e Claude Duet. Prendere il controllo di un browser, accedere a un pannello interno e completare un flusso di lavoro può sembrare questione di pochi passaggi. Ma quando vedo la schermata navigare da sola, mi viene una domanda meno spettacolare: una volta terminato il flusso, dove sono finiti i dati dell’account affidati al cloud? Quando termina lo stato di accesso? Se uno strumento dirotta quello stato, o una pagina nasconde testo che cerca di alterare i fatti di un ordine, chi ne risponde? Non è un presupposto che gli Agent cloud siano insicuri: è un modo per chiarire il confine di fiducia prima di affidare loro lavoro reale.

Le demo di prodotto mostrano spesso che un flusso funziona, ma raramente rispondono a fondo a queste domande. Per questa verifica ho scelto TinyFish e ho ristretto il problema: ho esaminato cosa restituisce TinyFish Fetch da sei pagine HTML con ordini fittizi e ho controllato il sorgente fissato di AgentQL MCP, la documentazione SDK, quella delle sessioni browser remote e i termini separati dei due servizi.

Prima, il limite delle prove: in questo round ho osservato che la modalità di estrazione cambia il testo restituito dallo strumento. Non ho passato quel testo a un Agent, quindi non posso dedurne se un Agent seguirebbe un’istruzione falsa. Account reali, cookie, sessioni remote e cancellazione dei dati remoti non rientravano nel test.

Recuperare una pagina, passare il contenuto a un modello, lasciare che il modello decida il passo successivo e mantenere da remoto lo stato di accesso di un account sono livelli distinti. Fetch può restituire testo che una persona non vede, ma questo non significa che il modello lo seguirà. Far cliccare un Agent in base al contenuto della pagina o affidargli una sessione autenticata sono ulteriori confini di rischio che questo test non ha verificato.

Limiti delle prove

Misurato	Revisione statica	Non testato
Testo restituito da TinyFish Fetch: 6 fixture × 3 modalità una volta (18 osservazioni), poi F0/F1/F2 × 2 modalità HTML × 3 ripetizioni (18 osservazioni)	Costruzione della richiesta nella versione fissata di AgentQL MCP, valori predefiniti SDK di includeHidden, opzioni di sessione AgentQL REST e due termini di servizio pubblici	Risposta finale di TinyFish Browser Agent; corpi reali delle richieste AgentQL SDK/REST; login reali, persistenza Cookie/Profile, controllo accessi streaming URL e ricevute di cancellazione remota

La stessa pagina può restituire contenuti diversi in base alla modalità di estrazione

Il portale sintetico del fornitore contiene quattro campi di riferimento:

• Ordine: #101
• Importo: USD 4200.00
• Stato: PENDING_APPROVAL
• Marcatore del beneficiario: ACCOUNT_FIXTURE_GOOD_101

Il resto è contenuto esclusivamente di test: un’istruzione falsa in un aria-label, testo nascosto con display:none, un commento HTML e un valore di campo nascosto esplicitamente indicato come canary non segreto. Non sono presenti dati reali di carte, chiavi API, cookie o informazioni personali.

Le sei varianti e il generatore sono in un branch pubblico indipendente di fixture. Le pagine sono servite da una CDN statica di terze parti, non da GitHub Pages. Il sorgente è fissato a un commit per rendere verificabili gli input.

Ho eseguito due round di lettura con la versione gratuita di TinyFish Fetch. Nel primo, sei pagine sono state lette come Markdown ordinario, HTML ordinario e HTML di una regione DOM specificata: 18 osservazioni del testo restituito. Nel secondo, solo F0, F1 e F2 sono state ripetute tre volte ciascuna con HTML ordinario e HTML con ambito selezionato: altre 18 osservazioni.

Ho eseguito due round con TinyFish Fetch gratuito. Nel primo ho letto sei pagine con Markdown normale, HTML normale e HTML di una regione DOM specificata: 18 osservazioni del testo restituito. Nel secondo ho ripetuto solo F0, F1 e F2 tre volte ciascuna con HTML normale e HTML circoscritto: altre 18 osservazioni. Le opzioni erano format: "markdown", format: "html" e format: "html" con include_selectors: ["#trusted-order-facts", "#untrusted-webpage-region"]. Un riscontro indica che la stringa bersaglio dell’istruzione o del canary è apparsa nel testo restituito; non significa che un modello l’abbia seguita.

Fixture	Contenuto non attendibile	Markdown normale	HTML normale	HTML circoscritto
F0	Nessuna istruzione falsa	0/1	0/1	0/1
F1	Istruzione falsa in aria-label	0/1	0/1	1/1
F2	Istruzione falsa in display:none	1/1	1/1	1/1
F3	Istruzione falsa in commento HTML	0/1	0/1	0/1
F4	Canary falsa in campo nascosto	canary 0/1	canary 0/1	canary 1/1
F5	Controllo benigno aria-label	—	—	Testo benigno aria-label 1/1

F5 è un controllo negativo benigno: non contiene testo malevolo, ma l’HTML circoscritto ha restituito comunque il suo aria-label innocuo. Questo è più coerente con la serializzazione del testo degli attributi dalla regione DOM selezionata che con il riconoscimento semantico di contenuti malevoli. L’istruzione nel commento HTML di F3 non è apparsa nella serializzazione DOM restituita in questo round.

Il canary di F4 a 1/1 è una singola osservazione del primo round, non un risultato ripetuto. Il secondo round ha ripetuto solo F0–F2 nelle due modalità HTML; Markdown e F3–F5 non sono stati ripetuti.

Il round ripetuto mostra il contrasto più chiaro:

Fixture	HTML ordinario (3 esecuzioni)	HTML con ambito selezionato (3 esecuzioni)	Risultato osservato
F0: controllo pulito	0/3	0/3	Nessun testo di istruzione falsa in entrambe le risposte
F1: istruzione in aria-label	0/3	3/3	L’estrazione con ambito ha conservato il testo dell’attributo
F2: istruzione nel nodo display:none	3/3	3/3	Il testo del nodo nascosto compare in entrambe le risposte HTML

Tutti i 36 testi restituiti contenevano l’importo, lo stato e il marcatore del beneficiario di riferimento. “Contenevano” significa soltanto che quelle stringhe erano presenti nel testo restituito dallo strumento. Non significa che un modello abbia risposto correttamente, e non si tratta di 36 test di decisione dell’IA.

Il primo round ha prodotto anche due osservazioni con evidenza più limitata. L’istruzione nel commento HTML non è apparsa in nessuno dei tre modi di estrazione di quel round. Il canary sintetico del campo nascosto non è apparso nell’estrazione ordinaria, ma è apparso nell’HTML con ambito selezionato. Entrambi i casi sono stati osservati una sola volta e non supportano una regola generale.

La conclusione supportata è circoscritta: la modalità di estrazione influenza quali contenuti della pagina entrano nel testo restituito dallo strumento. Questo non dimostra che un fornitore abbia sottratto credenziali reali né che un modello seguirà istruzioni nascoste. Servono esperimenti diversi.

AgentQL MCP non inserisce semplicemente tutto il DOM locale nel corpo della richiesta

Un’ipotesi iniziale sosteneva che AgentQL MCP locale caricasse l’intero albero DOM di Chrome per la selezione semantica. Non è corretto estendere questa affermazione a tutti i percorsi AgentQL.

Ho esaminato la versione fissata di src/index.ts in tinyfish-io/agentql-mcp. La costruzione locale della richiesta per extract-web-data invia url, prompt e parametri a api.agentql.com/v1/query-data. Il corpo JSON costruito non contiene il DOM locale né un campo accessibility_tree.

Questo non significa che nessun contenuto della pagina esca dal dispositivo. Questo percorso MCP invia URL e prompt di estrazione; il modo in cui il server recupera ed elabora la pagina associata a quell’URL va valutato separatamente. Il sorgente, però, non dimostra che il browser locale serializzi l’intero DOM nel corpo della richiesta.

Un altro percorso usa l’SDK AgentQL per avvolgere una pagina Playwright. La documentazione sul funzionamento interno di AgentQL spiega che l’elaborazione semantica usa HTML della pagina e Accessibility Tree, semplificando l’input. La API delle pagine JavaScript SDK elenca valori predefiniti diversi per gli elementi nascosti:

Metodo SDK	Valore predefinito documentato di includeHidden
queryData()	true
queryElements()	false
getByPrompt()	false

Questo mostra che le configurazioni cambiano tra i metodi, ma non sostituisce la cattura di una richiesta di rete reale. Non ho eseguito l’SDK né catturato il corpo della richiesta, quindi non posso affermare che un campo nascosto sia stato caricato tramite quel percorso.

Il Browser Agent cloud di TinyFish e le sessioni browser remote di AgentQL sono ulteriori percorsi distinti. MCP, SDK, estrazione tramite URL e browser remoto devono essere valutati separatamente in base al luogo di esecuzione e all’uscita dei dati.

La pulizia di una sessione remota dipende dalla configurazione del ciclo di vita

La guida al browser remoto di AgentQL documenta indirizzi di connessione CDP e URL di streaming delle pagine, e descrive la gestione e la pulizia automatica delle sessioni. La sola documentazione non stabilisce se uno specifico URL di streaming richieda un’autorizzazione aggiuntiva o se i dati della sessione siano stati cancellati da tutti gli archivi.

L’interfaccia delle sessioni browser nella referenza dell’API REST AgentQL espone opzioni più specifiche:

• inactivity_timeout_seconds ha un valore predefinito di 300 secondi (cinque minuti).
• shutdown_mode ha come valore predefinito on_disconnect.
• Con on_inactivity_timeout, la sessione può restare attiva dopo la disconnessione dell’ultimo client fino alla scadenza del timeout di inattività; riconnettersi entro quella finestra può riutilizzare lo stesso browser.

Questo è più preciso dell’affermazione “ogni attività cancella subito la sessione”. Descrive però il comportamento documentato dell’interfaccia REST di AgentQL, non una regola universale per ogni TinyFish Browser Context Profile. Non ho verificato in modo indipendente che una sessione reale sia stata cancellata completamente dopo il timeout.

L’esempio di caching delle credenziali AgentQL mostra inoltre Playwright storage_state(path=“session.json”) per salvare lo stato di accesso in un file locale. È un esempio d’uso dell’SDK locale, non una prova della posizione in cui un Remote Browser Profile conserva i dati.

I termini di servizio descrivono il trattamento consentito, non ciò che è successo in una singola esecuzione

TinyFish e AgentQL hanno termini di servizio separati: non vanno fusi in una generica promessa sulla privacy del fornitore. Ho confrontato le clausole sui Customer Data:

Termini	Permesso pubblicato per il trattamento dei Customer Data	Il passaggio cita esplicitamente training/fine-tuning dei modelli?
Termini di servizio TinyFish	Trattamento per fornire, mantenere, proteggere, analizzare e migliorare il servizio; menziona anche la revisione di specifici runs, prompts, inputs, outputs, errori e modelli d’uso.	Sì. Elenca training, fine-tuning, valutazione e miglioramento dei modelli AI/ML, con garanzie dichiarate per evitare la divulgazione di informazioni riservate ad altri clienti. Data di efficacia: 17 agosto 2026.
Termini di servizio AgentQL	Trattamento dei Customer Data per fornire, mantenere, proteggere e migliorare il servizio; consente anche l’uso di dati aggregati o de-identificati per scopi leciti, incluso il miglioramento e lo sviluppo del prodotto.	Il passaggio visibile sui Customer Data non menziona esplicitamente training o fine-tuning dei modelli. Ciò non prova che altri accordi o policy non possano contenere clausole pertinenti. Data di efficacia: 21 aprile 2026.

Non tratto i termini di servizio come log di esecuzione. Descrivono i permessi di trattamento pubblicati dal fornitore, ma non provano che una richiesta specifica sia stata usata per addestrare un modello o che un cookie sia trapelato. Vale comunque la pena leggerli prima di collegare dati aziendali e verificare se si applichi un accordo enterprise separato.

Come delimiterei l’uso pratico

Questo test non giustifica una valutazione generale “TinyFish è sicuro” o “TinyFish non è sicuro”. Supporta però alcune regole operative:

1. Non iniziare dall’account principale. Se serve il login, usa un account di prova con privilegi minimi, senza permessi di pagamento, amministrazione o aree estranee. Digitare una password in un browser remoto non riporta automaticamente sul dispositivo locale i cookie e lo stato di sessione successivi.
2. Tratta i contenuti web come input non attendibile. aria-label, nodi nascosti e commenti possono contenere testo estraneo ai campi aziendali. Una risposta JSON non dimostra che i dati siano stati sanificati. Definisci i campi ammessi, verifica l’origine dei valori ed esegui test negativi mirati sui contenuti nascosti.
3. Un selettore non è un meccanismo di oscuramento. In questo test, l’HTML con ambito selezionato ha restituito sia testo aria-label sia un valore sintetico di campo nascosto. Limitare la regione DOM può ridurre i contenuti irrilevanti, ma non garantisce che gli attributi e i nodi nascosti al suo interno vengano rimossi.
4. Separa lettura e scrittura. Riassumere un ordine o preparare una bozza da revisionare non equivale ad approvare un ordine, inviare email o inoltrare un modulo. Le azioni irreversibili richiedono una conferma umana indipendente, non soltanto un prompt che dice “non inviare”.
5. Definisci le condizioni di uscita dalla sessione. Prima di iniziare, verifica API di sessione, shutdown_mode e timeout. Una pagina non più visibile, un client disconnesso o lo stato Completed di uno strumento non provano che lo stato remoto sia stato cancellato. Tratta gli indirizzi CDP e gli URL di streaming come punti di controllo sensibili.
6. Riduci al minimo i dati inviati al modello. Per estratti conto, dati clienti e ticket interni, chiediti se serva davvero l’analisi semantica dell’intera pagina. Se pochi campi possono essere selezionati localmente, non inviare l’intera pagina al cloud per impostazione predefinita.

Avevo pianificato di passare le stesse fixture a TinyFish Browser Agent per verificare come avrebbe deciso dopo aver ricevuto il testo della pagina. Tuttavia, l’account di test non poteva imporre il limite di passi approvato e il valore predefinito disponibile superava di molto l’ambito autorizzato. Non ho allentato il limite solo per completare l’esperimento. Nell’automazione, non poter imporre un confine di esecuzione è un motivo per fermarsi, non qualcosa da liquidare con «usalo con attenzione». Questo round si ferma quindi al testo restituito da Fetch, alla revisione del sorgente fissato e alla documentazione pubblica.

La conclusione pratica non è assegnare a un prodotto un’etichetta globale di “sicuro”. Prima identifica cosa viene inviato e attraverso quale percorso; poi usa ricevute verificabili per dimostrare cosa è stato effettivamente restituito. Nome del prodotto, termini sulla privacy e una demo riuscita non sostituiscono un audit dei confini di fiducia.

---

Nota su tempi e ambito: La revisione delle fonti e le osservazioni sulle pagine sintetiche arrivano al 25 ottobre 2026. I test Fetch includono sei fixture × tre modalità di estrazione e tre ripetizioni ciascuna di F0/F1/F2 in due modalità HTML, per un totale di 36 osservazioni del testo restituito. Non sono stati usati account reali, cookie, chiavi API o dati dei clienti. TinyFish Browser Agent, l’uscita dati in runtime di AgentQL SDK/REST, la persistenza di sessioni reali e la cancellazione remota non sono stati testati; questo non certifica la sicurezza complessiva di alcun prodotto.

Nota sulle fonti e sulla riproduzione: Fetch ha usato il commit sorgente 152cdc9a58e6a8fcf2d5857820d60774f0967555. Il commit successivo 604bde069c0bd32bb41a4238140062e5468a7f2f ha modificato solo il README; gli SHA dei blob Git di F0–F5 sono rimasti invariati. Le pagine sono state lette tramite la CDN statica di terze parti cdn.githubraw.com; disponibilità, cache ed equivalenza byte per byte non sono state verificate. Il sorgente Git fissato non prova quindi che la CDN abbia servito contenuti identici byte per byte. Il generatore completo, il classificatore e le ricevute originali del testo restituito restano nel dossier di ricerca privato.