Agentic Evidence

Evidenza di sicurezza e osservabilità per l'AI agentica

Agentic Evidence è un progetto di riferimento open-source OWASP che esplora come raccogliere, correlare e valutare l'evidenza di sicurezza per l'esecuzione dell'AI agentica.

L'osservabilità degli agenti può dimostrare che un evento è stato registrato. Un'indagine di sicurezza deve stabilire cosa è accaduto, quali identità e permessi sono stati coinvolti, quali input hanno influenzato l'azione, quali decisioni di policy sono state prese e quali conclusioni l'evidenza disponibile supporta effettivamente.

Agentic Evidence si concentra su sufficienza dell'evidenza, ricostruzione dell'esecuzione e indagine di sicurezza. Integra le tassonomie e i progetti di testing per la sicurezza degli agenti anziché duplicarli.

Stato del progetto: Il progetto è in incubazione e l'implementazione iniziale è in fase di pianificazione. L'architettura e i comandi descritti in questo documento rappresentano l'MVP previsto e potrebbero cambiare man mano che le decisioni di implementazione vengono finalizzate.

Obiettivi

• Ricostruire le esecuzioni degli agenti a partire da eventi di esecuzione e di sicurezza correlati.
• Collegare le azioni a identità, input, contenuti recuperati, chiamate agli strumenti, decisioni di autorizzazione ed esiti.
• Rendere visibili agli investigatori la provenienza dell'evidenza e le lacune nell'evidenza.
• Dimostrare cosa si può e cosa non si può concludere dall'evidenza raccolta.
• Fornire scenari deterministici e ripetibili che i contributori possono eseguire localmente.
• Pubblicare una tassonomia dell'evidenza estensibile e una guida pratica per i professionisti della sicurezza.

Scenari iniziali

1. Esecuzione benigna: Stabilire una baseline per un normale flusso di lavoro dell'agente.
2. Avvelenamento del recupero: Dimostrare come il contenuto recuperato può influenzare un'azione dell'agente e se l'evidenza cattura tale relazione.
3. Modifica del descrittore dello strumento: Valutare se l'evidenza può stabilire quale descrittore dello strumento è stato osservato o utilizzato e se le modifiche sono rilevabili.

Gli scenari dovrebbero essere deterministici e utilizzare dati sintetici. Il progetto non deve affermare che un attacco è rilevabile a meno che l'implementazione e i test non supportino tale affermazione.

MVP previsto

La prima release è pianificata come un'applicazione di riferimento locale che include:

• Un esecutore di scenari deterministico.
• Uno schema di evidenza JSON con versionamento.
• Telemetria di esecuzione OpenTelemetry e correlazione.
• Un registratore di evidenza e un archivio locale dell'evidenza.
• Un'interfaccia di indagine di sicurezza con timeline di esecuzione, dettagli degli eventi e lacune nell'evidenza.
• Bundle di evidenza esportabili.
• Test automatizzati, configurazione Docker Compose e documentazione per i contributori.

Stack tecnologico proposto

Componente	Tecnologia proposta
Applicazione/API	Python con FastAPI, o Go dove appropriato
Formato dell'evidenza	JSON con versionamento e JSON Schema
Telemetria	OpenTelemetry SDK e OTLP
Archiviazione locale	SQLite e/o fixture JSON
UI di indagine	Streamlit o una UI leggera equivalente
Deployment locale	Docker Compose
Testing	pytest e validazione dello schema
Integrazione continua	GitHub Actions

Queste sono scelte di implementazione proposte, non una garanzia che ogni componente sia disponibile. Le decisioni architetturali dovrebbero essere documentate nel repository e modificate solo in presenza di una chiara giustificazione tecnica.

Cosa non è questo progetto

La release iniziale non è pensata per essere:

• Un SIEM di produzione o una piattaforma di osservabilità general-purpose.
• Un runtime per agenti, un fornitore di modelli o un motore di risposta autonoma.
• Una garanzia che un agente sia sicuro o che l'evidenza registrata sia veritiera.
• Un sostituto dell'applicazione delle autorizzazioni, dei controlli di sicurezza runtime o della risposta agli incidenti.
• Dipendente da un LLM live, da Kubernetes o da infrastrutture cloud.

La telemetria non è di per sé una prova. Gli eventi possono essere mancanti, correlati in modo errato o generati da un componente compromesso. L'applicazione deve distinguere tra record osservati, asserzioni dei componenti, evidenza verificata in modo indipendente e incognite.

Flusso di lavoro concettuale

1. Eseguire uno scenario deterministico.
2. Generare eventi di esecuzione e di sicurezza.
3. Correlare gli eventi con un'esecuzione dell'agente e il contesto di traccia.
4. Convalidare le strutture degli eventi e registrare la provenienza.
5. Ispezionare le timeline di esecuzione, le decisioni di autorizzazione, gli esiti e le lacune nelle evidenze.
6. Esportare il bundle di evidenze e confrontarlo con i risultati attesi dello scenario.

Documentazione del repository

• Per iniziare: Configurazione locale e flusso di lavoro per la prima esecuzione.
• Risorse: Standard, specifiche e progetti di sicurezza correlati.
• FAQ: Ambito del progetto, affidabilità delle evidenze, limitazioni della telemetria e domande sui contributi.

Principi del progetto

• Evidenze prima delle affermazioni: I risultati devono essere supportati da evidenze esplicite.
• Rendere visibile l'incertezza: L'assenza di evidenze è un risultato, non un motivo per inventare una conclusione.
• Ripetibilità: Gli scenari devono avere input deterministici e risultati attesi verificabili.
• Minimo dei dati: Utilizzare input sintetici per impostazione predefinita ed evitare la raccolta di segreti o dati personali non necessari.
• Interoperabilità: Preferire schemi documentati e convenzioni di telemetria consolidate, ove appropriato.
• Sicurezza fin dalla progettazione: Trattare l'ingestione, l'archiviazione, le esportazioni delle evidenze e l'interfaccia di indagine come componenti sensibili alla sicurezza.

Contribuire

I contributi sono benvenuti nelle seguenti aree:

• Progettazione e convalida dello schema delle evidenze.
• Scenari di sicurezza degli agenti e casi di test riproducibili.
• Raccolta della telemetria e correlazione degli eventi.
• Provenienza, integrità e analisi delle evidenze.
• Miglioramenti dell'interfaccia di indagine.
• Test automatizzati e documentazione.

Prima di iniziare un lavoro sostanziale:

1. Rivedere le issue esistenti e la roadmap del progetto.
2. Aprire o commentare una issue che descriva la modifica proposta.
3. Mantenere le pull request focalizzate e includere test o evidenze riproducibili, ove applicabile.
4. Non inviare mai segreti, dati reali dei clienti o tracce di produzione sensibili.

Seguire le linee guida per i contributi del repository per i requisiti attuali.

Licenza

Il progetto intende utilizzare la Apache License 2.0, in base al file di licenza pubblicato nel repository. Consultare il file LICENSE del repository per i termini vincolanti.

Riconoscimenti

Agentic Evidence è un progetto OWASP. Fare riferimento all'elenco ufficiale dei progetti OWASP e ai metadati del repository per la leadership attuale, i dettagli di contatto e lo stato del progetto. I riferimenti a strumenti e servizi di terze parti non implicano l'approvazione da parte di OWASP.