Approfondimento tecnico: rilevamento di catene di strumenti pericolosi e uso improprio degli agenti a livello di esecuzione

Il divario: le chiamate consentite individualmente che costituiscono un uso improprio¶

La politica per chiamata risponde bene a una domanda: possa questo preside utilizzare questo strumento con questi argomenti qui e ora. Una lista consentita per chiamata non ha memoria, quindi non può rispondere se questa chiamata è pericolosa considerando ciò che ha già fatto l'esecuzione. Tre modelli sintetici mostrano il divario.

Un agente dell'assistenza può leggere il record di un cliente, riassumere il testo e chiamare un webhook di notifica. Ogni funzionalità ha un uso legittimo. La combinazione all'interno di un'esecuzione sposta i dati regolamentati verso una destinazione esterna. Un agente dei pagamenti può inviare pagamenti al di sotto di una soglia di approvazione 500; sessanta chiamate di questo tipo in una sola corsa muovono 25,000 senza una sola decisione umana. Un agente di recupero autorizzato a elencare i clienti e uno strumento di esportazione autorizzato a scrivere file sono entrambi insignificanti; l'enumerazione seguita da un'esportazione in blocco è una forma di esfiltrazione da manuale.

La modalità di fallimento è la composizione. Ogni gate ha rilevato una chiamata consentita e l'oggetto pericoloso (la sequenza, l'aggregato, il flusso di dati tra strumenti) non è mai esistito come singolo input di policy. Il rilevamento a livello di esecuzione rende l'oggetto valutabile.

Cosa vede effettivamente un checkpoint di corsa¶

Le policy KLA valutano le espressioni JSON Logic su un GateContext tipizzato. Le regole per chiamata leggono context.action: il nome dello strumento, gli argomenti e la destinazione di una chiamata proposta. Le regole del checkpoint di esecuzione leggono context.run.tools: un accumulatore che l'executionworker mantiene durante un'esecuzione, codificato da una chiave informativa sicura per strumento.

Ciascuna voce di strumento contiene quattro fatti. calls conta le operazioni completate, con le chiavi delle operazioni riprovate deduplicate in modo che un nuovo tentativo temporaneo non possa aumentare il conteggio. argValues contiene valori a forma di identificatore deduplicati, limitati e dichiarati dal registro. numericSums contiene le somme degli input numerici finiti dichiarati dal registro. numericMaximums mantiene il massimo per campo durante l'esecuzione, un aggregato non ordinato che impedisce a una regola ripetuta di valore basso di corrispondere a un numero limitato di chiamate di valore elevato.

Il confine di proiezione è volutamente stretto. Uno strumento di registro accede tramite metadata.run_fact_arg_keys, metadata.run_fact_numeric_keys e uno metadata.run_fact_key opzionale; ogni elenco di campi dichiarati accetta al massimo chiavi 32. La proiezione viene eseguita accanto all'esecutore dello strumento e l'osservazione che attraversa il flusso di lavoro temporale contiene l'ID tenant, l'ID esecuzione, la chiave dello strumento codificata, un digest opaco dell'operazione e i valori dichiarati. L'input dello strumento non elaborato, il testo libero, le stringhe numeriche e l'ordine degli eventi non oltrepassano mai tale limite, quindi i fatti di esecuzione non possono diventare una copia shadow di payload sensibili.

{
  "tools": {
    "secret_read": {
      "calls": 1,
      "argValues": {},
      "numericSums": {},
      "numericMaximums": {}
    },
    "external_send": {
      "calls": 1,
      "argValues": {},
      "numericSums": {},
      "numericMaximums": {}
    },
    "payment_submit": {
      "calls": 12,
      "argValues": {
        "beneficiary_id": [
          "bene-2201",
          "bene-2207",
          "bene-2213"
        ]
      },
      "numericSums": {
        "amount": 4620
      },
      "numericMaximums": {
        "amount": 480
      }
    }
  }
}

• Proprietà: il flusso di lavoro temporale possiede l'accumulatore e rifiuta le osservazioni di un altro tenant o viene eseguito prima dell'aggregazione.
• Limiti: le identità operative distinte e i valori degli identificatori conservati sono limitati, quindi uno strumento loquace non può gonfiare lo stato del flusso di lavoro.
• Approvazione vincolante: uno strumento il cui output è delimitato contribuisce con i suoi fatti solo dopo che il proprio output gate ha deciso di approvare. Una chiamata bloccata, un rifiuto della visualizzazione della cassaforte o un'approvazione per un altro varco non ammettono nulla.
• Fatti relativi all'occorrenza: uno strumento con una dichiarazione esplicita del fatto di esecuzione registra una voce calls anche quando non dichiara alcun identificatore o campo numerico, quindi una policy può richiedere che lo screening sia stato effettivamente eseguito.

Tre modelli di regole deterministiche, configurati dal tenant¶

buildDangerousToolChainRules in @kla/shared genera tre regole deterministiche per una versione della politica del tenant. Il tenant fornisce i nomi degli strumenti di registro, i nomi dei campi numerici, le soglie e il risultato che ciascuna regola dovrebbe risolvere: warn, require_approval o block, con un gruppo di approvatori a cui si applica l'approvazione.

