Venerdì 6 novembre 2026
L’edizione di oggi
Millebit
AI · Software · QA
Il segnale, non il rumore.

Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo

Approfondimento

Confinamento agenti AI: rilevare, isolare, limitare le capacità

Testo scritto con l’intelligenza artificiale a partire da 4 fonti citate, senza revisione umana prima della pubblicazione.

Per confinare agenti AI serve una strategia di difesa in profondità che combini rilevamento del comportamento dei modelli, micro-isolamento delle esecuzioni e controllo granulare delle credenziali.

Illustrazione generata con l’intelligenza artificiale

Molti modelli gratuiti su OpenRouter dichiarano il supporto ai tool, poi rispondono in sola prosa. model-radar li prova uno per uno e segna chi chiama davvero un tool. Misura e agisce. Tesi: per confinare agenti AI serve difesa in profondità. Rilevamento del comportamento, micro-isolamento dell’esecuzione, controllo granulare delle credenziali. I tre livelli si sommano1.

1. Misurare il comportamento reale dei modelli

L’autore ha pubblicato due comandi, model-radar e model-canary. Il primo elenca i modelli gratuiti su OpenRouter e chiede a ogni nuovo ingresso di eseguire una chiamata a tool. Il secondo controlla il modello a pagamento usato dagli agent e il saldo crediti. Se qualcosa si rompe, passa a un’opzione più economica o locale. Sono strumenti operativi. Misurano e agiscono1.

L’installazione richiede Python 3.11 o superiore. Non serve pip. Si clona il repository e si copia il file di configurazione: git clone https://github.com/casareanderson/model-radar.git && cd model-radar, poi cp config.example.toml config.toml. L’help è in ./bin/model-radar --help. L’autore indica un setup di circa dieci minuti. Tiene anche una guida che gira ogni settimana su una macchina Ubuntu fresca1.

La guida invita a provare senza credenziali. Si esegue ./bin/model-radar --dry-run e ./bin/model-canary --dry-run. model-radar produce una baseline vuota. model-canary stampa no OPENROUTER_API_KEY -- nothing to check ed esce con codice 1. Quel codice conta. Se il canary non può controllare nulla, un timer deve accorgersene1.

Questa telemetria sostiene le scelte successive. Scopri quali modelli chiamano davvero tool e quali no. Tieni sotto controllo il modello a pagamento e il credito. Automatizza i fallback quando serve. Un agente affidabile nasce da misure ripetibili.

2. Limitare l’impatto di runtime con micro-isolamento

Docker descrive le Sandboxes come microVM con kernel, filesystem, rete e Docker Engine privati. Servono per eseguire agenti di coding autonomi. Risolvono un problema diverso dai container4.

La differenza è nel confine. Un container è un processo isolato che condivide il kernel dell’host. Usa namespace e cgroups. Parte in fretta e consuma poco. Nelle Sandboxes l’agente ottiene una macchina intera. Ha un kernel Linux proprio, uno stack di rete separato e un Docker Engine privato. Può fare sudo dentro la sandbox senza raggiungere il Docker daemon dell’host, né il filesystem dell’host fuori dal suo workspace, né le altre Sandboxes sulla stessa macchina. Una sandbox può eseguire container al suo interno, ma il limite resta quello della microVM4.

Serve agli agenti perché agiscono come sviluppatori. Clonano repository, installano pacchetti, avviano database, costruiscono immagini, lanciano applicazioni con Compose, rileggono i log, cambiano codice, ripetono per ore. Ogni passo dipende dal precedente. I container nascono per processi con dipendenze note e per essere ricreati dall’immagine. Le Sandboxes contengono meglio questa attività aperta e iterativa, senza impattare l’host4.

3. Ridurre la superficie di rete e la gestione delle porte

DockTail registra automaticamente i container Docker nel Tailnet di Tailscale usando semplici label. Non serve mappare porte sull’host. Ogni servizio ottiene un nome stabile via MagicDNS e indirizzi IPv4 e IPv6 virtuali. Un esempio: jellyfin.tailnet-name.ts.net. Tailscale collega i nodi con WireGuard in una rete privata e usa un servizio cloud per distribuire chiavi e regole di accesso2.

