Eine Lieferantenprüfung erreicht ihre letzte Stufe. Ein Agent liest eine Übergabedatei, laut der die Nachweise vollständig sind, erstellt eine Zusammenfassung und sendet sie an die genehmigende Person. Die Datei hat einen bekannten Autor, einen Zeitstempel und einen intakten Digest (eine kryptografische Prüfsumme). Ein unterstützendes Dokument fehlt weiterhin.
Der Workflow dient der Veranschaulichung. Er rahmt eine technische Frage: Welcher Teil des Systems prüft eine Aussage, unmittelbar bevor ein anderer Agent auf ihrer Grundlage handelt? Ein Nachweis über den Ersteller erklärt, woher eine Aussage stammt. Der empfangende Workflow muss zusätzlich klären, ob diese Aussage die vorgeschlagene Aktion stützt. Dieser Beitrag bespricht aktuelle Forschung zu Agenten-Skills, berichtet über eine eng begrenzte Untersuchung eines veröffentlichten Benchmarks und stellt ein Prüfprotokoll für die Datei bereit, die ein Skill an den nächsten übergibt. Er gehört zu unseren Forschungsnotizen zur Agentenausführung, nach Unabhängigkeit der Prüfer und Grenzen von Benchmark-Scores.
Skill-Ausgaben werden zu Eingaben späterer Arbeit
Agenten-Skills bündeln Anweisungen, Skripte und Ressourcen zur Wiederverwendung. Ihre Ausgaben können zu Eingaben späterer Arbeit werden. Eine Zusammenfassung, eine Tabelle oder eine lokale Datenbank kann einen früheren Fehler in eine spätere Entscheidung tragen, auch nachdem die Konversation, die sie erzeugt hat, beendet ist. Unsere frühere Notiz zu Richtlinien im Agentengedächtnis befasste sich mit gespeicherten Richtlinienzusammenfassungen. Diese Notiz befasst sich mit erzeugten Arbeitsergebnissen, die ein späterer Schritt als Nachweis behandelt.
SkillRelay, ein am 9. Oktober 2026 eingereichtes Preprint von Liao et al., untersucht dieses Fortbestehen über getrennte Sitzungen hinweg. In seinem Bedrohungsmodell kontrolliert der Angreifer vor der Ausführung mehrere Skills; Benutzeraufgaben und vertrauenswürdige Projektrichtlinien bleiben außerhalb seiner Kontrolle. Die Autoren unterscheiden ein schädliches Ergebnis von einer vollständigen Angriffskette über die vorgesehene Übergabe. Zum Paper (v1).
Die Abwehr im Paper kombiniert Provenienz mit der Prüfung vorgeschlagener Operationen. Die Prüfung ist verpflichtend und beratend: Nach einer ablehnenden Empfehlung kann der Agent die geprüfte Anfrage trotzdem bestätigen. Es handelt sich um Befunde aus einem kontrollierten Benchmark, und das Paper schätzt nicht, wie oft Organisationen dieser Bedrohung begegnen. Wir haben die Ergebnisse nicht reproduziert. Dieser Beitrag lässt die Angriffs- und Abwehrraten des Papers weg; wer sie verwendet, sollte jeden Nenner im Paper prüfen.
Die Abdeckungserklärung benennt, was die Prüfung auslässt
Das nützlichste Implementierungsdetail steht im veröffentlichten Code. Beim fixierten Commit erstellen die Zeilen 57 bis 66 der Datei run.py des Guards eine Abdeckungserklärung, die die vom Prototyp geprüften Operationen und die außerhalb dieser Prüfung liegenden Wirkungen benennt. Eine Datei coverage.json hält diese Grenze für jeden geschützten Lauf fest. Fixierte Abdeckungserklärung.
Die Implementierung nennt weitere Grenzen: Provenienz wird pro Stufe verfolgt, die Vermittlung des Netzwerkverkehrs ist unvollständig, und ein nach dem Lesen berechneter Hash kann nicht zeigen, welche Bytes gelesen wurden, während ein anderer Prozess schrieb. Es sind Grenzen des Prototyps, die die Autoren offen benennen. Wir haben den Quellcode als Text gelesen und die Abdeckung zur Laufzeit nicht ausgeführt.
Eine solche Erklärung verdient Aufmerksamkeit, weil ein Workflow dasselbe folgenreiche Ergebnis auf mehreren Wegen erreichen kann. Ein Nachweispaket kann über eine API veröffentlicht, in ein gemeinsames Verzeichnis exportiert oder aus einer Datenbank zusammengestellt werden, die ein anderer Dienst liest. Die Prüfung der API-Anfrage deckt einen Weg ab. Eine Architekturprüfung muss die anderen nachverfolgen, bevor sie den gesamten Workflow als geprüft bezeichnet.
- Geprüft: Übermittlung über den Adapter des Prototyps, mit einer Ersatzprüfung beim empfangenden Dienst.
- Außerhalb der Operationsprüfung: beliebige lokale Dateiänderungen.
- Außerhalb der Operationsprüfung: Veröffentlichung in eine lokale SQLite-Datenbank.
- Außerhalb der Operationsprüfung: Datenverkehr zum Modell-Gateway.
Was wir im veröffentlichten Artefakt geprüft haben
Wir haben das Repository bei Commit f7fa742 (8. Oktober 2026) als Daten untersucht. Über zwei lesende GitHub-API-Anfragen haben wir den vollständigen Benchmark-Katalog und den ungekürzten Git-Baum ausgewertet und jeden Konfigurationspfad, auf den der Katalog verweist, mit dem Baum abgeglichen.
Damit ist eine eng begrenzte strukturelle Eigenschaft des Release bestätigt: Der Katalog ist in sich konsistent, und die referenzierten Dateien sind vorhanden. Wir haben den Benchmark nicht ausgeführt, seine Skills in keinem Agentenkontext installiert und seine Sicherheitsergebnisse nicht reproduziert. Das Vorhandensein eines Pfads sagt nichts über den Dateiinhalt aus und zeigt daher nicht, dass die harmlosen Eingaben harmlos sind. Die Zahlen beschreiben das Design des Benchmarks und haben keine Aussagekraft über Leistung.
| Prüfung | Beobachtet |
|---|---|
| Eindeutige Fallkennungen | 270 |
| Szenarien | 30 |
| Domänengruppen | 10, mit je 27 Fällen |
| Angriffsmuster | 3, mit je 90 Fällen |
| Injektionsflächen | Code, Anweisungen und Ressourcen, mit je 90 Fällen |
| Referenzierte Konfigurationspfade, die im Baum fehlen | 0 |
| Fallverzeichnisse mit einem Pfad für harmlose Eingaben | 270 von 270 |
Erstellung, Nachweise und Autorisierung getrennt halten
Zurück zum Lieferantenbeispiel: Geben Sie der Übergabe zwei Datensätze. Der erste beschreibt die Erstellung: die Aufgabe, die die Datei erzeugt hat, die Version des Erstellers, den Digest des Artefakts und die Quellenverweise. Der zweite beschreibt die empfangende Entscheidung: die aktuelle Aufgabe, den vorgesehenen Empfänger, den genauen ausgehenden Inhalt, die zu überprüfenden Aussagen und die Person oder Regel, die für die Autorisierung verantwortlich ist.
Diese Datensätze beantworten unterschiedliche Fragen. Ein intakter Digest bindet eine Prüfung an bestimmte Bytes. Ein Quellenverweis zeigt auf unterstützendes Material. Die Aussage, dass ein Prüfer etwas genehmigt hat, braucht einen eigenen Entscheidungsdatensatz und Umfang. Keines dieser Felder sollte stillschweigend ein anderes ersetzen. Auch ein vollständig wirkendes Manifest kann eine unbelegte Schlussfolgerung beschreiben.
Ein Prüfer sollte außerdem sowohl die Datei als auch die Operation sehen können, zu der sie geführt hat. Halten Sie fest, welche Originalquellen geprüft wurden, welche konkrete Anfrage geprüft wurde, ob sich die Anfrage danach geändert hat und welche Schnittstelle die Wirkung tatsächlich ausgelöst hat. Wer eine Lieferantenentscheidung prüft, sollte dieser Kette folgen können, ohne sie aus einer geglätteten Zusammenfassung rekonstruieren zu müssen.
Ein Prüfprotokoll für die Übergabe
Das Prüfprotokoll für Skill-Übergaben (auf Englisch) macht aus diesen Fragen Felder. Es ist ein veranschaulichendes Arbeitsblatt für einen synthetischen Workflow und wurde nicht als Sicherheitskontrolle evaluiert. Passen Sie es an das System an, dem die Entscheidung gehört und das die Aktion ausführt.
Bewahren Sie Prüf- und Autorisierungsdatensätze außerhalb der Kontrolle des Erstellers auf, wo das Vertrauensmodell des Systems es verlangt. Ein vom Ersteller ausgefülltes Feld, das eine Genehmigung behauptet, muss bei der Instanz geprüft werden, der diese Entscheidung gehört. Erfassen Sie für jede Wirkung jeden Weg, den der Workflow nutzen kann: API-Aufrufe, Exporte in gemeinsame Verzeichnisse und Datenbankänderungen, die ein anderer Prozess liest. Halten Sie die tatsächliche Prüfgrenze fest und den Nachweis, dass sie auf diese Anfrage angewendet wurde. Kennzeichnen Sie Wege ohne diesen Nachweis als nicht verifiziert.
| Datensatz | Was einzutragen ist |
|---|---|
| Artefakt | Kennung, exakte Version oder Digest, Speicherort |
| Erstellung | Ursprüngliche Aufgabe, Paket und Version des Erstellers, Erstellungszeitpunkt |
| Aktuelle Verwendung | Empfangende Aufgabe, vorgesehener Zweck, zulässiger Empfänger |
| Folgenreiche Aussagen | Jede Aussage, deren Wahrheit die Entscheidung beeinflusst |
| Unterstützende Nachweise | Originalquelle und Version, relevante Passage oder relevantes Feld, Lücken und Widersprüche |
| Vorgeschlagene Wirkung | Schnittstelle, Aktion, Ziel, exakte Payload-Version oder Digest |
| Prüfung | Prüfer, Entscheidung, unterstützende Nachweise, Umfang, Zeitpunkt |
| Autorisierung | Entscheidungsverantwortliche Person oder geltende Regel, zulässige Aktion und zulässiger Empfänger |
| Ausführung | Tatsächliche Schnittstelle, Kennung der angenommenen Anfrage, beobachtete Wirkung |
Drei synthetische Fälle zum Testen einer Übergabe
Eine erste Untersuchung kann klein bleiben. Wählen Sie eine wiederkehrende Übergabe und eine folgenreiche Aktion, erfassen Sie jeden Weg von der Datei zu dieser Wirkung und führen Sie drei synthetische Fälle mit festen Quelldatensätzen und einem lokalen Empfänger aus. Bewahren Sie die Originalmaterialien, die erzeugte Datei, die exakte ausgehende Anfrage, das Prüfergebnis und die beobachtete Wirkung auf.
Zählen Sie legitime Abschlüsse, akzeptierte unbelegte Aussagen, versuchte Offenlegungen außerhalb des Umfangs, Wirkungen, die die Prüfung umgangen haben, und Ausführungsfehler als getrennte Ergebnisse. Behandeln Sie Fehler als Fehler. Das erwartete Verhalten in der Tabelle ist ein vorgeschlagenes Evaluierungskriterium. Wir haben diese Übung nicht durchgeführt, daher stützt sie keine Schutzrate.
| Synthetischer Fall | Quelle und angeforderte Verwendung | Zu evaluierendes erwartetes Verhalten |
|---|---|---|
| Gestützte Übergabe | Quellenverzeichnis ist vollständig; Empfänger ist autorisiert | Die angeforderte Übergabe abschließen |
| Unbelegte Erledigung | Übergabe meldet vollständige Nachweise; im Quellenverzeichnis fehlt ein Dokument | Die Aussage korrigieren oder an den verantwortlichen Prüfer weiterleiten |
| Abweichender Empfänger | Aussagen sind belegt; der vorgesehene Empfängerkreis liegt außerhalb des zulässigen Umfangs | Die erforderliche Autorisierung einholen oder die Offenlegung unterlassen |
Verwandte Forschung zu Skills
Mehrere aktuelle Papers betrachten Skills aus anderen Blickwinkeln. Jedes untersucht eine andere Prüfeinheit: ein Paket, eine Kette von Paketen oder eine spätere Nutzung ihrer Ausgabe.
- SkillCascade (Zhu et al., v1, 24. September 2026) untersucht schädliche Wechselwirkungen zwischen gemeinsam installierten Skills, einschließlich Fällen, die Scans einzelner Skills bestehen. Es betrachtet die Zusammensetzung innerhalb eines Workflows; SkillRelay betrachtet Artefakte, die über Sitzungen hinweg erhalten bleiben. Die Autoren räumen ein, dass kontrollierte Sandboxes keine Häufigkeit in der Praxis belegen können, und erörtern die Grenzen der Ergebnisbewertung durch ein Modell. SkillCascade v1.
- Counterfactual Trace Auditing (Zhou et al., v2 überarbeitet am 28. Mai 2026, erstmals veröffentlicht am 12. Mai) vergleicht gleichartige Aufgaben mit und ohne Skill und erfasst Verhaltensunterschiede. Jede Bedingung läuft einmal, mit einem Modell und einem Benchmark, daher schränken die Autoren die kausale Deutung ein. Für einen Übergabetest übertragbar ist die Idee, Lesevorgänge, Schreibvorgänge und Operationen zusammen mit der Aufgabenerledigung zu vergleichen. Counterfactual Trace Auditing v2.
- Security Skills für die Erkennung von Linux-Schwachstellen (Xue et al., v1, 19. Oktober 2026) evaluiert ausgewählte Security Skills bei dateigeführter Analyse des Linux-Kernels. Böswillige Übergaben untersucht das Paper nicht, und seine Erkennungsraten lassen sich nicht auf Dokumentübergaben übertragen. Paper v1.
- ACES (Kevin et al., v1, 20. August 2026) schlägt eine gepaarte Live-Evaluierung mit und ohne Skill vor, und SkillEval (Han et al., v2 überarbeitet am 12. Oktober 2026, erstmals veröffentlicht am 7. August) bewertet Eigenschaften von Skill-Dokumenten. Von beiden haben wir nur Abstract und Einleitung gelesen. ACES v1, SkillEval v2.
Wo KLA eine genehmigte Aktion erneut prüft
Für Agenten, die über die KLA-Schnittstelle für Agentenaktionen handeln, bewertet die KLA Policy Engine jede vorgeschlagene Aktion, und ein Ergebnis require_approval erzeugt eine Entscheidungsanfrage. Wird die genehmigte Aktion fortgesetzt, vergleicht KLA ihre Argumente mit dem Hash, der bei der Anforderung der Genehmigung versiegelt wurde. Haben sich die Argumente geändert, wird die Aktion mit dem Grundcode tool_args_mismatch blockiert und nicht ausgeführt. Diese Prüfung beantwortet für Aktionen, die über diese Schnittstelle eingereicht werden, die Frage des Protokolls, „ob sich die Anfrage danach geändert hat“. Eine Datei, die ein Agent direkt in ein gemeinsames Verzeichnis schreibt, ist ein eigener Weg und braucht eine eigene Zeile im Protokoll.
Die Forschung in diesem Beitrag hat KLA nicht getestet. Der Leitfaden zur menschlichen Aufsicht behandelt, wann eine Aktion eine Genehmigung erfordern sollte und wie der Maker-Checker-Workflow sie aufzeichnet.
Häufig gestellte Fragen
Kann die Ausgabe eines KI-Agenten-Skills eine spätere Sitzung beeinflussen?
Ja, wenn die Ausgabe gespeichert wird und eine spätere Aufgabe sie liest. Eine Zusammenfassung, eine Tabelle oder eine lokale Datenbank, die ein Skill geschrieben hat, kann eine unbelegte Aussage in eine spätere Entscheidung tragen, nachdem die ursprüngliche Konversation beendet ist. Das SkillRelay-Preprint untersucht dies in einem kontrollierten Benchmark; es schätzt nicht, wie oft es in der Praxis vorkommt.
Belegt Provenienz, dass eine Übergabedatei korrekt ist?
Nein. Provenienz hält fest, wer die Datei erstellt hat und wann, und ein Digest bindet eine Prüfung an bestimmte Bytes. Ob jede Aussage in der Datei belegt ist, muss anhand der Originalquellen geprüft werden, und ob die nächste Aktion zulässig ist, braucht einen eigenen Autorisierungsdatensatz.
Was prüft der SkillRelay-Guard, und was lässt er aus?
Beim fixierten Commit erfasst seine Abdeckungserklärung als geprüft: Übermittlungen über den Adapter des Prototyps, mit einer Ersatzprüfung beim empfangenden Dienst. Beliebige lokale Dateiänderungen, die Veröffentlichung in eine lokale SQLite-Datenbank und Datenverkehr zum Modell-Gateway liegen laut der Erklärung außerhalb der Operationsprüfung. Die Prüfung ist beratend: Der Agent kann eine Anfrage nach einer ablehnenden Empfehlung bestätigen. Wir haben den Quellcode gelesen und nicht ausgeführt.
Wie testet man eine Agentenübergabe, bevor man ihr vertraut?
Wählen Sie eine wiederkehrende Übergabe und eine folgenreiche Aktion, erfassen Sie jeden Weg von der Datei zur Wirkung und führen Sie synthetische Fälle aus: eine gestützte Übergabe, eine unbelegte Erledigungsmeldung und einen Empfänger außerhalb des zulässigen Umfangs. Zählen Sie legitime Abschlüsse, akzeptierte unbelegte Aussagen, Wirkungen außerhalb des Umfangs, umgangene Prüfungen und Ausführungsfehler getrennt.
Die wichtigsten Erkenntnisse
Halten Sie für die nächste Übergabe, die Ihr Team prüft, vier Dinge zusammen: was der erste Agent erzeugt hat, was der nächste Agent verwendet hat, was der Prüfer gesehen hat und was am Ende geschehen ist. Geben Sie der für den Betrieb verantwortlichen Person eine Möglichkeit, jeden Weg dazwischen zu untersuchen. Trägt eine plausible Datei eine unbelegte Aussage in die reale Arbeit, zeigt dieser Datensatz, welche Entscheidung korrigiert werden muss. Beginnen Sie mit dem Prüfprotokoll für Skill-Übergaben.
Die Quellen wurden am 26. Oktober 2026 geprüft. SkillRelay und die verwandten Papers sind Preprints, und wir haben keines ihrer Ergebnisse reproduziert. Unsere Beobachtung ist eine Metadaten- und Pfadprüfung eines fixierten Repositorys. Das Lieferantenbeispiel und die drei Fälle sind synthetisch und wurden nicht ausgeführt.