Tiefer Einblick in die Technik: Erkennung gefährlicher Toolketten und Run-Level-Agent-Missbrauch

Die Lücke: individuell erlaubte Anrufe, die zu Missbrauch führen¶

Die Richtlinie pro Anruf beantwortet eine Frage gut: Darf dieser Auftraggeber dieses Tool hier und jetzt mit diesen Argumenten ausführen? Eine Zulassungsliste pro Anruf verfügt über keinen Speicher und kann daher nicht beantworten, ob dieser Anruf angesichts dessen, was der Lauf bereits bewirkt hat, gefährlich ist. Drei synthetische Muster zeigen die Lücke.

Ein Supportmitarbeiter kann einen Kundendatensatz lesen, Text zusammenfassen und einen Benachrichtigungs-Webhook aufrufen. Jede Fähigkeit hat einen legitimen Nutzen. Die Kombination innerhalb eines Laufs verschiebt regulierte Daten an ein externes Ziel. Ein Zahlungsagent kann Zahlungen unter einer Genehmigungsschwelle von 500 einreichen; Sechzig solcher Anrufe in einem Lauf bewegen 25.000 ohne eine einzige menschliche Entscheidung. Ein Retrieval-Agent, der Kunden auflisten darf, und ein Export-Tool, das Dateien schreiben darf, sind beide unauffällig; Eine Aufzählung mit anschließendem Massenexport ist eine Exfiltrationsform wie aus dem Lehrbuch.

Der Fehlermodus ist die Zusammensetzung. Jedes Tor sah einen erlaubten Aufruf, und das gefährliche Objekt (die Sequenz, das Aggregat, der werkzeugübergreifende Datenfluss) existierte nie als einzelne Richtlinieneingabe. Die Run-Level-Erkennung macht dieses Objekt auswertbar.

Was ein Run-Checkpoint tatsächlich sieht¶

KLA-Richtlinien werten JSON-Logikausdrücke über ein typisiertes GateContext aus. Die Regeln pro Aufruf lauten context.action: der Toolname, die Argumente und das Ziel eines vorgeschlagenen Aufrufs. Die Run-Checkpoint-Regeln lesen context.run.tools: ein Akkumulator, den der Ausführungsarbeiter während eines Laufs verwaltet und der durch einen sicheren Faktschlüssel pro Tool verschlüsselt ist.

Jeder Tool-Eintrag enthält vier Fakten. calls zählt abgeschlossene Vorgänge, wobei die Schlüssel für wiederholte Vorgänge dedupliziert werden, sodass ein temporärer Wiederholungsversuch die Anzahl nicht erhöhen kann. argValues enthält deduplizierte, begrenzte, in der Registrierung deklarierte, bezeichnerförmige Werte. numericSums enthält die Summen der in der Registrierung deklarierten endlichen numerischen Eingaben. numericMaximums hält das Maximum pro Feld während des Laufs, ein ungeordnetes Aggregat, das verhindert, dass eine wiederholte Regel mit niedrigem Wert mit einer kleinen Anzahl von Aufrufen mit hohem Wert übereinstimmt.

Die Projektionsgrenze ist bewusst schmal. Ein Registrierungstool meldet sich über metadata.run_fact_arg_keys, metadata.run_fact_numeric_keys und optional metadata.run_fact_key an; Jede deklarierte Feldliste akzeptiert höchstens 32 Schlüssel. Projection wird neben dem Tool-Executor ausgeführt, und die Beobachtung, die in den Temporal-Workflow übergeht, enthält die Mandanten-ID, die Ausführungs-ID, den codierten Tool-Schlüssel, einen undurchsichtigen Operations-Digest und die deklarierten Werte. Rohe Werkzeugeingaben, freier Text, numerische Zeichenfolgen und die Ereignisreihenfolge überschreiten diese Grenze nie, sodass Lauffakten nicht zu einer Schattenkopie sensibler Nutzlasten werden können.

