Cosa possono davvero raggiungere i tuoi agenti AI: mappare gli accessi degli agenti su infrastrutture reali

Un agente AI è, dal punto di vista operativo, un processo che detiene credenziali. Qualcuno gli assegna un service account, una API key o un ruolo IAM perché possa svolgere il suo lavoro, e da quel momento può raggiungere tutto ciò che quelle credenziali raggiungono. La descrizione del compito diceva “esporta i dati di fatturazione ogni notte”. La credenziale diceva “leggi e scrivi il database di produzione, e l’object store, e la coda”. Nessuno ha riconciliato le due cose. Mesi dopo, nessuno nel team sa rispondere a una domanda che dovrebbe essere banale: cosa può davvero raggiungere questo agente, e cosa tocca effettivamente?

Quel divario non è un’ipotesi astratta. Ricerche indipendenti del settore (CSA/Token) hanno rilevato che circa l’82% delle organizzazioni ha agenti AI in esecuzione di cui non è a conoscenza, mentre solo il 21% circa ne mantiene un inventario in tempo reale. Non puoi governare ciò che non puoi vedere, e oggi la maggior parte degli ambienti non riesce a vedere affatto i propri agenti — figurarsi gli edge che collegano ciascun agente alle risorse che può raggiungere.

Tre domande diverse, abitualmente confuse

Il motivo per cui “cosa può raggiungere questo agente” è una domanda difficile è che fa collassare tre domande distinte in una sola. Tenerle separate è tutto il gioco.

• Detenuto — le credenziali che l’agente possiede. Un token, una chiave, un binding di ruolo. È un fatto di identità: di quali porte l’agente ha le chiavi.
• Permesso — ciò che quelle credenziali sono autorizzate a fare, secondo la policy: i grant IAM, i ruoli del database, le regole di rete. È un fatto di policy, ed è quasi sempre più ampio di quanto chiunque ricordi, perché i grant si accumulano e nessuno li revoca.
• Osservato — ciò che l’agente è stato effettivamente visto fare: quali risorse ha raggiunto, e se ogni accesso è stato una lettura o una scrittura. È un fatto comportamentale e, finché non lo raccogli, semplicemente non esiste da nessuna parte.

La maggior parte degli strumenti di sicurezza si ferma al permesso. Legge il tuo IAM e ti dice che l’agente potrebbe scrivere sul bucket degli export di fatturazione. È necessario ma insufficiente, perché “potrebbe” è un insieme di migliaia di capacità latenti, e un essere umano non può triagiare migliaia di “forse”. Ciò che cambia la conversazione è mettere l’osservato accanto al permesso e guardare la differenza.

La mappa degli accessi

Una mappa degli accessi è il grafo di quegli edge: per ogni agente individuato, un edge verso ciascuna risorsa che può raggiungere, annotato con ciò che è stato effettivamente osservato lungo di esso. L’unità che conta è l’edge, e l’annotazione più importante sull’edge è la distinzione read/write.

R (read) significa che l’agente ha recuperato dati senza modificarli: un SELECT, un GET, una lettura di file. RW (read/write) significa che ha mutato lo stato: un INSERT/UPDATE/DELETE, un PUT su object storage, una migrazione di schema. Il blast radius dei due non è paragonabile. Un edge di lettura su una tabella sensibile è una questione di esposizione. Un edge di scrittura — specialmente se non voluto — è una questione di integrità e di incidente. Trattarli come lo stesso “accesso” è il modo in cui i team si lasciano sfuggire il risultato che contava.

Ecco come si presenta la riga di un singolo agente una volta costruita la mappa:

Guarda la prima riga. Il job di export doveva leggere da prod-postgres e scrivere il risultato su s3://billing-exports. Leggere dalla sorgente, scrivere sulla destinazione. Ma la credenziale che gli è stata consegnata concede RW sul database, e il collector lo ha osservato mentre scriveva su prod-postgres — una mutazione sul sistema di registrazione di produzione che nessuno ha rivisto, voluto o sa attualmente spiegare. La colonna del permesso, silenziosamente, diceva da sempre che era consentito. È il seme di un incidente, in piena vista, e senza la colonna dell’osservato non c’è nulla da segnalare.

