AgentFootprint zeigt den blinden Fleck von KI-Agenten
19. Juli 2026
Ein neues arXiv-Paper misst, wie viele Daten LLM-Agenten nach Aufgaben zurücklassen. Der Befund ist praktisch: Gleiche Trefferquote kann 15,7-mal mehr gespeicherte Bytes bedeuten.
Worum es geht
Ein neues arXiv-Paper mit dem Titel The Hidden Footprint: Making Storage a First-Class Metric for LLM Agent Evaluation schlägt vor, LLM-Agenten nicht nur nach Trefferquote, Kosten und Zuverlässigkeit zu bewerten. Die Forschenden messen auch, was nach einem Agentenlauf auf dem Datenträger liegen bleibt: Logs, Kontext-Snapshots, Checkpoints, Debug-Spuren und gespeicherte Gesprächsverläufe.
Die erste Version wurde am 13. Juli 2026 eingereicht, die für diesen Lauf relevante Version 2 erschien am 16. Juli 2026. Das Thema ist nicht akademische Kleinteiligkeit. Wenn Agenten künftig Code ändern, Tickets bearbeiten, Browser bedienen oder Kundendaten auswerten, werden ihre Datenreste zu Kosten-, Datenschutz- und Sicherheitsmaterial.
Was AgentFootprint tatsächlich macht
AgentFootprint ist ein Benchmark für den Speicher-Fußabdruck nach einem Agentenlauf. Er betrachtet nicht nur, ob eine Aufgabe gelöst wurde, sondern wie viel persistente Information dabei entsteht und wie diese Information zusammengesetzt ist. Dazu zählen Gesamtmenge, Kanäle, Duplikate, Wachstum über Wiederholungen, Komprimierbarkeit und die Frage, ob sich der Gesprächsverlauf aus den gespeicherten Daten rekonstruieren lässt.
Wichtig ist die Messmethode. Das Paper argumentiert, dass naive Byte-Zählung Wiederholungen stark unterschätzen kann, weil Datenbanken, JSON-Escaping und Speicherformate Duplikate verdecken. Deshalb trennt der Benchmark logisches Agentenmaterial von Verstärkung durch die Persistenzschicht.
Warum das wichtig ist
Die Zahlen sind konkret. Beim Replay derselben Trajektorie durch sieben persistierende Frameworks fand das Paper eine Spanne von 6,7x. Unter identischen Modellen, Tools und Aufgaben unterschieden sich Konfigurationen mit 100 Prozent Genauigkeit um 15,7x bei den gespeicherten Bytes. Exportierte Trajektorien aus 108 normalisierten SWE-bench Verified-Einreichungen lagen pro Instanz über drei Größenordnungen auseinander.
Das trifft Entwicklerteams unmittelbar. Ein Agent, der jeden Tool-Aufruf, jede Beobachtung und jede Zwischenantwort dauerhaft speichert, ist leichter zu auditieren und zu debuggen. Gleichzeitig wächst die Angriffsfläche: mehr sensible Daten, mehr Retention, mehr mögliche Rekonstruktion von Gesprächsverläufen. Speicher ist damit nicht nur Infrastrukturkostenstelle, sondern Teil der Sicherheitsarchitektur.
Für Unternehmen wird daraus eine einfache Prüfpflicht: Ein Agent ist nicht automatisch besser, weil er dieselbe Aufgabe löst. Entscheidend ist auch, wie viel verwertbares Material er danach hinterlässt und ob dieses Material wirklich gebraucht wird.
Einfach erklärt
Es ist wie beim Umzug. Zwei Teams bringen dieselbe Wohnung leer und schaffen alle Kartons ans Ziel. Das eine Team lässt danach drei beschriftete Ordner mit Inventar zurück, das andere kopiert jeden Zettel zehnmal und vergisst Kisten im Hausflur. Beide haben den Auftrag erledigt, aber nur eines arbeitet kontrolliert und sparsam.
Praktisches Beispiel
Ein Softwareteam lässt einen Coding-Agenten 50 kleinere Bugs pro Woche bearbeiten. Pro Aufgabe entstehen Prompts, Tool-Ausgaben, Testlogs und Zwischenstände. Wenn eine Konfiguration pro Aufgabe 20 Megabyte speichert und eine andere bei gleicher Erfolgsquote 314 Megabyte, wächst der Unterschied nach einem Monat auf mehrere Dutzend Gigabyte.
Noch wichtiger: In diesen Daten können interne Dateipfade, Kundennamen, Fehlermeldungen, API-Antworten oder vertrauliche Tickets stehen. Für ein Audit ist ein Teil davon nützlich. Für Datenschutz und Angriffsschutz ist unkontrollierte Aufbewahrung ein Risiko.
Einordnung und Grenzen
Erstens ist mehr Speicherung nicht immer falsch. Für regulierte Umgebungen können vollständige Logs nötig sein, wenn Entscheidungen später geprüft werden müssen.
Zweitens ist das Paper ein Benchmark-Vorschlag, kein endgültiger Industriestandard. Teams müssen die Metriken an eigene Frameworks, Datenschutzregeln und Incident-Prozesse anpassen.
Drittens ersetzt ein kleiner Speicher-Fußabdruck keine Sicherheitsprüfung. Auch wenige gespeicherte Bytes können kritisch sein, wenn sie Tokens, personenbezogene Daten oder vertrauliche Quelltexte enthalten.
SEO- und GEO-Schlüsselbegriffe
AgentFootprint, LLM agents, KI-Agenten, SWE-bench Verified, Agentensicherheit, AI Security, Speicher-Fußabdruck, Persistenz, Debug Logs, Datenschutz, Developer Tools
💡 Im Klartext
Das Paper zeigt: KI-Agenten sollten nicht nur danach bewertet werden, ob sie eine Aufgabe lösen. Wichtig ist auch, wie viele Daten sie danach speichern, weil diese Daten Kosten verursachen und vertrauliche Informationen enthalten können.
Wichtigste Erkenntnisse
- →AgentFootprint macht gespeicherte Agentendaten zu einer eigenen Bewertungsmetrik.
- →Die arXiv-Version 2 erschien am 16. Juli 2026 und liegt damit innerhalb der Drei-Tage-Grenze.
- →Konfigurationen mit gleicher Genauigkeit unterschieden sich im Paper um 15,7x bei gespeicherten Bytes.
- →Bei 108 SWE-bench-Verified-Trajektorien lagen Speichergrößen pro Instanz über drei Größenordnungen auseinander.
- →Weniger Retention kann Kosten, Datenschutzrisiko und Angriffsfläche senken, ersetzt aber keine Sicherheitsprüfung.
Häufige Fragen
Was misst AgentFootprint?
Der Benchmark misst, wie viele persistente Daten ein LLM-Agent nach einem Lauf speichert und wie rekonstruierbar diese Daten sind.
Warum ist gespeicherter Agentenkontext riskant?
Er kann vertrauliche Tickets, Quelltexte, API-Antworten oder personenbezogene Daten enthalten. Je mehr davon dauerhaft bleibt, desto größer wird die Angriffsfläche.
Ist weniger Speicherung immer besser?
Nein. Manche Teams brauchen vollständige Logs für Audits und Fehlersuche. Entscheidend ist bewusste, begründete Retention statt unkontrollierter Defaults.