{
  "Werkzeuge": {
    „secret_read“: {
      „Anrufe“: 1,
      "argValues": {},
      "numericSums": {},
      "numericMaximums": {}
    },
    „external_send“: {
      „Anrufe“: 1,
      "argValues": {},
      "numericSums": {},
      "numericMaximums": {}
    },
    "zahlung_submit": {
      „Anrufe“: 12,
      „argValues“: {
        „beneficiary_id“: [
          „bene-2201“,
          „bene-2207“,
          „bene-2213“
        ]
      },
      "numericSums": {
        "Betrag": 4620
      },
      „numericMaximums“: {
        "Betrag": 480
      }
    }
  }
}

• Eigentum: Der Temporal-Workflow ist Eigentümer des Akkumulators und lehnt Beobachtungen von einem anderen Mandanten ab oder wird vor der Aggregation ausgeführt.
• Grenzen: Eindeutige Vorgangsidentitäten und beibehaltene Bezeichnerwerte sind begrenzt, sodass ein Chatty-Tool den Workflow-Status nicht erhöhen kann.
• Genehmigungsbindung: Ein Tool, dessen Ausgabe mit einem Gatter versehen ist, trägt seinen Fakt erst bei, nachdem sein eigenes Ausgabegatter zur Genehmigung aufgelöst wurde. Ein blockierter Anruf, eine Ablehnung der Safe-Anzeige oder eine Genehmigung für ein anderes Tor lässt nichts zu.
• Fakten zum Vorkommen: Ein Tool mit einer expliziten Run-Fact-Deklaration zeichnet einen calls-Eintrag auf, auch wenn es keinen Bezeichner oder kein numerisches Feld deklariert, sodass eine Richtlinie erfordern kann, dass die Überprüfung tatsächlich ausgeführt wurde.

Drei deterministische Regelvorlagen, mandantenkonfiguriert¶

buildDangerousToolChainRules in @kla/shared generiert drei deterministische Regeln für eine Mandantenrichtlinienversion. Der Mandant stellt die Namen der Registrierungstools, die numerischen Feldnamen, die Schwellenwerte und das Ergebnis bereit, das jede Regel auflösen soll: warn, require_approval oder block, mit einer Genehmigergruppe, für die die Genehmigung gilt.

Die erste Vorlage entspricht einem Lauf, bei dem ein konfiguriertes Secret-Retrieval-Tool und ein konfiguriertes External-Send-Tool beide vor dem Prüfpunkt abgeschlossen wurden. Die zweite Option gleicht die Kundenaufzählung ab, die gleichzeitig mit einem Export erfolgt, dessen deklarierte Datensatzanzahl das konfigurierte Volumen erreicht. Die dritte Methode gleicht wiederholte Aktionen mit geringem Wert ab: Die Anrufanzahl und die Gesamtmenge erreichen ihre Schwellenwerte, während das Maximum pro Anruf bei oder unter der konfigurierten Grenze bleibt, was die strukturelle Signatur der Schwellenwertaufteilung darstellt.

Bei den generierten Regeln handelt es sich um normale Richtlinienregeln. Sie werten in der normalen Richtlinienversion des Mandanten über dieselbe Engine aus wie jede Regel pro Aufruf, im deterministischen Modus, mit stabilen Regel-IDs und Ursachencodes. Die folgende Richtlinie bettet die genaue Ausgabe des Hilfsprogramms für eine synthetische Vorlage ein; Der Geschwistertest in diesem Repository generiert es aus @kla/shared neu und beweist, dass die beiden übereinstimmen und dass das Dokument anhand des veröffentlichten PolicyVersion-Schemas validiert wird.

