Tool-Chain-Analyse

Sicherheitsziel

Die Tool-Chain-Analyse rekonstruiert die geordnete Kette vorgeschlagener und beobachteter Tool-Aktionen aus Telemetrie und Lineage, die die Anwendung erfasst, und bewertet die kumulative, zusammengesetzte Wirkung der Kette gegen Regeln und Invarianten auf Aufgabenebene. Sie ist nötig, weil einzeln plausible und sogar einzeln autorisierte Aufrufe nicht bedeuten, dass die Kette als Ganzes sicher ist.

Ein Lesezugriff auf einen internen Datensatz, eine lokale Zusammenfassung und eine Benachrichtigung sind jeweils unauffällig. Hintereinander können sie einen Pfad bilden, der interne Daten an ein Ziel bringt, das die Aufgabe nie enthielt. Zwei Reservierungen, die jeweils ein Limit pro Aufruf einhalten, können zusammen die Obergrenze der Aufgabe überschreiten. Eine Wiederholung nach einer verlorenen Bestätigung kann eine bereits eingetretene Wirkung verdoppeln.

Zuständigkeitsgrenzen

Der übergreifende Artikel Erkennung von Prompt Injection ordnet Sequenzsignale in eine größere Korrelationsarchitektur ein. Diese Seite vertieft genau diese eine Ebene.

Bedrohungsmodell

Die Sorge ist, dass beeinflusstes Modellverhalten, ob aus direkter Eingabe, abgerufenen Inhalten, Tool-Ausgaben oder dem Ergebnis eines Sub-Agenten, den Agenten in eine Folge lenkt, deren Gesamtwirkung die Aufgabe nie verlangt hat. Jeder Schritt kann wie normale Arbeit aussehen. Ein möglicher Schaden liegt in der Zusammensetzung.

Nicht im Umfang: Absicht nachweisen, Inhalte als böswillig beurteilen und entscheiden, ob ein einzelner Aufruf laufen darf. Dafür sind Triage, Inhaltsprüfung und Autorisierung zuständig.

Was ist eine Tool-Chain?

Auf dieser Seite ist eine Tool-Chain die geordnete, gegebenenfalls verzweigte Menge von Tool-Aufrufen, die zu einer Aufgabe gehören, einschließlich der Aufrufe delegierter Sub-Agenten, zusammen mit der Daten- und Ressourcen-Lineage, die sie verbindet. Dazu gehören vorgeschlagene Aufrufe, autorisierte, übermittelte oder ausgeführte Aufrufe und ihre erfassten Ergebnisse.

Warum die Prüfung einzelner Aufrufe nicht reicht

Die Prüfung je Aufruf fragt, ob eine aufgelöste Anfrage erlaubt und korrekt geformt ist. Sie sieht nicht, was ein früherer Aufruf gelesen hat, was ein späterer senden wird, wie viele Einheiten bereits reserviert sind oder ob eine identische Wirkung noch offen ist. Diese Fakten existieren nur über mehrere Aufrufe hinweg.

Die Verfügbarkeit eines Tools ist keine Erlaubnis und sagt nichts darüber aus, was eine Kette insgesamt bewirkt.

Maßgebliche Kettenevidenz

Die maßgebliche Kette stammt aus Datensätzen der Anwendung: Aufgaben- und Lauf-IDs, geordnete Aufruf-IDs, Tool und Operation, konkret aufgelöste Parameter, Ressourcenklassen, Ziele, Daten-Lineage, Zähler, Idempotenzschlüssel, Delegationsdatensätze und Ausführungszustände.

Vertrauensmodell

Aufgabenregeln, Telemetrie, Analyse und Reaktionsrichtlinie sind Systemkomponenten. Die vorgeschlagene Kette ist variabler Inhalt. Auch das zurückgegebene Ergebnis eines Sub-Agenten ist variabler Inhalt; seine Lineage und sein Delegationsdatensatz sind Fakten der Anwendung.

Kettenrekonstruktion

Die Reihenfolge wird ausdrücklich rekonstruiert. Laufen Aufrufe parallel, belegen Zeitstempel allein weder Reihenfolge noch Abhängigkeit. Sequenznummern innerhalb eines Laufs und Eltern-Aufruf-IDs machen die Kette zu einem gerichteten Abhängigkeitsgraphen statt einer nach Uhrzeit sortierten Liste.

