La maggior parte dei team scopre lo stesso fatto scomodo nello stesso ordine. Prima si rende conto che gli agenti AI sono già in esecuzione in tutto il proprio parco, chiamano modelli, aprono server MCP, accedono a database e object store. Poi prova a inventariarli e scopre che non esiste alcun elenco. Una ricerca di settore indipendente (CSA/Token, n=418) quantifica il divario: circa l’82% delle organizzazioni ha agenti in esecuzione di cui non è a conoscenza, e solo circa il 21% mantiene un inventario in tempo reale. Prima di poter governare qualunque cosa, devi vederla. La domanda è come ottenere questa visibilità senza peggiorare le cose.
Ci sono due risposte oneste, e si collocano agli estremi opposti di uno spettro di rischio.
Due modi per vedere un agente
Il primo è un proxy inline. Instrada il traffico dell’agente attraverso un componente che controlli e, poiché ogni richiesta e risposta vi transita, puoi vedere, modellare e bloccare in tempo reale. È una scelta di progettazione legittima e potente. È così che oggi vengono applicati gran parte del filtraggio dell’egress, l’intermediazione dei segreti e le policy a livello di richiesta.
Il secondo è la discovery passiva. Anziché metterti dentro il flusso, lo osservi dal lato: l’OpenTelemetry che un agente già emette, i registri di audit nativi dei sistemi che tocca (PostgreSQL pgAudit, log di audit cloud come AWS CloudTrail, l’audit di Kubernetes) e i segnali a livello di kernel tramite eBPF come backstop di verità di base. Non termini mai la connessione. Osservi ciò che è accaduto e ricostruisci chi ha toccato cosa.
La differenza che conta non è quanto ciascun approccio può vedere nel caso migliore. È cosa succede quando è il livello di visibilità stesso a guastarsi.
Il vero asse è il raggio d’impatto
Un proxy inline è, per costruzione, nel percorso dei dati. Questo garantisce il controllo in tempo reale, e ti costa una modalità di guasto condivisa. Se il proxy è lento, i tuoi agenti sono lenti. Se crolla, il comportamento sicuro di default è di solito fallire chiuso, il che significa che i tuoi agenti si fermano, oppure fallire aperto, il che significa che il tuo controllo sparisce silenziosamente nel momento peggiore. In entrambi i casi il componente di visibilità condivide ora un raggio d’impatto con la produzione. Aggiunge inoltre un hop di latenza a ogni chiamata e una superficie di deployment che qualcuno deve gestire, scalare e patchare sul percorso critico.
La discovery passiva ha il profilo opposto. Il collector è fuori banda e read-first: legge telemetria, registri di audit ed eventi del kernel; non inoltra né riscrive il traffico dell’agente. Se degrada o muore, nulla cambia nel percorso della richiesta. Perdi visibilità aggiornata finché non si ripristina, non throughput, non disponibilità. È questo che in pratica significa read-first, l’asimmetria a basso rischio: non c’è alcun rischio al rialzo per la produzione da parte di ciò che ha come unico compito quello di osservare.
| Proxy inline | Discovery passiva | |
|---|---|---|
| Posizione | Nel percorso dei dati | Fuori banda, accanto |
| Blocco in tempo reale | Nativo | Richiede l’enforcement al punto di accesso |
| Latenza aggiunta | Sì, a ogni chiamata | Nessuna |
| In caso di guasto | Gli agenti si bloccano o il controllo svanisce | La visibilità diventa obsoleta; agenti non interessati |
| Copertura dei percorsi silenziosi | Alta (termina il flusso) | Dipende dai segnali emessi + backstop eBPF |
Ecco perché la posizione del prodotto è nessun proxy obbligatorio anziché «i proxy sono inutili». Ci sono percorsi in cui un componente inline è la scelta giusta, e si compongono. Ma la discovery, la parte a cui non si dovrebbe mai permettere di mettere fuori uso la cosa che sta inventariando, è il compito sbagliato da imbullonare al percorso critico.
Il compromesso, dichiarato onestamente
La discovery passiva ha una debolezza autentica, e fingere il contrario sarebbe il tipo di uomo di paglia che fa screditare silenziosamente una progettazione. Un proxy che termina un flusso ne vede ogni byte. Un collector passivo vede solo ciò che l’agente, il suo runtime o la risorsa hanno scelto di emettere. Su un percorso pienamente non cooperativo, uno che registra poco e non emette telemetria utile, la discovery a livello applicativo si assottiglia. Puoi dedurre che qualcosa è accaduto, ma l’attribuzione diventa più difficile.
Due elementi mantengono tutto questo onesto anziché fatale.
Il primo è il backstop eBPF a livello di kernel. I log applicativi possono essere incompleti, ritardati o, in un caso avversario, soppressi deliberatamente. Al kernel non si può chiedere educatamente di dimenticare una syscall. Un agente che apre un socket verso un database o scrive un file lascia una traccia al confine delle syscall a prescindere da ciò che il suo logging ha scelto di registrare. Questo rende eBPF la verità di base anti-evasione: quando i segnali di livello superiore non concordano o tacciono, la vista del kernel è il livello di conferma. È anche il motivo per cui le annotazioni degli strumenti MCP come readOnlyHint e destructiveHint, per quanto utili come indizi, sono trattate come non attendibili secondo la specifica MCP. Uno strumento che dichiara di essere a sola lettura e viene osservato mentre scrive è esattamente la discrepanza che vale la pena far emergere, e la cogli solo se confermi la dichiarazione rispetto a ciò che è effettivamente accaduto.
Il secondo sono i livelli di confidenza onesti. Non ogni osservazione merita lo stesso peso, quindi la mappa degli accessi non finge che sia così. Un arco supportato da un segnale del kernel e da una voce di audit corrispondente è contrassegnato come attribuito; un arco dedotto da telemetria parziale è contrassegnato come approssimato. Il prodotto non riconverte mai un’ipotesi in un fatto. Un revisore dovrebbe poter vedere, a colpo d’occhio, quanto fidarsi di ogni riga.
Dall’osservazione al diff che conta
La discovery è solo l’input. L’output è il confronto tra PERMITTED, ciò che la policy consente, e OBSERVED, ciò che il collector ha effettivamente visto. Quel diff è il drift dal least-privilege, e il caso principale è una scrittura osservata che la policy non ha mai concesso e che nessuno ha revisionato.
Poche righe da un feed di accessi lo rendono concreto. Le letture sono di routine; la scrittura segnalata è la notizia:
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged attributed
support-rag READ internal-wiki-mcp allowed approximateUn job di export che legge un database di produzione è normale. Lo stesso job che vi scrive, quando la policy ha concesso solo la lettura, è il tipo di arco che non dovrebbe mai passare senza revisione. Poiché la scrittura è confermata al confine del kernel, è contrassegnata come attributed, non come una semplice cautela.
Vedere il drift è metà del lavoro; chiuderlo è l’altra metà. L’enforcement spetta al punto di accesso, espresso come policy-as-code, così la regola è revisionabile e la violazione viene gestita, non semplicemente registrata:
policy "data-export-readonly" {
agent = "data-export-job"
resource = "prod-postgres"
allow = ["read"]
deny = ["write"]
on_violation = "block + alert"
}La discovery passiva trova la scrittura non permessa; la policy riporta l’agente al least-privilege e blocca la successiva. Visibilità e controllo restano preoccupazioni separate, ed è esattamente per questo che il livello di discovery può permettersi di essere read-first.
In sintesi
La visibilità sugli agenti AI è una decisione di rischio prima di essere una decisione di funzionalità. Un proxy inline ti dà il controllo in tempo reale al costo di condividere un raggio d’impatto con la produzione. La discovery passiva rinuncia a parte della portata sui percorsi silenziosi in cambio del non poter mai mettere fuori uso la produzione, poi recupera gran parte di quella portata con un backstop eBPF di verità di base e livelli di confidenza che restano onesti su ciò che è stato effettivamente visto. Per un inventario, il livello il cui intero compito è osservare, quell’asimmetria è il default giusto.
Se vuoi il quadro completo di come collector, mappa degli accessi e registro di audit si incastrano insieme, la panoramica dell’architettura lo illustra dall’inizio alla fine.