{
  „schemaVersion“: „1.0.0“,
  „policyId“: „pol_run_tool_chain_checkpoints“,
  „workspaceId“: „workspace-regulated-operations“,
  „name“: „Tool-Chain-Prüfpunkte ausführen“,
  „description“: „Wertet akkumulierte Lauffakten an Workflow-Kontrollpunkten auf gefährliche Tool-Call-Kookkurrenzen und Aggregate aus.“,
  „status“: „Entwurf“,
  „Version“: „1.0.0“,
  „policyKind“: „guardrail“,
  "Umfang": {
    „workflowIds“: [],
    "agentIds": [],
    "stepIds": [],
    „Umgebungen“: [
      „Produkt“
    ]
  },
  „defaultDecision“: „allow“,
  „Regeln“: [
    {
      „ruleId“: „run-tool-chain-secret-then-external“,
      „name“: „Geheimer Abruf und externer Versand treten gleichzeitig auf“,
      „description“: „Erkennt konfigurierte Secret-Retrieval- und External-Send-Aufrufe, die vor einem Prüfpunkt gleichzeitig auftreten. Version 1 legt keine Aufrufreihenfolge fest.“,
      „wann“: {
        „Ausdruck“: {
          „und“: [
            {
              ">": [
                {
                  „var“: „context.run.tools.secret_read.calls“
                },
                0
              ]
            },
            {
              ">": [
                {
                  „var“: „context.run.tools.external_send.calls“
                },
                0
              ]
            }
          ]
        }
      },
      „dann“: {
        „Entscheidung“: „block“,
        „reason“: „Der Lauf hat ein Geheimnis abgerufen und vor diesem Prüfpunkt ein externes Ziel erreicht.“,
        „reasonCodes“: [
          „run_chain_secret_then_external“
        ]
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.run.tools.secret_read.calls“,
          „context.run.tools.external_send.calls“
        ],
        „artifactRefs“: []
      }
    },
    {
      „ruleId“: „run-tool-chain-enumeration-then-export“,
      „name“: „Kundenaufzählung und großer Export treten gleichzeitig auf“,
      „description“: „Erkennt konfigurierte Kundenaufzählungen und große Exportfakten, die vor einem Prüfpunkt gleichzeitig auftreten. Version 1 legt keine Anrufreihenfolge fest.“,
      „wann“: {
        „Ausdruck“: {
          „und“: [
            {
              ">": [
                {
                  „var“: „context.run.tools.customer_enumeration.calls“
                },
                0
              ]
            },
            {
              ">=": [
                {
                  „var“: „context.run.tools.customer_export.numericSums.record_count“
                },
                500
              ]
            }
          ]
        }
      },
      „dann“: {
        „Entscheidung“: „require_approval“,
        „reason“: „Der Lauf zählte Kunden auf und exportierte Datensätze über das konfigurierte Volumen hinaus.“,
        „reasonCodes“: [
          „run_chain_enumeration_then_export“
        ],
        „approverGroup“: „security_reviewers“
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.run.tools.customer_enumeration.calls“,
          „context.run.tools.customer_export.numericSums.record_count“
        ],
        „artifactRefs“: []
      }
    },
    {
      „ruleId“: „run-tool-chain-repeated-low-value-actions“,
      „name“: „Wiederholte Aktionen mit geringem Wert überschreiten den Gesamtschwellenwert“,
      „description“: „Erkennt konfigurierte wiederholte Aktionen, deren jede deklarierte Menge bei oder unter der konfigurierten Grenze pro Aufruf liegt und deren Gesamtheit den konfigurierten Schwellenwert überschreitet.“,
      „wann“: {
        „Ausdruck“: {
          „und“: [
            {
              ">=": [
                {
                  „var“: „context.run.tools. payment_submit.calls“
                },
                10
              ]
            },
            {
              ">=": [
                {
                  „var“: „context.run.tools. payment_submit.numericSums.amount“
                },
                4000
              ]
            },
            {
              "<=": [
                {
                  „var“: „context.run.tools. payment_submit.numericMaximums.amount“
                },
                500
              ]
            }
          ]
        }
      },
      „dann“: {
        „Entscheidung“:„require_approval“,
        „reason“: „Wiederholte Zahlungen unterhalb der Grenze pro Anruf haben den Gesamtschwellenwert überschritten.“,
        „reasonCodes“: [
          „run_chain_repeated_low_value“
        ],
        „approverGroup“: „zahlungen_reviewers“
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.run.tools. payment_submit.calls“,
          „context.run.tools. payment_submit.numericSums.amount“,
          „context.run.tools. payment_submit.numericMaximums.amount“
        ],
        „artifactRefs“: []
      }
    }
  ]
}

