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 l'attività termina, il contesto viene distrutto. Cookie, stato della sessione e token OAuth non passano da un'attività all'altra, anche quando più membri del workspace lavorano in parallelo.
Altri strumenti condividono una sessione browser di lunga durata. LokBox tratta ogni attività come se fosse l'ultima che quel browser eseguirà.
I token OAuth non entrano mai nella sandbox dell'agente
Quando LokBox esegue una skill Gmail o Notion, il codice della skill gira dentro un isolato V8 tramite isolated-vm 6.1.2 incapsulato in un thread figlio worker_threads.
Il token OAuth Bearer non entra mai in quell'isolato. 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.
Anche se un attaccante trovasse un bug di uscita dalla sandbox in V8, il tuo token non verrebbe esfiltrato. L'esfiltrazione dei token è uno dei pattern di compromissione più comuni negli strumenti IA; LokBox lo chiude per progettazione.
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 mostra nella dashboard una finestra con l'azione richiesta. Completate il passaggio nello stream live oppure inserite un codice, ad esempio un OTP a 6 cifre. Poi l'agente riprende.
LokBox non vi chiede mai di condividere password. Se non rispondete entro 10 minuti, l'attività viene interrotta automaticamente per non generare costi.
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 — tua 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 — tua 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 — tua responsabilità | No — di solito assente |
| Risultati audit pubblici | Sì — 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 in una sola regione. Solo UE-Francoforte. Gli utenti negli Stati Uniti vedono circa 200 ms di latenza base. Il multi-regione è nella roadmap v2.
- 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 Risponderemo entro 48 ore. Prima del lancio non abbiamo ancora un programma bug bounty formale; se la segnalazione è materiale, troveremo una soluzione equa.
Ti chiediamo di non divulgare nulla pubblicamente prima di una nostra conferma e del rilascio di una correzione. Finestra standard di responsible disclosure: 90 giorni.
Ultimo aggiornamento 2026-05-02.