Verzweigungen und parallele Aufrufe werden als Verzweigungen dargestellt. Wer jeden Agentenlauf als linear behandelt, übersieht den Fall, in dem zwei parallele Lesezugriffe in ein späteres Senden münden.

Kettenidentität, Aufgabe und Korrelation

Diese Felder sind Engineering-Empfehlungen. Korrelations-IDs müssen über jeden Hop weitergegeben werden, sonst zerfällt die Kette in Bruchstücke, die jeweils harmlos wirken.

Modell der Ausführungszustände

Vorgeschlagene und beobachtete Ketten

Vorgeschlagene Ketten werden vor der Ausführung analysiert, damit Einschränkung oder Pause möglich sind. Beobachtete Ketten werden analysiert, um Abgleich und Untersuchung zu unterstützen. In der Telemetrie bleiben beide getrennt: Ein Befund zu einer vorgeschlagenen Kette sagt, was geschähe, wenn jeder Schritt liefe; ein Befund zu einer beobachteten Kette sagt, was die Datensätze als geschehen zeigen.

Jeder Fakt wird als beobachtet oder abgeleitet gekennzeichnet. Die Folgerung einer Analyse, ein Aufruf sei "wahrscheinlich erfolgreich", ist keine Beobachtung.

Kumulative Wirkungen und Invarianten auf Aufgabenebene

Regeln auf Aufgabenebene sind von technischen Limits je Aufruf getrennt. Ein Tool kann bis zu 40 Einheiten pro Aufruf annehmen, während die Aufgabe insgesamt 50 erlaubt. Kumulative Invarianten werden mit der Aufgabe erfasst, etwa Gesamteinheiten, Anzahl der Zustandsänderungen, erlaubte Zielklassen oder ein reiner Lese- und Entwurfsumfang, und jeder vorgeschlagene Schritt wird gegen die laufende Summe geprüft.

Lesen, dann senden: zusammengesetzte Datenflüsse

Lineage auf Sequenzebene verbindet einen Lesezugriff mit allem, was daraus abgeleitet wird. Erreicht abgeleiteter Inhalt eine ausgehende Senke, enthält die Kette einen durchgehenden Datenpfad, den die isolierte Prüfung einzelner Aufrufe nicht sieht. Die Analyse kann den Pfad mit einem Grund wie LINEAGE_TO_EXTERNAL_SINK markieren. Ob dieser Fluss erlaubt ist, bleibt eine Entscheidung der Informationsflusskontrolle.

Aufgeteilte Operationen und Summengrenzen

Wird eine große Wirkung auf mehrere kleine Aufrufe verteilt, bleibt jeder Aufruf im Limit, während die Summe die Aufgabengrenze überschreitet. Zähler der Anwendung werden je Aufgabe und Invariante geführt, aus erfassten Ausführungszuständen aktualisiert und bei der Bewertung einer vorgeschlagenen Kette um die vorgeschlagenen Aufrufe ergänzt. Eine Aufteilung kann harmlos sein; der Befund lautet CUMULATIVE_LIMIT_EXCEEDED und ist kein Vorwurf.

Wiederholungen, Idempotenz und unbeobachtete Ergebnisse

Wurde ein zustandsändernder Aufruf übermittelt und ging seine Bestätigung verloren, ist das Ergebnis unbeobachtet. Ein zweiter Aufruf mit neuem Idempotenzschlüssel kann die Wirkung verdoppeln. Das Engineering-Muster ist der Abgleich: vor jeder Wiederholung den Zielzustand lesen oder den ursprünglichen Idempotenzvertrag so wiederverwenden, wie die Anwendungsrichtlinie es festlegt.

Ressourcen- und Ziel-Lineage

Ressourcenklasse und Zielklasse werden durch die Kette mitgeführt. Eine neue Zielklasse, eine neue Ressourcenklasse oder eine neue zustandsändernde Wirkungsklasse, die die Aufgabenregeln nicht enthalten, ist ein starkes Kettensignal und wird als NEW_DESTINATION oder mit einem vergleichbaren Begründungscode gemeldet. Die Identität eines Ziels stammt aus aufgelösten Parametern, nicht aus der Bezeichnung durch das Modell. Ob ein neues Ziel überhaupt erreichbar ist, entscheiden getrennt die Netzwerk- und Egress-Beschränkungen.

Ketten über mehrere Agenten