Wo sich der Kontrollpunkt befindet und was passiert, wenn er entdeckt wird¶

KLA-Richtlinienregeln werden an Abfangpunkte entlang des geregelten Ausführungspfads angehängt: input, tool_call, tool_result, step_output und Workflow-Richtlinien-Gates. Die Durchsetzung pro Anruf bleibt vor jedem Nebeneffekt bei tool_call, genau wie im MCP-Prüfungsleitfaden beschrieben. Ausführungsfakten werden nur für Workflow-policy_gate-Schritte bereitgestellt, daher lässt eine Kettenregel interceptionPoint nicht festgelegt und löst an den Prüfpunkten aus, die der Workflow-Autor nach Agentenschritten platziert. Ein Kontrollpunkt sieht die Fakten der vor diesem Gate abgeschlossenen Anrufe und seine Entscheidung wird vor der Ausführung eines späteren Schritts aufgelöst; Die bereits ausgeführten Anrufe führen ihre eigenen Entscheidungsaufzeichnungen pro Anruf.

Die Platzierung ist eine Entwurfsentscheidung mit demselben Charakter wie die Platzierung einer Datenbankbeschränkung. Ein Prüfpunkt nach jedem Agentenschritt begrenzt, wie viel ein Lauf zwischen den Auswertungen zusammensetzen kann. Ein einziger Kontrollpunkt vor dem daraus resultierenden letzten Schritt (dem Senden, dem Export, der Stapelfreigabe) konzentriert die Überprüfung dort, wo der irreversible Effekt auftritt. Beide Platzierungen verwenden dieselben Regeln und erzeugen dieselben Datensätze.

Bei einer Übereinstimmung folgt die Entscheidung der Standard-KLA-Semantik. block beendet den Vorgang und eine nicht erreichbare Richtlinien-Engine löst Fail-Closed in denselben Terminalstatus auf. require_approval pausiert den Workflow und leitet eine Entscheidungsanfrage an die konfigurierte Genehmigergruppe weiter, und die Ausführung wird nur bei einer autorisierten Genehmigung fortgesetzt. warn lässt den Lauf weiterlaufen und erzeugt ein überprüfbares Signal. Vorfallauslöser werden über den vorhandenen Richtlinienentscheidungspfad ausgelöst, an den auch eine laufbezogene Eindämmung wie der Kill-Schalter angehängt wird, wenn eine Erkennung eine Suspendierung des Agenten über die aktuelle Ausführung hinaus erfordert.

Der Beweis, den eine Entdeckung liefert¶

Eine Checkpoint-Erkennung erstellt keinen maßgeschneiderten Datensatztyp. Der Prüfpunkt wertet über die gleiche Policy-Gate-Aktivität aus wie jedes andere Gate, sodass die persistente Entscheidung die Richtlinien-ID und -Version, die übereinstimmende Regel-ID, die aufgelöste Entscheidung, den Grund und die Ursachencodes, den Determinismusmodus und die ausgewerteten Felder enthält, die für diese Regeln die Run-Fact-Pfade selbst sind, wie z. B. context.run.tools.payment_submit.numericSums.amount. Die Entscheidung landet auf dem bestehenden Prüfungs-, Vorfallauslöser- und Beweispfad.