Il primo modello corrisponde a un'esecuzione in cui uno strumento configurato per il recupero dei segreti e uno strumento configurato per l'invio esterno sono stati entrambi completati prima del checkpoint. Il secondo corrisponde all'enumerazione dei clienti concomitante con un'esportazione il cui conteggio dei record dichiarati raggiunge il volume configurato. Il terzo corrisponde ad azioni ripetute di basso valore: il conteggio delle chiamate e l'importo aggregato raggiungono le rispettive soglie mentre il massimo per chiamata rimane pari o inferiore al limite configurato, che è la firma strutturale della suddivisione della soglia.

Le regole generate sono regole di policy ordinarie. Valutano nella normale versione della policy dell'inquilino attraverso lo stesso motore di ogni regola per chiamata, in modalità deterministica, con ID regola e codici motivo stabili. La policy seguente incorpora l'output esatto dell'helper per un modello sintetico; il test di pari livello in questo repository lo rigenera da @kla/shared e dimostra che i due corrispondono e che il documento è convalidato rispetto allo schema PolicyVersion pubblicato.

{
  "schemaVersion": "1.0.0",
  "policyId": "pol_run_tool_chain_checkpoints",
  "workspaceId": "workspace-regulated-operations",
  "name": "Run tool-chain checkpoints",
  "description": "Evaluates accumulated run facts at workflow checkpoints for dangerous tool-call co-occurrences and aggregates.",
  "status": "draft",
  "version": "1.0.0",
  "policyKind": "guardrail",
  "scope": {
    "workflowIds": [],
    "agentIds": [],
    "stepIds": [],
    "environments": [
      "prod"
    ]
  },
  "defaultDecision": "allow",
  "rules": [
    {
      "ruleId": "run-tool-chain-secret-then-external",
      "name": "Secret retrieval and external send co-occur",
      "description": "Detects configured secret retrieval and external-send calls that co-occur before a checkpoint. Version 1 does not establish call order.",
      "when": {
        "expression": {
          "and": [
            {
              ">": [
                {
                  "var": "context.run.tools.secret_read.calls"
                },
                0
              ]
            },
            {
              ">": [
                {
                  "var": "context.run.tools.external_send.calls"
                },
                0
              ]
            }
          ]
        }
      },
      "then": {
        "decision": "block",
        "reason": "The run retrieved a secret and reached an external destination before this checkpoint.",
        "reasonCodes": [
          "run_chain_secret_then_external"
        ]
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.run.tools.secret_read.calls",
          "context.run.tools.external_send.calls"
        ],
        "artifactRefs": []
      }
    },
    {
      "ruleId": "run-tool-chain-enumeration-then-export",
      "name": "Customer enumeration and large export co-occur",
      "description": "Detects configured customer enumeration and large export facts that co-occur before a checkpoint. Version 1 does not establish call order.",
      "when": {
        "expression": {
          "and": [
            {
              ">": [
                {
                  "var": "context.run.tools.customer_enumeration.calls"
                },
                0
              ]
            },
            {
              ">=": [
                {
                  "var": "context.run.tools.customer_export.numericSums.record_count"
                },
                500
              ]
            }
          ]
        }
      },
      "then": {
        "decision": "require_approval",
        "reason": "The run enumerated customers and exported records past the configured volume.",
        "reasonCodes": [
          "run_chain_enumeration_then_export"
        ],
        "approverGroup": "security_reviewers"
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "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": "Repeated low-value actions exceed aggregate threshold",
      "description": "Detects configured repeated actions whose every declared amount is at or below the configured per-call bound and whose aggregate crosses the configured threshold.",
      "when": {
        "expression": {
          "and": [
            {
              ">=": [
                {
                  "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
              ]
            }
          ]
        }
      },
      "then": {
        "decision": "require_approval",
        "reason": "Repeated payments below the per-call bound crossed the aggregate threshold.",
        "reasonCodes": [
          "run_chain_repeated_low_value"
        ],
        "approverGroup": "payments_reviewers"
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.run.tools.payment_submit.calls",
          "context.run.tools.payment_submit.numericSums.amount",
          "context.run.tools.payment_submit.numericMaximums.amount"
        ],
        "artifactRefs": []
      }
    }
  ]
}

Dove si trova il checkpoint e cosa succede al rilevamento¶

Le regole della politica KLA si collegano ai punti di intercettazione lungo il percorso di esecuzione governato: input, tool_call, tool_result, step_output e alle porte della politica del flusso di lavoro. L'applicazione per chiamata rimane a tool_call, prima di ogni effetto collaterale, esattamente come descritto nella guida all'audit MCP. I fatti di esecuzione vengono forniti solo ai passaggi policy_gate del flusso di lavoro, quindi una regola a catena lascia interceptionPoint non impostato e si attiva nei checkpoint posizionati dall'autore del flusso di lavoro dopo i passaggi dell'agente. Un checkpoint vede i fatti delle chiamate completate prima di quel gate e la sua decisione viene risolta prima che venga eseguita qualsiasi fase successiva; le chiamate già eseguite conservano i propri record delle decisioni per chiamata.

