Un guardrail non è un system prompt più severo. È un insieme di controlli che valgono anche quando il modello sbaglia e quando un contenuto di terze parti prova a redirigere l’agente. Il rilascio sicuro si costruisce su tre cose: una policy dei contenuti scritta prima del codice, strati che degradano bene, credenziali che non concedono più di quanto serva.

La policy dei contenuti è un documento, non un prompt

Il metodo della guida alla moderazione parte dagli esempi, non dalle categorie: raccogli contenuti che devono essere segnalati e contenuti che non devono esserlo, casi limite inclusi, e solo dopo ne ricavi la lista di categorie. Le definizioni contano più dei nomi: «Specialized Advice» non dice nulla finché non scrivi che comprende i consigli su investimenti, azioni e pianificazione finanziaria.

Due scelte di progetto pagano subito. La prima: livelli di rischio da 0 a 3 invece di un booleano, così blocchi automaticamente solo l’alto rischio e mandi a revisione umana chi accumula segnalazioni di rischio medio. La seconda: il modello giusto è quello piccolo. Su un miliardo di post al mese da circa 100 caratteri l’uno, la guida stima 36.100 dollari al mese con Claude Haiku 4.5 contro 180.500 con i modelli Opus; e quando la moderazione non deve essere in tempo reale, il batching abbassa ancora il costo per messaggio. Poi misura il sistema come un classificatore, con precision e recall.

Un limite da conoscere prima di scrivere la policy: i modelli hanno comportamenti di sicurezza incorporati, quindi Claude può rifiutare contenuti che la tua policy permetterebbe. La Usage Policy di Anthropic è un vincolo a monte del tuo documento.

Strati che si sommano, non che si sostituiscono

Anthropic descrive il proprio contenimento su tre livelli: l’ambiente — «We constrain where and how an agent can act with process sandboxes, VMs, filesystem boundaries, and egress controls» — il modello, con system prompt, classificatori e modifiche all’addestramento, e il contenuto esterno, con i permessi dei tool e l’audit dei server MCP. La distinzione utile per chi progetta è che il livello del modello è probabilistico e quello dell’ambiente no. Un classificatore riduce la probabilità; una sandbox limita il danno. Non contare il primo come se fosse il secondo.

Nei Claude Managed Agents lo strato di autorizzazione è esplicito. Ogni toolset ha una permission policy: always_allow esegue senza conferma, always_ask sospende la sessione finché non arriva la tua risposta. I default sono asimmetrici e la ragione è istruttiva: l’agent toolset è always_allow, i toolset MCP sono always_ask, perché un tool nuovo aggiunto dal server non deve poter eseguire senza approvazione. Puoi tenere il default largo e stringere un solo tool.

{
  "type": "agent_toolset_20260401",
  "default_config": { "permission_policy": { "type": "always_allow" } },
  "configs": [
    { "name": "bash", "permission_policy": { "type": "always_ask" } }
  ]
}

Due precisazioni che evitano errori. Mettere un tool in always_ask non è disabilitarlo: se non deve esistere, va tolto dal toolset. E le permission policy non governano i custom tool, che esegue la tua applicazione e che quindi deve autorizzare la tua applicazione. In Claude Code la logica è la stessa vista dall’altro lato: le modalità di permesso fissano la linea di base e sopra ci vanno le regole; le regole di deny bloccano in ogni modalità, bypassPermissions compreso, dove invece le regole di allow non hanno alcun effetto.

Identità: nessuna chiave che sopravvive a chi la possiede

Le chiavi legate a un’identità — personali o di service account — sono preferibili alle workspace key, ormai legacy, perché ogni richiesta agisce come quell’identità e la chiave smette di funzionare quando quell’identità esce dall’organizzazione. Il modo tipico di sbagliare è condividere una chiave personale per un carico automatico: agisce come una persona sola e si rompe il giorno in cui quella persona cambia lavoro. Per CI e servizi in produzione si crea un service account.

La scadenza si sceglie alla creazione e non si può cambiare dopo: limita la vita di una credenziale trapelata, ma non sostituisce l’igiene dei segreti. Il passo successivo è la Workload Identity Federation, che scambia il token dell’identity provider con uno a vita breve e toglie del tutto la stringa statica dall’ambiente. Con un caveat dichiarato: non garantisce da sola la sicurezza end-to-end, perché la catena di fiducia vale quanto la configurazione del tuo identity provider, e un segreto a lunga vita un passo più a monte la vanifica.

Minimo privilegio al confine dell’esecuzione

Nei Managed Agents una credenziale di tipo environment_variable finisce nel sandbox come segnaposto opaco e viene sostituita con il valore reale solo all’egress: «The agent never sees the secret value.» Attorno a questo si stringono due viti indipendenti: networking.allowed_hosts decide per quali host il segreto viene sostituito, injection_location decide in quale parte della richiesta, header o body. Il body è la superficie più larga, perché il payload è spesso assemblato con il contenuto su cui l’agente sta lavorando; la configurazione più stretta è quindi il solo header.

Restano due avvertenze. I vault sono scoped al workspace: qualunque API key con accesso a quel workspace può referenziarli, e si revoca solo cancellando il vault o la credenziale. E la regola che riassume il modulo: «The agent can do anything the key allows, so a key with broader permissions than necessary increases the blast radius if the agent behaves unexpectedly.» La domanda giusta al rilascio non è se il modello si comporterà bene, ma che cosa può toccare la chiave che gli hai dato quando non lo fa.