Die Aufrufe eines delegierten Sub-Agenten gehören zur Kette der übergeordneten Aufgabe. Korrelations-IDs werden weitergegeben, der Delegationsumfang jedes Hops wird erfasst und jede Delegation bleibt eine begrenzte Teilmenge der übergeordneten.

Wie sich Beeinflussung über Hops ausbreitet, zeigt Multi-Agent Prompt Injection.

Effektiver Berechtigungsgraph und zusammengesetzte Fähigkeit

Als Engineering-Modell, nicht als Standardbegriff, verbindet ein effektiver Berechtigungsgraph Principals, Agenten, Delegationen, Tools, Ressourcen und Ziele. Die zusammengesetzte Fähigkeit ist die Menge der durchgehenden Wirkungen, die sich durch Kombination von Kanten innerhalb einer Aufgabe erreichen lassen. Ihre Analyse zeigt, wo enge Rechte sich zu breiten Wirkungen verbinden, und fließt in Kettenregeln und in das Design von Least Privilege ein.

Abgrenzung zur Plan-Drift-Erkennung

Plan-Drift-Erkennung und Tool-Chain-Analyse sind sich ergänzende Signalfamilien.

Abgrenzung zur Autorisierung je Aufruf

Die Autorisierung je Aufruf ist unabhängig. Ein Aufruf kann einzeln erlaubt sein, während die Folge trotzdem eine unsichere Gesamtwirkung erzeugt. Umgekehrt autorisiert eine Kette, die als innerhalb der Regeln eingestuft wurde, keinen Aufruf vorab. Jeder Aufruf durchläuft weiterhin die Agentenautorisierung.

Abgrenzung zur Informationsflusskontrolle

Die Informationsflusskontrolle entscheidet, ob Daten aus einer Quelle ein Ziel erreichen dürfen. Die Tool-Chain-Analyse kann einen Pfad aus Lesen und Senden erkennen; IFC trifft anhand von Labels und Richtlinien die getrennte, deterministische Flussentscheidung. Eine Kette innerhalb der Regeln stuft Daten nie herab.

Analysefamilien

Modellgestützte Kettenanalyse

Eine modellgestützte Analyse ist probabilistisch. Sie wird von unnötigem nicht vertrauenswürdigem Kontext isoliert, erhält keine Tools, liefert schemagebundene Befunde mit Begründungscodes und wird versioniert.

Reaktionsrichtlinie

Kein zusammengefasster Vertrauenswert. Kettenbefund, Provenienz, Autorisierung, Flussentscheidungen, Klassifikation und Ausführungsevidenz bleiben getrennte Felder.

Telemetrie-Design

Fehlen erforderliche Felder, wird CHAIN_INCOMPLETE gemeldet. Fehlende Evidenz ist nie ein Beleg dafür, dass die Kette innerhalb der Regeln liegt.

Alarmqualität und Triage

Alarme zeigen die geordnete Kette, die überschrittene Regel, den Begründungscode, Ausführungszustände und Lineage in einer Ansicht. Die Triage entscheidet, ob ein Befund auf Beeinflussung, eine fehlende Aufgabenregel, einen legitimen, nicht modellierten Ablauf oder einen Analysefehler zurückgeht. Die Ergebnisse fließen in Regeln und Regressionssatz zurück.

Durchgespieltes Szenario A: begrenzte interne Berichtskette

Aufgabe t-17: ops-user-dana bittet um einen internen Nachbestellbericht für SKU-17. Erfasste Kette: c1 read_stock(SKU-17), c2 read_threshold(SKU-17), c3 lokale Berechnung, c4 draft_report an ops-user-dana. Regeln: nur Lesen und Entwerfen, kein externes Ziel. Alle vier Schritte sind vorgeschlagen.

Einstufung: innerhalb der Kettenregeln. Das ist nur eine Einstufung auf Sequenzebene. Sie gewährt keine Autorisierung und keine dauerhafte oder künftige Befugnis; jeder Aufruf wird weiterhin einzeln autorisiert.

Durchgespieltes Szenario B: Lesen, dann externes Senden

Aufgabe t-310: support-user-ana bittet um eine Zusammenfassung des synthetischen Falls K-310. Erfasste Kette: c1 read_case(K-310), c2 lokale Zusammenfassung, c3 notify(to=reviewer@outside.example.test). Regeln: Antwort im Chat an die initiierende Nutzerin, kein ausgehender Schritt. c1 bis c3 sind vorgeschlagen.

