Architettura di sicurezza
La sicurezza non è stata aggiunta dopo.
Quando si costruisce uno strumento che usa browser per conto degli utenti, ci sono due opzioni: presumere che nulla andrà storto, oppure presumere che qualcosa possa sempre andare storto. Abbiamo scelto la seconda. Ogni scelta architetturale in Lokbox — sandbox, confini di isolamento, limiti di costo e conferme umane — esiste perché abbiamo analizzato cosa succederebbe senza.
Perché esiste questa pagina
Ad aprile 2026, ricercatori di sicurezza hanno divulgato 14 CVE su circa 200.000 server MCP — lo standard degli strumenti per agenti IA usato da Cursor, Windsurf, Claude Code, Gemini CLI e GitHub Copilot. 9 marketplace MCP su 11 potevano essere manipolati per distribuire pacchetti malevoli. La risposta di Anthropic è stata “expected behavior” — il modello di minaccia è fondamentale nel modo in cui gli agenti chiamano gli strumenti.
Lokbox è costruito diversamente. Questa pagina documenta le scelte architetturali concrete che ci rendono più sicuri dello strumento medio per agenti IA — e dove stiamo ancora migliorando.
Isolamento del browser per ogni attività
Ogni attività avvia un nuovo Chromium BrowserContext tramite Playwright. Quando un'attività termina, il relativo contesto viene distrutto. Questo design mira a limitare il riporto di stato di sessione e token tra le attività.
Altri strumenti condividono una sessione browser di lunga durata. Lokbox tratta ogni attività come se fosse l'ultima che quel browser eseguirà.
Trattamento dei token OAuth fuori dalla sandbox dell'agente
Quando Lokbox elabora una richiesta verso un servizio connesso, il codice del servizio gira dentro un isolato V8 tramite isolated-vm 6.1.2 incapsulato in un thread figlio worker_threads.
Il token OAuth Bearer viene mantenuto fuori da quell'isolato dal confine di trattamento dei token. Resta nel processo host. Quando la skill chiama ctx.fetch_with_oauth(...), l'host inserisce Authorization: Bearer ... al confine di rete. La skill vede solo il corpo della risposta.
Il trattamento dei token è separato in modo che il confine mira a mantenere il token fuori dalla sandbox. Questo riduce un importante percorso di esposizione, ma non garantisce l'assenza di ogni compromissione.
L'IA si ferma per CAPTCHA e 2FA
CAPTCHA, codici a due fattori e schermate di login non vengono aggirati dall'IA. L'agente chiama uno strumento integrato pause_for_human che spiega l'azione richiesta nella dashboard. Effettua personalmente il login o la 2FA nel browser in tempo reale; l'IA non vede ciò che inserisce.
Le credenziali e la 2FA restano presso di Lei. Le inserisce personalmente nel browser in tempo reale; l'IA non vede ciò che inserisce.
Tre livelli di limite dei costi
- Limite per attività: limite rigido di $1 per attività. Evita loop fuori controllo.
- Limite giornaliero per workspace: limita quanto un workspace può consumare in 24 ore. Evita che un solo utente consumi tutta la capacità.
- Limite giornaliero globale: tetto rigido sui costi totali della flotta per giorno UTC. Limita il peggior caso in un incidente di sicurezza.
Confronto
Confronto diretto con le alternative più comuni. Ultimo aggiornamento 2026-05-02.
| Lokbox | Browserbase | Computer Use direct | Most MCP servers | |
|---|---|---|---|---|
| Isolamento browser per attività | Sì — contesto nuovo | Parziale — sessioni condivise | No — Sua responsabilità | No — processo condiviso |
| Token OAuth isolati dal codice agente | Sì — iniezione a livello rete | No — direttamente nel codice | No — direttamente nel codice | Parziale — dipende dal server |
| Protezione SSRF nella navigazione agente | Sì — blocco IP privati + controllo DNS | Parziale — alcuni controlli | No — Sua responsabilità | Parziale — dipende dal server |
| Pausa per CAPTCHA / 2FA | Sì — integrata | No — errore o aggiramento | No — manuale | No — di solito assente |
| Limite rigido per attività | Sì — $1 predefinito | Parziale — fatturazione per sessione | No — Sua responsabilità | No — di solito assente |
| Documentazione dell'architettura di sicurezza | Descritta in questa pagina | Parziale — solo SOC 2 | N/A | No — auto-dichiarati |
Cosa non dichiariamo ancora
Vogliamo essere precisi anche sui limiti. Stato al 2026-05-02:
- Nessun penetration test esterno ancora. Previsto per il mese 2-3 dopo il lancio. I risultati saranno pubblicati su questa pagina.
- Infrastruttura svizzera. L'hosting web e applicativo opera da Zurigo, in Svizzera; una copia dei dati di produzione rimane a Francoforte (DE) fino al 22.08.2026. L'elaborazione Claude utilizza il distinto profilo geografico di inferenza UE di AWS Bedrock descritto nella nostra Informativa sulla privacy.
- Nessun SOC 2 / ISO 27001. Non lo faremo in modo speculativo. Se un cliente specifico lo richiede, avvieremo il processo; fino ad allora investiamo in miglioramenti architetturali reali.
- L'isolamento tenant del database oggi è lato applicazione. I confini del workspace sono applicati nel codice. Le policy Supabase Row-Level Security sono previste in v2 come difesa in profondità lato database.
- L'IA nel browser è per natura vulnerabile a prompt injection. Quando l'IA legge una pagina web, contenuto malevolo può teoricamente istruirla. Mitighiamo con limiti di costo, pausa per azioni sensibili e log di audit per analisi forense.
Avete trovato una vulnerabilità?
Inviate i dettagli a security@lokbox.ch Non disponiamo ancora di un programma bug bounty formale; includete un contesto sufficiente per permetterci di valutare la segnalazione.
Vi chiediamo di coordinare qualsiasi divulgazione pubblica con noi dopo la disponibilità di una correzione.
Ultimo aggiornamento 2026-05-02.