La configurazione passa da label con prefisso docktail.*. Nel caso base bastano docktail.service.enable, docktail.service.name e docktail.service.port. DockTail inoltra il traffico verso gli IP dei container nel network Docker e aggiorna la rotta se l’IP cambia. Supporta HTTP, HTTPS, TCP e TCP con terminazione TLS. Sui servizi TCP può attivare il PROXY protocol, così il backend vede l’IP del client nel Tailnet. Per HTTPS, i certificati arrivano da Let’s Encrypt. Verso il container si può parlare in HTTP2.

Questo taglia due nodi operativi. Non si espongono porte sull’host. Non si mantengono elenchi di host e porte. Serve solo che un host con client Tailscale possa contattare il servizio. Rispetto a strade già note, DockTail evita un nodo per container e l’allungamento della lista dispositivi in console2.

4. Controllo granulare delle capacità e isolamento delle credenziali

Edera propone Object Capability Bounded Authority. È un modello di sicurezza per isolare i workload degli agenti AI e i server Model Context Protocol dalle credenziali sensibili. Impone capability granulari a livello di hypervisor. Evita che ambienti non deterministici ricevano token o chiavi che un attaccante può estrarre con prompt injection o tramite la supply chain3.

L’architettura separa l’autorità operativa dalle credenziali. Non inietta segreti in variabili d’ambiente o file. Il piano dell’hypervisor applica capability strettamente definite per ogni workload3.

I componenti runtime integrati nell’Agent Runtime fanno il lavoro. capcurl instrada le chiamate API autorizzate attraverso un broker isolato e nasconde all’agente i materiali di autenticazione. capsudo esegue comandi con ambito ristretto, senza concedere privilegi permanenti o accessi root. L’identità del workload viene verificata in modo crittografico con integrazioni SPIFFE e SPIRE, che stabiliscono connessioni mutual TLS e identità di servizio senza segreti statici di lunga durata. Il modello si estende ai server MCP3.

5. Difesa in profondità: come combinare i livelli

Il primo livello è il rilevamento. model-radar indica quali modelli su OpenRouter chiamano davvero tool. model-canary verifica il modello a pagamento e il credito e segnala condizioni operative attraverso l’exit code1.

Il secondo livello è il contenimento. Le Sandboxes riducono il danno potenziale di azioni invasive. L’agente non raggiunge il Docker daemon dell’host, né altri workload sulla stessa macchina4.

Il terzo livello è la rete minima necessaria. DockTail evita porte esposte e gestioni manuali. Assegna nomi stabili, aggiorna inoltri quando l’IP cambia e usa certificati da Let’s Encrypt. L’accesso resta nel Tailnet collegato con WireGuard2.

Il quarto livello è il principio del minor privilegio sulle credenziali. Object Capability Bounded Authority impedisce all’agente di vedere o estrarre token sensibili. capcurl e capsudo applicano capability puntuali, mentre SPIFFE e SPIRE danno identità senza segreti statici di lunga durata3.

Insieme formano un percorso pratico. Misura il comportamento dei modelli, isola l’esecuzione, restringi la rete, separa le credenziali dall’autorità operativa1,4,2,3.

La differenza passa dai dettagli operativi: un exit code che segnala l’assenza di controlli, un ambiente di esecuzione che non tocca l’host, un servizio raggiungibile nel Tailnet senza porte aperte, una chiamata API instradata da un broker che nasconde i materiali di autenticazione1,4,2,3.

Fonti

  1. Due comandi su GitHub scoprono quali modelli OpenRouter fanno chiamate a tool millebit.com
  2. DockTail integra container Docker nella rete Tailscale senza aprire porte millebit.com
  3. Edera isola le credenziali dagli agenti AI con Object Capability Bounded Authority millebit.com
  4. Docker Sandboxes, microVM isolate per agenti di coding millebit.com
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici

Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:

  • Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
  • Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
  • Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
  • Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,0/10.

I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.

Come funziona Millebit, nel dettaglio →

Hai trovato un errore? Segnalacelo
Tipo di segnalazione

Leggiamo ogni segnalazione. Le correzioni fatte sono elencate in Correzioni. L’email, se la lasci, serve solo a risponderti.