Il posizionamento è una decisione progettuale con lo stesso carattere del posizionamento di un vincolo nel database. Un checkpoint dopo ogni passaggio dell'agente limita la quantità di un'esecuzione che può comporre tra le valutazioni. Un unico checkpoint prima del passaggio finale consequenziale (l'invio, l'esportazione, il rilascio del batch) concentra la revisione laddove si verifica l'effetto irreversibile. Entrambi i posizionamenti utilizzano le stesse regole e producono gli stessi record.

In una partita, la decisione segue la semantica standard dell'KLA. block termina l'operazione e un motore di policy irraggiungibile risolve il fail-closed nello stesso stato terminale. require_approval sospende il flusso di lavoro e instrada una richiesta di decisione al gruppo di approvatori configurato e l'esecuzione riprende solo in caso di approvazione autorizzata. avviso consente alla corsa di procedere e crea un segnale rivedibile. L'incidente attiva l'attivazione attraverso il percorso decisionale delle policy esistente, che è anche il punto in cui si inserisce il contenimento con ambito di esecuzione come il kill switch quando un rilevamento giustifica la sospensione dell'agente oltre l'esecuzione corrente.

La prova prodotta da un rilevamento¶

Il rilevamento di un checkpoint non crea alcun tipo di record personalizzato. Il checkpoint valuta attraverso la stessa attività di policy-gate di ogni altro gate, quindi la decisione persistente porta l'ID e la versione della policy, l'ID della regola corrispondente, la decisione risolta, il motivo e i codici motivo, la modalità determinismo e i campi valutati, che per queste regole sono gli stessi percorsi dei fatti di esecuzione, come context.run.tools.payment_submit.numericSums.amount. La decisione si basa sul percorso esistente di audit, attivazione degli incidenti e prove.

Questo riutilizzo è importante per la revisione. Nell'Audit Trail, una catena bloccata si legge come qualsiasi altra azione bloccata: un attore, un gate, una versione della policy, una regola, un codice motivo come run_chain_repeated_low_value e un risultato terminale, uniti all'esecuzione dall'identificatore di esecuzione. Un auditor che può già verificare una decisione per chiamata può verificare una decisione a catena con la stessa procedura, e i numeri valutati dalla regola (dodici chiamate, un totale di 4,620, e un massimo per chiamata di 480)) sono presenti nel contesto della decisione senza alcun carico utile di pagamento grezzo accanto a loro.

Quando il risultato è require_approval, la Richiesta di decisione mostra al revisore la regola corrispondente, il motivo e i fatti aggregati che hanno superato la soglia e l'approvazione o il rifiuto si legano a tale richiesta attraverso il flusso standard. L'esportazione delle prove sigillate contiene quindi l'intero arco: la per-call consente di ammettere ogni fatto, la decisione del checkpoint che ha rilevato la composizione, la decisione umana dove era richiesta e lo stato terminale della corsa.

Mappatura degli esempi alle categorie di minacce degli agenti OWASP¶

L'OWASP Top 10 for Agentic Applications, versione 2026 nomina le classi di minaccia a cui questi controlli si rivolgono. La guida ai controlli di runtime e alle prove associa tutte e dieci le categorie ai controlli KLA e l'EU AI Act crosswalk le associa agli articoli normativi. La tabella seguente inserisce solo i rilevamenti a livello di esecuzione in quel frame.

Limiti della versione 1¶

L'implementazione fornita indica i propri limiti e un tecnico della sicurezza dovrebbe progettare attorno ad essi. Le regole valutano i conteggi, gli identificatori e gli aggregati numerici dichiarati; la versione 1 non conserva né deduce l'ordine delle chiamate, quindi una regola di co-occorrenza si attiva se la lettura segreta è avvenuta prima o dopo l'invio esterno. Per un controllo delle esfiltrazioni questa asimmetria è accettabile perché entrambi gli ordini meritano una revisione. Le regole non controllano i payload grezzi, il ragionamento del modello o i punteggi delle anomalie statistiche.

I fatti vivono nell'attuale stato del flusso di lavoro temporale. Non esiste un archivio ordinato di eventi-azione durevoli, nessuna inferenza sui predecessori e nessuna correlazione tra esecuzioni indipendenti, quindi una catena divisa su due esecuzioni elude un checkpoint a esecuzione singola. Un checkpoint vede solo le chiamate completate prima di quel gate; una chiamata consequenziale effettuata dopo l'ultimo checkpoint di una corsa è regolata esclusivamente dai relativi gate per chiamata e di uscita. Il posizionamento del percorso rimane dell'autore del flusso di lavoro.

L'adozione della produzione richiede tre passaggi controllati dal tenant: dichiarazioni di registro per gli strumenti effettivamente gestiti, una versione pubblicata della policy del tenant contenente le regole generate e un flusso di lavoro policy_gate posizionato dopo il passaggio dell'agente pertinente. Il percorso del codice e le sue strutture deterministiche vengono forniti nella piattaforma; le soglie e i risultati sono decisioni di governance che ciascun inquilino prende per la propria propensione al rischio.