Befund: Kettenrisiko mit LINEAGE_TO_EXTERNAL_SINK und NEW_DESTINATION. Der durchgehende Pfad würde interne Falldaten an ein externes Ziel bringen, das die Aufgabe nicht enthält. Weil alle Schritte nur vorgeschlagen sind, wird weder eine Exfiltration noch eine Ausführung behauptet. IFC und Autorisierung je Aufruf entscheiden weiterhin getrennt.

Durchgespieltes Szenario C: aufgeteilte Reservierung und Wiederholung nach unbeobachtetem Ergebnis

Aufgabe t-50 begrenzt Reservierungen von SKU-17 auf insgesamt 50 Einheiten; das Tool nimmt bis zu 40 pro Aufruf an. Die vorgeschlagene Kette lautet c1 reserviere 30 und c2 reserviere 30. Jeder Aufruf liegt unter dem Maximum je Aufruf, die Kettensumme beträgt aber 60. Befund: CUMULATIVE_LIMIT_EXCEEDED. Keiner der Aufrufe wurde ausgeführt, daher wird keine Reservierung behauptet, und die Aufteilung beweist keine böse Absicht.

Aufgabe t-44 verlangt genau ein synthetisches Ticket für SIM-44. c1 create_ticket mit Schlüssel sim44-1 wurde autorisiert und übermittelt, die Bestätigung ging verloren; c1 ist daher unbeobachtet, nicht fehlgeschlagen. Das vorgeschlagene c2 nutzt einen neuen Schlüssel sim44-2. Befund: DUPLICATE_EFFECT_RISK. Abgleich durch Lesen des Ticketzustands oder Wiederverwendung des Vertrags zu sim44-1 gemäß Anwendungsrichtlinie. Ein doppeltes Ticket wird nicht behauptet.

Eine Variante über mehrere Agenten: Zwei reine Lese-Sub-Agenten mit strikten Teilmengen-Delegationen und erhaltener Lineage beliefern einen übergeordneten Agenten, der eine interne Empfehlung entwirft. Ohne Vereinigung von Berechtigungen und ohne ausgehenden Schritt kann die Kette innerhalb der Regeln bleiben.

Was die Szenarien zeigen und was nicht

Dieselben Szenarien lassen sich im Lab Tool-Chain-Analyse üben, einer deterministischen Simulation.

Tests und Validierung

Ein gekennzeichneter Regressionssatz enthält harmlose mehrschrittige Ketten, riskante Zusammensetzungen, parallele Verzweigungen, Wiederholungen nach unbeobachteten Ergebnissen und Hops über mehrere Agenten. Tests prüfen, dass fehlende Felder CHAIN_INCOMPLETE ergeben, unbeobachtet nie als fehlgeschlagen gilt und Reaktionen Befugnisse nur verengen. Benchmarks wie AgentDojo und InjecAgent bewerten Agentenverhalten bei eingeschleusten Tool-Inhalten und können Szenarien anregen; sie definieren diese Kontrolle nicht.

Kennzahlen

Das sind operative Messgrößen, kein Sicherheitsnachweis. Sie werden nicht zu einem Wert zusammengefasst.

Häufige Fehler

Checkliste für die Umsetzung

Standards und Quellen

Zur Quellennutzung: Microsofts Leitlinie nennt Tool-Chain-Analyse als Technik, um riskante Folgen von Tool-Ausführungen zu bewerten und zu blockieren, neben Plan-Drift-Erkennung, Informationsflusskontrolle und Least Privilege; ein Verfahren legt sie nicht fest. Die OWASP Top 10 for Agentic Applications 2026 liefern Risikokontext zu Tool-Missbrauch sowie Identitäts- und Rechtemissbrauch; sie definieren keine Tool-Chain-Analyse. OWASP LLM01:2026 liefert Risikokontext zu Prompt Injection. NIST AI 100-2e2025 wird nur für Terminologie herangezogen. CaMeL ist verwandte Designforschung zur Trennung von Kontroll- und Datenfluss. Kettenschemata, Begründungscodes, Zähler, Idempotenzbehandlung und Graphrekonstruktion auf dieser Seite sind Engineering-Empfehlungen, keine Anforderungen dieser Quellen.

Häufige Fragen