Diese Wiederverwendung ist für die Überprüfung wichtig. Im Audit Trail liest sich eine blockierte Kette wie jede andere blockierte Aktion: ein Akteur, ein Gate, eine Richtlinienversion, eine Regel, ein Ursachencode wie run_chain_repeated_low_value und ein Endergebnis, verbunden mit der Ausführung durch die Ausführungskennung. Ein Prüfer, der bereits eine Entscheidung pro Anruf überprüfen kann, kann mit demselben Verfahren eine Kettenentscheidung überprüfen, und die von der Regel ausgewerteten Zahlen (zwölf Anrufe, insgesamt 4.620, ein Maximum pro Anruf von 480) sind im Entscheidungskontext vorhanden, ohne dass daneben Rohzahlungsnutzlasten vorhanden sind.

Wenn das Ergebnis require_approval ist, zeigt die Entscheidungsanforderung dem Prüfer die übereinstimmende Regel, den Grund und die aggregierten Fakten, die den Schwellenwert überschritten haben, und die Genehmigung oder Ablehnung wird über den Standardablauf an diese Anfrage gebunden. Der versiegelte Beweisexport enthält dann den gesamten Bogen: die pro Anruf zugelassenen Genehmigungen, die jede Tatsache zuließen, die Kontrollpunktentscheidung, die die Zusammensetzung erfasste, die menschliche Entscheidung, wo eine erforderlich war, und den Endstatus des Laufs.

Zuordnung der Beispiele zu OWASP-Agenten-Bedrohungskategorien¶

Die OWASP Top 10 for Agentic Applications, Version 2026 benennt die Bedrohungsklassen, gegen die diese Kontrollen vorgehen. Der Runtime Controls and Evidence Guide ordnet alle zehn Kategorien KLA-Kontrollen zu, und der EU AI Act Crosswalk ordnet sie Regulierungsartikeln zu. In der folgenden Tabelle werden nur die Runlevel-Erkennungen in diesem Frame platziert.

Grenzen der Version 1¶

Die ausgelieferte Implementierung gibt ihre Grenzen an, und ein Sicherheitsingenieur sollte diese berücksichtigen. Regeln werten deklarierte Zählungen, Bezeichner und numerische Aggregate aus; Version 1 behält die Aufrufreihenfolge nicht bei oder leitet sie nicht ab. Daher wird eine Regel für das gemeinsame Vorkommen ausgelöst, unabhängig davon, ob der geheime Lesevorgang vor oder nach dem externen Senden erfolgt ist. Für eine Exfiltrationskontrolle ist diese Asymmetrie akzeptabel, da beide Ordnungen einer Überprüfung bedürfen. Regeln prüfen keine Rohnutzlasten, Modellbegründungen oder statistische Anomaliewerte.

Fakten leben im aktuellen Temporal-Workflow-Status. Es gibt keinen geordneten dauerhaften Aktionsereignisspeicher, keine Vorgängerinferenz und keine Korrelation zwischen unabhängigen Läufen, sodass eine auf zwei Läufe aufgeteilte Kette einen Prüfpunkt für einen einzelnen Lauf umgeht. An einem Kontrollpunkt werden nur Anrufe angezeigt, die vor diesem Gate abgeschlossen wurden. Ein Folgeaufruf, der nach dem letzten Kontrollpunkt eines Laufs platziert wird, wird allein durch seine Pro-Aufruf- und Ausgabe-Gates gesteuert. Die Routenplatzierung verbleibt beim Workflow-Autor.

Die Produktionseinführung erfordert drei vom Mandanten kontrollierte Schritte: Registrierungsdeklarationen für die tatsächlich verwalteten Tools, eine veröffentlichte Mandantenrichtlinienversion mit den generierten Regeln und einen Workflow policy_gate, der nach dem relevanten Agentenschritt platziert wird. Der Codepfad und seine deterministischen Vorrichtungen werden in der Plattform ausgeliefert; Die Schwellenwerte und Ergebnisse sind Governance-Entscheidungen, die jeder Mieter im Hinblick auf seine eigene Risikobereitschaft trifft.