Permesso meno osservato uguale drift

L’output caratteristico è il diff. Il drift rispetto al least-privilege è ciò che ottieni sottraendo una colonna dall’altra, e taglia in entrambe le direzioni:

• Permesso ma mai osservato — l’agente può raggiungere internal-metrics-api ma in tutta la finestra di osservazione non l’ha mai fatto. È scope morto: un grant che puoi proporre di revocare in sicurezza, riducendo la superficie di attacco senza toccare il comportamento.
• Osservato oltre quanto autorizzato — la scrittura su prod-postgres che nessuno ha approvato. Questo è il risultato ad alto segnale: un’azione che accade e che, se qualcuno fosse stato interpellato al momento del provisioning, non avrebbe approvato.

La seconda categoria è il rischio in primo piano, e la versione onesta del prodotto non lo inventa mai. Ogni edge osservato porta con sé un livello di confidenza — attribuito quando l’azione è legata a una specifica identità di agente con segnale corroborante, approssimato quando le prove sono più deboli. Mostri la differenza invece di spacciare una congettura per certezza. Un risultato che non puoi sostenere è peggio di nessun risultato.

Individuato passivamente, attribuito per agente

Due scelte progettuali rendono tutto questo affidabile invece che l’ennesima dashboard.

Primo, l’individuazione è passiva. Il collector osserva — log, tracce OpenTelemetry, stream di audit del database come pgAudit di PostgreSQL ed eBPF a livello kernel come verità assoluta — e non si trova nel data path dell’agente. Non c’è alcun proxy obbligatorio. Se il collector si guasta, l’agente continua a funzionare; l’observability si degrada, la produzione no. Per un sistema il cui intero scopo è governare infrastruttura critica, quell’asimmetria è il design: basso svantaggio, alto segnale.

Secondo, ogni azione è attribuita a una specifica identità di agente, non a un service account condiviso. È la differenza tra un registro di audit che dice “il ruolo di export ha scritto su prod-postgres alle 02:14” e uno che dice quale agente lo ha fatto, sotto la titolarità di chi, rispetto a quale scope previsto. L’identità per agente è la precondizione perché il least-privilege significhi qualcosa — senza di essa, un’azione può essere vista ma mai ricondotta a un responsabile.

Gli edge e i fatti read/write sono l’unica cosa memorizzata. La mappa registra relazioni — agente verso risorsa, R o RW — non payload, non le righe lette, non segreti. Gli input che potrebbero contenere segreti o PII vengono redatti e sottoposti a secret-scanning prima che venga scritto qualsiasi cosa. Il grafo è sensibile proprio perché è una mappa degli accessi, perciò è costruito per contenere il minimo che rende possibile la governance e nulla di più.

I segnali provenienti dall’ecosistema stesso dell’agente aiutano ma non sono attendibili di per sé. Un MCP server può dichiarare che un tool è in sola lettura tramite annotazioni come readOnlyHint; secondo la specifica MCP quegli hint sono non attendibili e devono essere corroborati, mai creduti ciecamente. La vista a livello kernel è ciò che coglie un tool che si è dichiarato in sola lettura ma ha comunque scritto.

Una volta che la mappa esiste, il passo successivo è l’enforcement: vincolare il job di export alla sola lettura sul database, negare la scrittura e generare un alert invece di limitarsi a fare logging — policy applicata al momento dell’accesso, non ricostruita dopo l’incidente.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # intended scope: read source only
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # intended scope: write destination
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

La mappa ti dice la policy che avresti dovuto scrivere, perché ti mostra l’unico accesso di cui l’agente aveva davvero bisogno e la dozzina che non ha mai usato. È la differenza tra tirare a indovinare il least-privilege e derivarlo dalla verità assoluta.

Se questa è la domanda a cui il tuo ambiente non sa rispondere oggi — cosa può raggiungere ciascun agente, e cosa tocca effettivamente — è esattamente a questo che serve la mappa degli accessi. La panoramica del prodotto illustra l’individuazione e il diff permesso-versus-osservato; l’architettura spiega come la raccolta passiva, l’identità per agente e il registro di audit si combinano senza mai trovarsi nel data path dei tuoi agenti.