Agentic Evidence

Preuves de sécurité et observabilité pour l'IA agentique

Agentic Evidence est un projet de référence open source de l'OWASP qui explore la manière de collecter, corréler et évaluer les preuves de sécurité liées à l'exécution de l'IA agentique.

L'observabilité des agents peut montrer qu'un événement a été journalisé. Une enquête de sécurité doit établir ce qui s'est passé, quelles identités et permissions étaient impliquées, quelles entrées ont influencé l'action, quelles décisions de politique ont été prises et quelles conclusions les preuves disponibles étayent réellement.

Agentic Evidence se concentre sur la suffisance des preuves, la reconstruction de l'exécution et l'enquête de sécurité. Il complète les taxonomies et les projets de test de sécurité des agents plutôt que de les dupliquer.

Statut du projet : Le projet est en incubation et l'implémentation initiale est en cours de planification. L'architecture et les commandes décrites dans ce document représentent le MVP envisagé et peuvent évoluer à mesure que les décisions d'implémentation sont finalisées.

Objectifs

• Reconstruire les exécutions d'agents à partir d'événements d'exécution et de sécurité corrélés.
• Relier les actions aux identités, aux entrées, au contenu récupéré, aux appels d'outils, aux décisions d'autorisation et aux résultats.
• Rendre visibles aux enquêteurs la provenance des preuves et les lacunes probatoires.
• Démontrer ce qui peut et ne peut pas être conclu à partir des preuves collectées.
• Fournir des scénarios déterministes et reproductibles que les contributeurs peuvent exécuter localement.
• Publier une taxonomie de preuves extensible et des recommandations pratiques pour les praticiens de la sécurité.

Scénarios initiaux

1. Exécution bénigne : Établir une référence pour un flux de travail d'agent normal.
2. Empoisonnement de la récupération : Démontrer comment le contenu récupéré peut influencer une action de l'agent et si les preuves capturent cette relation.
3. Modification du descripteur d'outil : Évaluer si les preuves permettent d'établir quel descripteur d'outil a été observé ou utilisé et si les modifications sont détectables.

Les scénarios doivent être déterministes et utiliser des données synthétiques. Le projet ne doit pas affirmer qu'une attaque est détectable à moins que l'implémentation et les tests ne soutiennent cette affirmation.

MVP envisagé

La première version est prévue sous la forme d'une application de référence locale comprenant :

• Un exécuteur de scénarios déterministe.
• Un schéma de preuves JSON versionné.
• Une télémétrie d'exécution OpenTelemetry et sa corrélation.
• Un enregistreur de preuves et un stockage local des preuves.
• Une interface d'enquête de sécurité avec chronologies d'exécution, détails des événements et lacunes probatoires.
• Des bundles de preuves exportables.
• Des tests automatisés, une configuration Docker Compose et une documentation pour les contributeurs.

Pile technologique proposée

Composant	Technologie proposée
Application/API	Python avec FastAPI, ou Go lorsque c'est approprié
Format des preuves	JSON versionné avec JSON Schema
Télémétrie	SDK OpenTelemetry et OTLP
Stockage local	SQLite et/ou fixtures JSON
Interface d'enquête	Streamlit ou une interface légère équivalente
Déploiement local	Docker Compose
Tests	pytest et validation de schéma
Intégration continue	GitHub Actions

Il s'agit de choix d'implémentation proposés, et non d'une garantie que chaque composant est disponible. Les décisions d'architecture doivent être documentées dans le dépôt et modifiées uniquement lorsqu'il existe une justification technique claire.

Ce que ce projet n'est pas

La version initiale n'a pas vocation à être :

• Un SIEM de production ou une plateforme d'observabilité généraliste.
• Un runtime d'agent, un fournisseur de modèles ou un moteur de réponse autonome.
• Une garantie qu'un agent est sûr ou que les preuves enregistrées sont véridiques.
• Un remplacement de l'application des autorisations, des contrôles de sécurité à l'exécution ou de la réponse aux incidents.
• Dépendante d'un LLM en direct, de Kubernetes ou d'une infrastructure cloud.

La télémétrie ne constitue pas une preuve en soi. Des événements peuvent être manquants, incorrectement corrélés ou générés par un composant compromis. L'application doit distinguer les enregistrements observés, les assertions des composants, les preuves vérifiées de manière indépendante et les inconnues.

Flux de travail conceptuel

1. Exécuter un scénario déterministe.
2. Générer des événements d'exécution et de sécurité.
3. Corréler les événements avec une exécution d'agent et le contexte de trace.
4. Valider les structures d'événements et enregistrer la provenance.
5. Inspecter les chronologies d'exécution, les décisions d'autorisation, les résultats et les lacunes probatoires.
6. Exporter le bundle de preuves et le comparer aux résultats attendus du scénario.

Documentation du dépôt

• Premiers pas : Configuration locale et workflow de première exécution.
• Ressources : Normes, spécifications et projets de sécurité associés.
• FAQ : Périmètre du projet, confiance dans les preuves, limites de la télémétrie et questions relatives aux contributions.

Principes du projet

• Les preuves avant les affirmations : Les conclusions doivent être étayées par des preuves explicites.
• Rendre l'incertitude visible : Une preuve manquante est un résultat, et non une raison d'inventer une conclusion.
• Reproductibilité : Les scénarios doivent avoir des entrées déterministes et des résultats attendus testables.
• Minimisation des données : Utiliser des entrées synthétiques par défaut et éviter de collecter des secrets ou des données personnelles inutiles.
• Interopérabilité : Privilégier les schémas documentés et les conventions de télémétrie établies lorsque cela est approprié.
• Sécurité dès la conception : Traiter l'ingestion, le stockage, les exports de preuves et l'interface d'investigation comme des composants sensibles en matière de sécurité.

Contribuer

Les contributions sont les bienvenues dans les domaines suivants :

• Conception et validation du schéma de preuves.
• Scénarios de sécurité des agents et cas de test reproductibles.
• Collecte de télémétrie et corrélation d'événements.
• Provenance, intégrité et analyse des preuves.
• Améliorations de l'interface d'investigation.
• Tests automatisés et documentation.

Avant d'entreprendre un travail substantiel :

1. Consultez les issues existantes et la feuille de route du projet.
2. Ouvrez une issue ou commentez-en une décrivant la modification proposée.
3. Gardez les pull requests ciblées et incluez des tests ou des preuves reproductibles le cas échéant.
4. Ne soumettez jamais de secrets, de données clients réelles ou de traces de production sensibles.

Suivez les directives de contribution du dépôt pour connaître les exigences actuelles.

Licence

Le projet est destiné à utiliser la Licence Apache 2.0, sous réserve du fichier de licence publié dans le dépôt. Consultez le fichier LICENSE du dépôt pour connaître les termes faisant foi.

Remerciements

Agentic Evidence est un projet OWASP. Reportez-vous à la liste officielle des projets OWASP et aux métadonnées du dépôt pour connaître la direction actuelle, les coordonnées et le statut du projet. Les références à des outils et services tiers n'impliquent pas l'approbation de l'OWASP.