Presentazione di Beacon: Telemetria degli endpoint per agenti AI

La prima generazione di sicurezza AI si concentrava sul gateway del modello. La prossima si sposterà sull'endpoint, dove gli agenti svolgono effettivamente il lavoro.

I gateway avevano senso quando i sistemi AI rispondevano principalmente a domande. Un team di sicurezza poteva inserire un punto di controllo tra l'utente e il modello, ispezionare prompt e output, applicare DLP, mediare l'accesso al modello e registrare lo scambio.

Gli agenti costringono quell'architettura a evolversi. Il problema di sicurezza non è più solo ciò che un modello dice o vede. È ciò che un agente può fare: usare gli strumenti dell'utente, ereditare le sue autorizzazioni e modificare lo stato all'interno di ambienti sensibili.

L'esempio più chiaro è la macchina dello sviluppatore. Agenti di codifica come Claude Code, Codex e Cursor operano insieme a codice sorgente, terminali, gestori di pacchetti, CLI cloud, credenziali locali e sistemi vicini alla produzione. Una singola richiesta in linguaggio naturale può trasformarsi in letture di file, comandi shell, modifiche alle dipendenze, azioni autenticate e modifiche al codice.

Lo stesso modello si sta ora espandendo oltre gli sviluppatori verso i knowledge worker. Gli agenti connessi al desktop stanno iniziando a operare attraverso app SaaS, strumenti locali e sistemi interni. Spazi di lavoro per agenti come Claude Cowork e OpenClaw indicano la prossima fase dell'AI aziendale: il laptop dell'utente diventa il runtime per il lavoro delegato attraverso le applicazioni aziendali.

La dura realtà oggi è che i team di sicurezza potrebbero vedere il raggio d'esplosione solo dopo che un agente ha eseguito comandi, modificato file, installato dipendenze o esfiltrato dati. Le modalità di fallimento sono già gravi: esecuzione remota di codice tramite la configurazione del progetto Claude Code, esposizione di codice privato tramite injection di prompt in Copilot Chat e furto di credenziali tramite pacchetti npm dannosi che trasformano gli agenti di codifica locali in percorsi di attacco.

Questo è il divario di visibilità dell'endpoint che Beacon è progettato per colmare.

Beacon è il layer di telemetria endpoint open-source di @asymptotelabs per agenti AI. È il nostro primo passo per rendere l'attività degli agenti locali osservabile, comprensibile e, infine, governabile in tutta l'azienda.

Cosa Significa per i Team di Sicurezza

Per i team di sicurezza, questo è importante perché lo stack esistente non è stato progettato per spiegare il lavoro delegato. Gateway, EDR e telemetria nativa degli agenti rimangono tutti importanti, ma ognuno vede solo una parte di ciò che un agente sta facendo. Per governare gli agenti in sicurezza, i team devono vedere come un agente passa dall'intenzione all'azione sull'endpoint.

Tre lacune emergono:

1. I log degli endpoint mostrano gli effetti, non i flussi di lavoro. Possono catturare comandi, modifiche ai file e attività dei processi, ma raramente collegano questi eventi alla richiesta dell'agente, alla decisione dello strumento, al percorso di approvazione o al diff finale.
2. La telemetria degli agenti necessita di un layer comune. Agenti di codifica AI come Claude Code, Cursor, Codex e Claude Cowork espongono tutti segnali di telemetria diversi. I team di sicurezza hanno bisogno di un record unificato a livello di endpoint tra di loro.
3. La visibilità viene prima del controllo. I team non possono applicare configurazioni, limitare azioni sensibili, governare l'accesso MCP o proteggere i segreti finché non sanno quali agenti sono in esecuzione, quali autorizzazioni hanno e quali azioni stanno compiendo.

I Log degli Endpoint Non Catturano i Flussi di Lavoro degli Agenti

La telemetria tradizionale degli endpoint è necessaria, ma insufficiente per comprendere il comportamento degli agenti.

Può mostrare che i comandi sono stati eseguiti, i file modificati, i processi avviati o le connessioni aperte. Ciò che di solito non può mostrare è il flusso di lavoro dietro l'evento: cosa è stato chiesto all'agente di fare, cosa ha deciso di fare e se l'azione aveva senso per il compito.

La stessa azione dell'agente può essere sicura o rischiosa a seconda del compito che la circonda. Per esempio:

• Un comando kubectl può essere appropriato durante un incidente infrastrutturale, ma inappropriato per un agente di codifica a cui è stato chiesto di aggiornare un test unitario.
• Una lettura di .env può essere prevista durante il debug locale, ma sospetta durante una modifica alla documentazione.
• Una modifica a Terraform può essere normale in un repository di infrastruttura, ma pericolosa quando introdotta come effetto collaterale di un aggiornamento delle dipendenze.

In ogni caso, l'evento grezzo non è sufficiente. Il significato di sicurezza dipende dal flusso di lavoro che lo circonda: il prompt, il piano, il contesto a cui si è acceduto, gli strumenti invocati, i file toccati, le credenziali utilizzate e le approvazioni concesse.

Considera un agente di codifica a cui è stato chiesto di fare una modifica di test mirata: La richiesta dell'utente potrebbe essere qualcosa come: "Aggiorna il test unitario per la logica di ripetizione della fatturazione."

La telemetria tradizionale potrebbe mostrare:

• billing_test.go modificato
• .env letto
• terraform/main.tf modificato
• kubectl apply eseguito

