Agentic Evidence

Sicherheitsnachweise und Observability für agentische KI

Agentic Evidence ist ein OWASP-Open-Source-Referenzprojekt, das untersucht, wie Sicherheitsnachweise für die Ausführung agentischer KI gesammelt, korreliert und bewertet werden können.

Agent-Observability kann zeigen, dass ein Ereignis protokolliert wurde. Eine Sicherheitsuntersuchung muss feststellen, was geschehen ist, welche Identitäten und Berechtigungen beteiligt waren, welche Eingaben die Aktion beeinflusst haben, welche Richtlinienentscheidungen getroffen wurden und welche Schlussfolgerungen die verfügbaren Nachweise tatsächlich stützen.

Agentic Evidence konzentriert sich auf Nachweissuffizienz, Rekonstruktion der Ausführung und Sicherheitsuntersuchung. Es ergänzt Taxonomien und Testprojekte zur Agentensicherheit, anstatt sie zu duplizieren.

Projektstatus: Das Projekt befindet sich in der Inkubation, und die erste Implementierung wird geplant. Die in diesem Dokument beschriebene Architektur und die Befehle stellen das beabsichtigte MVP dar und können sich ändern, sobald Implementierungsentscheidungen finalisiert sind.

Ziele

• Agentenausführungen aus korrelierten Ausführungs- und Sicherheitsereignissen rekonstruieren.
• Aktionen mit Identitäten, Eingaben, abgerufenem Inhalt, Tool-Aufrufen, Autorisierungsentscheidungen und Ergebnissen verknüpfen.
• Die Provenienz von Nachweisen und Nachweislücken für Ermittler sichtbar machen.
• Aufzeigen, welche Schlussfolgerungen aus gesammelten Nachweisen gezogen werden können und welche nicht.
• Deterministische, wiederholbare Szenarien bereitstellen, die Mitwirkende lokal ausführen können.
• Eine erweiterbare Nachweis-Taxonomie und praktische Leitlinien für Sicherheitspraktiker veröffentlichen.

Erste Szenarien

1. Harmlose Ausführung: Eine Baseline für einen normalen Agenten-Workflow etablieren.
2. Retrieval-Vergiftung: Aufzeigen, wie abgerufener Inhalt eine Agentenaktion beeinflussen kann und ob die Nachweise diese Beziehung erfassen.
3. Modifikation von Tool-Deskriptoren: Bewerten, ob die Nachweise feststellen können, welcher Tool-Deskriptor beobachtet oder verwendet wurde und ob Modifikationen erkennbar sind.

Szenarien sollten deterministisch sein und synthetische Daten verwenden. Das Projekt darf nicht behaupten, dass ein Angriff erkennbar ist, es sei denn, die Implementierung und die Tests stützen diese Behauptung.

Beabsichtigtes MVP

Die erste Version ist als lokale Referenzanwendung geplant, mit:

• Einem deterministischen Szenario-Runner.
• Einem versionierten JSON-Nachweisschema.
• OpenTelemetry-Ausführungstelemetrie und -Korrelation.
• Einem Nachweis-Recorder und einem lokalen Nachweisspeicher.
• Einer Schnittstelle für Sicherheitsuntersuchungen mit Ausführungszeitleisten, Ereignisdetails und Nachweislücken.
• Exportierbaren Nachweis-Bundles.
• Automatisierten Tests, Docker-Compose-Konfiguration und Dokumentation für Mitwirkende.

Vorgeschlagener Technologie-Stack

Komponente	Vorgeschlagene Technologie
Anwendung/API	Python mit FastAPI oder Go, wo angemessen
Nachweisformat	Versioniertes JSON mit JSON Schema
Telemetrie	OpenTelemetry SDK und OTLP
Lokaler Speicher	SQLite und/oder JSON-Fixtures
Untersuchungs-UI	Streamlit oder eine gleichwertige leichtgewichtige UI
Lokale Bereitstellung	Docker Compose
Tests	pytest und Schema-Validierung
Kontinuierliche Integration	GitHub Actions

Dies sind vorgeschlagene Implementierungsentscheidungen, keine Garantie, dass jede Komponente verfügbar ist. Architekturentscheidungen sollten im Repository dokumentiert und nur bei klarer technischer Begründung geändert werden.

Was dieses Projekt nicht ist

