Come progettare un agent firewall per proteggere CRM e dati dagli agenti AI.
Perché gli agenti AI rendono necessario un “firewall” dedicato
Finché l’AI viveva solo in strumenti di content creation o in chatbot scollegati dai sistemi core, la sicurezza era (relativamente) semplice: qualche controllo su privacy, brand voice e poco altro. Con l’arrivo di agenti che leggono e scrivono nel CRM, orchestrano campagne, aprono o chiudono ticket, la domanda cambia: chi controlla cosa questi agenti possono fare sui tuoi dati e sulle tue API? OWASP, nel suo progetto GenAI e nel Top 10 per applicazioni LLM, ha già mappato rischi molto concreti: prompt injection da contenuti esterni, data exfiltration verso canali non autorizzati, over-permissioning di chiavi e tool, output non validato che genera azioni indesiderate OWASP – LLM Top 10. Anthropic, con il Model Context Protocol, propone di affrontare il problema alla radice: separare in modo chiaro il livello "cosa può fare l’agente" (tool e scope) dal modello sottostante, riducendo dipendenza dal singolo vendor e rendendo più semplice auditare chi tocca cosa Anthropic – MCP. Da qui nasce il concetto di agent firewall: uno strato architetturale che sta tra agenti e sistemi core e governa permessi, tool, verifiche e log. Non è (solo) un prodotto, è un modo di pensare agli agenti: non più "utenti super-admin" con accesso diretto a tutto, ma client che parlano con un gateway che decide, per ogni azione, se è consentita, se va modificata o se va bloccata. Meta, in "Practical AI agent security", parla esplicitamente di Rule of Two: per azioni ad alto impatto serve sempre un secondo controllo indipendente – umano o automatizzato – che verifichi cosa sta succedendo Meta AI – Practical AI agent security. NVIDIA, dal canto suo, spinge molto su profiling, osservabilità e benchmark per agenti complessi con NeMo Agent Toolkit, proprio perché senza numeri su p95, Attack Pass Rate e Costo per Outcome è impossibile capire se uno stack agentico è davvero pronto per la produzione NVIDIA – NeMo Agent Toolkit. Nel frattempo, l’AI Act europeo rende chiaro che sistemi AI che toccano dati personali e decisioni di business devono essere governati end-to-end: permessi, log, valutazioni di rischio, monitoraggio post-market Deloitte – EU AI Act overview. In questo contesto, l’agent firewall è il punto dove si incontrano esigenze tecniche (sicurezza, performance) e legali/compliance. In questo articolo vediamo come disegnare un agent firewall per proteggere CRM, marketing automation e sistemi di servizio dagli errori – o dagli abusi – degli agenti AI, usando pattern e standard che stanno emergendo nei player globali, ma adattati alla realtà di PMI e mid-market italiane.
Permessi, MCP, Verifier e logging: mattoni di un agent firewall
Tradurre il concetto di agent firewall in architettura richiede di mettere a terra quattro mattoni: permessi, MCP, Verifier e logging/tracing. Permessi e MCP. L’errore più comune nei POC è dare all’agente chiavi dirette verso CRM, data warehouse o API esterne, magari incollate nel prompt o nel codice. Anthropic propone un’alternativa più sana con il Model Context Protocol (MCP): invece di parlare direttamente con le API, l’agente dialoga con server MCP che espongono tool ben definiti (read_contact_basic, list_open_tickets, propose_email_reply, ecc.) con scope e TTL chiari Anthropic – MCP. In pratica, l’agente non vede mai credenziali raw, ma solo un catalogo di azioni consentite. Verifier indipendente. Meta, nel suo post su "Practical AI agent security", parla di Rule of Two: nessun agente dovrebbe poter eseguire azioni sensibili senza un secondo livello di controllo indipendente Meta AI – Practical AI agent security. Questo secondo livello – il Verifier – può essere un altro modello, un servizio di business logic o una combinazione dei due che riceve le proposte di azione dell’agente e le valuta secondo tre assi: • sintassi: rispetto di JSON Schema, formati, tipi e range di valori; • regole di business: sconti massimi, limiti su modifiche a offerte e contratti, coerenza con pipeline e processi; • provenienza: presenza di citazioni quando si aggiornano dati sulla base di documenti/KB, coerenza con policy AI Act/GDPR. Se qualcosa non torna, il Verifier blocca l’azione o la manda a revisione umana. Logging e tracing. Senza audit trail non c’è firewall che tenga. Standard aperti come OpenTelemetry permettono di rappresentare ogni esecuzione dell’agente come una trace con span per input, retrieval, tool-use e write-back, inclusi tempi, costi e permessi usati OpenTelemetry – overview. NVIDIA, con NeMo Agent Toolkit, mostra come usare questa telemetria per misurare p95 edge→azione, Attack Pass Rate e Costo per Outcome su workflow agentici complessi NVIDIA – NeMo Agent Toolkit. A livello pratico, un agent firewall per CRM e marketing può essere implementato come un gateway: • in ingresso riceve le richieste degli agenti (via Responses API, Interactions API, LangGraph, ecc.); • decide, in base a policy e identità dell’agente, quali server MCP e quali tool rendere disponibili; • applica controlli su ogni chiamata (rate limit, pattern sospetti, check OWASP LLM Top 10 su prompt injection e data exfiltration); • inoltra le azioni approvate verso CRM, data warehouse, piattaforme adv, ticketing; • registra in log strutturati ogni azione, con metadati su chi/cosa/come/quando. È un layer trasversale: non appartiene a un singolo vendor di modello, ma alla tua architettura. Per questo è importante che sia progettato in modo vendor-neutral, usando standard aperti e pattern documentati, così da poter cambiare modello o orchestratore senza riscrivere la sicurezza da zero.