Questi eventi sono utili, ma sono scollegati dal flusso di lavoro dell'agente. Il log mostra che un test è stato modificato, un file segreto è stato letto, Terraform è stato modificato e un comando di deployment è stato eseguito. Non mostra se quelle azioni facevano parte della richiesta dell'utente, quale decisione dello strumento le ha prodotte o se l'utente ha approvato i passaggi sensibili.

Un record consapevole dell'agente collega gli stessi eventi al flusso di lavoro:

• Prompt: "Aggiorna il test unitario per la logica di ripetizione della fatturazione."
• Decisione dello strumento: read_file(billing_test.go), read_file(.env), edit_file(terraform/main.tf), run_command(kubectl apply)
• Approvazione: Utente ha approvato kubectl apply
• Diff: billing_test.go: +3 righe, terraform/main.tf: -2 righe

Senza quella traccia, i team di sicurezza si ritrovano a ricostruire l'intenzione da artefatti di basso livello dopo i fatti. Possono vedere gli effetti dell'attività dell'agente, ma non se il comportamento dell'agente era appropriato per il lavoro che gli era stato chiesto di fare.

Beacon: Un Layer di Telemetria Endpoint per Agenti AI

La maggior parte dei team di sicurezza e IT può rispondere a quali modelli sono approvati o quali gateway sono distribuiti. Una volta che gli agenti vengono eseguiti localmente, le domande di sicurezza si avvicinano all'endpoint:

• Inventario degli agenti: Quali strumenti agente sono installati? Quali utenti e dispositivi li stanno eseguendo?
• Contesto di runtime: In quali repository e spazi di lavoro operano gli agenti? Quali strumenti, credenziali e autorizzazioni locali possono ereditare?
• Attività dell'agente: Quali file stanno leggendo o modificando gli agenti? Quali comandi, approvazioni e diff stanno generando?
• Telemetria e audit: Quale telemetria viene raccolta e dove viene inviata? I team di sicurezza possono collegare la richiesta originale dell'utente alle azioni intraprese?

La telemetria nativa degli agenti aiuta, ma è frammentata. Claude Code e Codex possono esportare OpenTelemetry. Cursor espone hook per sessioni, prompt, uso di strumenti, esecuzione di comandi, approvazioni, attività simili a MCP e modifiche ai file. Claude Cowork può esportare telemetria tramite un endpoint OTLP configurato dall'amministratore.

Ciò di cui i team di sicurezza hanno bisogno è un record del flusso di lavoro che li attraversi: cosa è stato chiesto all'agente di fare, quale contesto aveva, quali strumenti ha invocato, quali approvazioni erano richieste e cosa è cambiato sull'endpoint.

Beacon colma quel divario configurando OpenTelemetry dove supportato, raccogliendo segnali locali dove disponibili e mappando l'attività frammentata degli agenti in un formato comune di eventi endpoint.

Come mostrato nella Figura 1, Beacon collega quattro layer:

1. Runtime degli agenti: Claude Code, Codex, Cursor, Claude Cowork, OpenClaw e modelli locali generano prompt, piani, chiamate a strumenti, approvazioni, diff e stato di runtime.
2. Attività endpoint: Questi agenti interagiscono con la macchina: file, terminali, gestori di pacchetti, server MCP, CLI cloud, repository, credenziali e configurazione locale.
3. Normalizzazione Beacon: Beacon trasforma segnali frammentati di OpenTelemetry, basati su hook e endpoint in un flusso di eventi JSON comune, così i team di sicurezza possono seguire la catena dalla richiesta dell'agente all'azione locale.
4. Destinazioni di sicurezza: Beacon scrive oggi JSONL compatibile con Wazuh. Lo stesso flusso di eventi normalizzato può estendersi nei SIEM, data lake, piattaforme di osservabilità, pipeline di rilevamento e flussi di lavoro endpoint che le aziende già utilizzano.

Con Beacon, prompt, chiamate a strumenti, comandi, modifiche ai file, approvazioni, interazioni MCP e modifiche al runtime diventano parte di un unico record a livello di endpoint: una catena più chiara dalla richiesta dell'utente all'azione locale, attraverso agenti e strumenti.

Visibilità Prima, Controllo Dopo

Gli agenti stanno diventando un nuovo layer di esecuzione all'interno dell'azienda.

Leggono file, chiamano strumenti, usano credenziali, modificano sistemi e agiscono con l'autorità delle persone che delegano loro il lavoro. Questa attività non può essere compresa o governata solo dal gateway del modello.

L'endpoint è dove contesto, autorità e azione dell'agente si uniscono. È dove i prompt diventano comandi, gli strumenti ereditano autorizzazioni, le credenziali vengono utilizzate e le modifiche vengono apportate.

Questo rende la telemetria endpoint il fondamento per la sicurezza degli agenti.

Beacon rende l'attività degli agenti locali osservabile attraverso gli strumenti che le aziende stanno già adottando. Fornisce ai team di sicurezza un record comune di cosa è stato chiesto agli agenti di fare, cosa hanno toccato, cosa hanno modificato e se le azioni sensibili sono state approvate.

Questo layer deve essere affidabile. Beacon è open source e con licenza MIT perché opera vicino al flusso di lavoro degli sviluppatori, al codice sorgente, alle credenziali e ai sistemi vicini alla produzione. Gli sviluppatori dovrebbero poter ispezionare ciò che viene raccolto. I team di sicurezza dovrebbero poter verificare la telemetria. I team IT dovrebbero capire esattamente cosa stanno distribuendo.

L'attività degli agenti dovrebbe essere osservabile prima di essere governabile.

Beacon è il nostro primo passo per rendere questo vero.