Il problema dell’automazione.
Un ciclo di computer use diventa pericoloso quando il suggerimento del modello e l’autorità del programma vengono trattati come la stessa cosa. Un prompt può descrivere un obiettivo; non dovrebbe concedere in silenzio accesso a filesystem, shell o desktop.
Il progetto doveva esporre soltanto le capacità supportate dal runtime corrente, applicare un livello di permessi scelto dall’operatore e richiedere un’osservazione dopo ogni azione.
I confini applicati dal runtime.
L’agente è progettato attorno a limiti espliciti:
- Il livello observe predefinito espone controlli del runtime e accesso in sola lettura ai file nei percorsi approvati.
- Gli strumenti desktop, browser, file e sistema compaiono soltanto quando runtime e livello di permesso li consentono entrambi.
- Non esiste una shell general-purpose. Il launcher limitato invoca direttamente un solo eseguibile in allowlist e rifiuta pipeline, sostituzioni e concatenazione dei comandi.
- Un’attività non può risultare completata finché il ciclo di orchestrazione non dispone di un’osservazione verificata successiva all’azione.
Separare ragionamento e autorità.
Il modello dovrebbe scegliere quale azione dichiarata richiedere. Non dovrebbe decidere se l’azione è consentita, quanto può durare o quanto output entra nel prompt successivo.
Ho spostato queste decisioni in un registro degli strumenti protetto da policy e in un livello di orchestrazione limitato. Gli strumenti sconosciuti falliscono, tentativi e durata dell’attività sono limitati e gli eventi di audit vengono redatti prima di raggiungere il disco.
Un ciclo osserva–decidi–autorizza–verifica.
La percezione acquisisce uno screenshot o l’albero di accessibilità. Gemini restituisce una singola chiamata di funzione dichiarata. Il livello di policy verifica supporto del runtime, livello e allowlist prima di eseguire uno strumento. L’osservazione risultante diventa l’evidenza del turno successivo.
Le scelte che riducono la superficie di attacco.
Le capacità sono configurazione e codice, non buone maniere suggerite nel prompt.
Costruire il registro a runtime
Gli strumenti non supportati vengono omessi, invece di essere pubblicizzati per poi fallire dopo che il modello li ha scelti.
Il modello vede meno strumenti, preferibile al fingere che ogni ambiente disponga degli stessi poteri.
Usare controlli indipendenti
Gli strumenti di sistema richiedono il livello system e un flag separato di conferma delle azioni pericolose, con allowlist per percorsi, applicazioni ed eseguibili.
La configurazione richiede più tempo, ma un unico interruttore generico non può esporre tutte le azioni ad alto impatto.
Autenticare la console locale
Il piano di controllo web scambia un token operatore con una sessione HttpOnly di breve durata e applica limiti a origine, frequenza, upload e concorrenza.
Resta un piano di controllo locale a processo singolo, non un servizio pubblico multi-tenant.
Verifica del runtime e del rilascio.
I test portabili vengono eseguiti su Linux, mentre la CI Windows verifica la copertura legata al desktop. Analisi statica, audit delle dipendenze, validazione del sito e smoke test Docker coprono i percorsi di distribuzione circostanti.
I rilasci dei container vengono promossi soltanto tramite digest dopo i controlli di vulnerabilità, SBOM e provenienza. Il controllo nativo del desktop resta volutamente fuori da Docker; il sito Pages pubblico è una presentazione, non una console operatore.
Cosa dimostra l’alpha.
L’agente può usare strumenti desktop e browser dichiarati attraverso un ciclo la cui autorità è visibile e limitata al di fuori della risposta del modello.
Non afferma un’autonomia generale. Qualità dell’interfaccia, focus della finestra, latenza di terze parti e interfacce basate su Canvas continuano a limitarne l’affidabilità; il progetto va quindi usato in ambienti usa e getta o attentamente confinati.
Registro delle evidenze.
Le affermazioni sull’alpha sono legate a limiti verificati, non ad aneddoti su attività autonome:
- Verifica
- 155 dichiarazioni di unit test e una soglia di copertura del repository del 70%.
- Limiti dell’attività
- 50 turni, 900 secondi per attività, 120 secondi per richiesta al modello e 45 secondi per azione come valori predefiniti.
- Piano di controllo
- Token operatore di almeno 24 caratteri, al massimo otto WebSocket e due stream nativi come valori predefiniti.
- Limite
- Gemini è una dipendenza cloud; Docker non può controllare il desktop host e l’affidabilità nativa dipende dall’accessibilità dell’interfaccia e dal focus.