Due domande separano un’integrazione che passa la revisione da una che viene rimandata: quanti tool servono davvero, e con quale identità l’agente li usa. Sono domande di architettura, non di codice, e hanno entrambe una risposta misurabile.

Capability bloat: un difetto che si misura, non si intuisce

Il primo errore ricorrente è dichiarato senza giri di parole: «More tools don’t always lead to better outcomes. A common error we’ve observed is tools that merely wrap existing software functionality or API endpoints». Un toolset che riproduce uno a uno gli endpoint di un sistema esistente non è un’integrazione, è un proxy — e il conto arriva su due fronti.

Il primo è il contesto: un aggregato multiserver realistico consuma circa 55k token in sole definizioni prima che l’agente faccia alcunché. Il secondo è la qualità della scelta, perché la capacità di selezionare il tool giusto «degrades once you exceed 30–50 available tools», e «too many tools or overlapping tools can also distract agents from pursuing efficient strategies».

La metrica da portare in revisione non è quindi «quanti tool abbiamo», ma «the total runtime of individual tool calls and tasks, the total number of tool calls, the total token consumption, and tool errors».

Rimediare in tre mosse, in quest’ordine

Consolidare. Un tool deve coprire un flusso di lavoro, non una chiamata. Al posto di list_users, list_events e create_event separati, un unico schedule_event che esegue più operazioni sotto il cofano. Il namespacing per servizio e risorsa (asana_search, asana_projects_search) delimita i confini quando i tool restano molti. E le risposte vanno progettate: paginazione, filtri e troncamento con valori predefiniti sensati per qualunque tool che possa restituire molto contesto.

Differire. Il tool search tiene le definizioni fuori dal contesto finché non servono: si marca defer_loading: true sui tool da caricare su richiesta, tenendo non differiti i 3–5 più usati e almeno il tool di ricerca. Le soglie documentate per adottarlo sono dieci o più tool, definizioni oltre i 10k token, o l’aggregazione di più server MCP. Sotto i dieci tool, o quando tutti servono a ogni richiesta, il tool calling standard resta la scelta giusta. Un dettaglio che rompe le build: un tool con defer_loading: true non può portare anche cache_control, e la richiesta viene rifiutata con 400.

Disabilitare. Sui toolset MCP la configurazione supporta sia allowlist (default disattivato, poi abilitazione esplicita) sia denylist, e quest’ultima ha una raccomandazione esplicita per i tool distruttivi quando si costruisce un assistente in sola lettura. La distinzione che conta in revisione: una permission policy governa quando un tool abilitato viene eseguito; per toglierlo del tutto all’agente si disabilita.

Autenticazione: quale identità agisce, e per quanto tempo

Le chiavi API non sono tutte uguali. Quelle personali e di service account sono legate a un’identità e smettono di funzionare quando l’identità esce dall’organizzazione; le chiavi di workspace sono legacy. La formula che chiarisce la differenza funziona bene con gli stakeholder: «a workspace API key is a credential, while a service account has credentials». Un carico condiviso o non presidiato deve avere il proprio service account, non la chiave personale di qualcuno.

La Workload Identity Federation sostituisce il segreto statico con uno scambio: il workload presenta un JWT del proprio identity provider a POST /v1/oauth/token, riceve un token di breve durata e l’SDK lo rinnova da solo. Due punti vanno riportati per onestà, perché stanno nella documentazione stessa:

durata del token = il minore fra (lifetime della regola, default 3600 s)
                   e (2x la vita residua del JWT), mai sotto i 60 s

ANTHROPIC_API_KEY ha precedenza sulle variabili di federazione:
una chiave dimenticata nell'ambiente eclissa la federazione in silenzio

E il limite dichiarato dal vendor: la federazione «is not a complete security story on its own: federated authentication is only as strong as the upstream identity provider that signs the JWT».

Autorizzazione: dove il perimetro si rompe davvero

Le permission policy dei Managed Agents hanno due valori, always_allow e always_ask, con default asimmetrici e motivati: il toolset dell’agente parte da always_allow, i toolset MCP da always_ask, perché così «new tools added to an MCP server do not execute in your application without approval». È il caso classico di perimetro che si allarga senza che nessuno abbia deciso nulla.

Tre falle si ripetono nelle revisioni.

La prima è la più insidiosa: le permission policy non si applicano ai custom tool, che «are executed by your application and controlled by you». Chi crede di avere un controllo gestito, lì non ce l’ha.

La seconda è la delega verso i server MCP di terze parti. Il token OAuth viaggia come authorization_token e la sua acquisizione e il suo rinnovo restano a carico di chi integra; i server elencati «are not owned, operated, or endorsed by Anthropic», che «does not security-audit or manage any MCP server».

La terza è il prompt injection. Il messaggio da riportare a chi finanzia è che la difesa è a strati (addestramento, classificatori, red teaming) e che il residuo esiste: «a 1% attack success rate — while a significant improvement — still represents meaningful risk».

Un’ultima onestà utile in riunione: la documentazione Anthropic non fornisce una mappatura di controlli GDPR, HIPAA o FedRAMP da spuntare. Fornisce controlli concreti — ZDR attivabile per organizzazione, HIPAA readiness con BAA firmato (che non copre Claude Code), residenza dei dati con inference_geo fra us e global — ed è quello che puoi difendere come documentato. Il resto resta responsabilità del tuo programma di conformità.