Die erste Version ist nicht als Folgendes gedacht:

• Ein produktives SIEM oder eine universelle Observability-Plattform.
• Eine Agenten-Laufzeitumgebung, ein Modellanbieter oder eine autonome Reaktions-Engine.
• Eine Garantie, dass ein Agent sicher ist oder dass aufgezeichnete Nachweise wahrheitsgemäß sind.
• Ein Ersatz für die Durchsetzung von Autorisierung, Laufzeitsicherheitskontrollen oder Incident Response.
• Abhängig von einem Live-LLM, Kubernetes oder Cloud-Infrastruktur.

Telemetrie ist für sich genommen kein Beweis. Ereignisse können fehlen, falsch korreliert oder von einer kompromittierten Komponente erzeugt worden sein. Die Anwendung muss zwischen beobachteten Aufzeichnungen, Behauptungen von Komponenten, unabhängig verifizierten Nachweisen und Unbekanntem unterscheiden.

Konzeptioneller Workflow

1. Führe ein deterministisches Szenario aus.
2. Generiere Ausführungs- und Sicherheitsereignisse.
3. Korreliere Ereignisse mit einem Agentenlauf und einem Trace-Kontext.
4. Validiere Ereignisstrukturen und zeichne die Provenienz auf.
5. Untersuche Ausführungszeitlinien, Autorisierungsentscheidungen, Ergebnisse und Evidenzlücken.
6. Exportiere das Evidenzbündel und vergleiche es mit den erwarteten Szenariobefunden.

Repository-Dokumentation

• Erste Schritte: Lokale Einrichtung und Workflow für den ersten Lauf.
• Ressourcen: Standards, Spezifikationen und verwandte Sicherheitsprojekte.
• FAQ: Projektumfang, Evidenzvertrauen, Telemetrie-Einschränkungen und Fragen zur Mitwirkung.

Projektprinzipien

• Evidenz vor Behauptungen: Befunde müssen durch explizite Evidenz gestützt werden.
• Unsicherheit sichtbar machen: Fehlende Evidenz ist ein Ergebnis, kein Grund, eine Schlussfolgerung zu erfinden.
• Reproduzierbarkeit: Szenarien müssen deterministische Eingaben und testbare erwartete Ergebnisse haben.
• Minimale Daten: Standardmäßig synthetische Eingaben verwenden und das Sammeln von Geheimnissen oder unnötigen personenbezogenen Daten vermeiden.
• Interoperabilität: Wo angemessen, dokumentierte Schemata und etablierte Telemetriekonventionen bevorzugen.
• Security by Design: Evidenzaufnahme, -speicherung, -exporte und die Untersuchungsoberfläche als sicherheitskritische Komponenten behandeln.

Mitwirken

Beiträge sind in den folgenden Bereichen willkommen:

• Design und Validierung von Evidenz-Schemata.
• Agenten-Sicherheitsszenarien und reproduzierbare Testfälle.
• Telemetrieerfassung und Ereigniskorrelation.
• Evidenzprovenienz, -integrität und -analyse.
• Verbesserungen der Untersuchungsoberfläche.
• Automatisierte Tests und Dokumentation.

Bevor du mit umfangreicher Arbeit beginnst:

1. Prüfe bestehende Issues und die Projekt-Roadmap.
2. Eröffne ein Issue oder kommentiere eines, das die vorgeschlagene Änderung beschreibt.
3. Halte Pull Requests fokussiert und füge, wo zutreffend, Tests oder reproduzierbare Evidenz bei.
4. Reiche niemals Geheimnisse, echte Kundendaten oder sensible Produktions-Traces ein.

Befolge die Beitragsrichtlinien des Repositories für die aktuellen Anforderungen.

Lizenz

Das Projekt soll die Apache License 2.0 verwenden, vorbehaltlich der im Repository veröffentlichten Lizenzdatei. Die maßgeblichen Bedingungen findest du in der Datei LICENSE des Repositories.

Danksagungen

Agentic Evidence ist ein OWASP-Projekt. Die offizielle OWASP-Projektliste und die Repository-Metadaten enthalten aktuelle Informationen zu Leitung, Kontaktdaten und Projektstatus. Verweise auf Drittanbieter-Tools und -Dienste bedeuten keine Billigung durch OWASP.