Analyse approfondie de l'ingénierie : détection des chaînes d'outils dangereuses et de l'utilisation abusive des agents au niveau de l'exécution.

L'écart : les appels individuellement autorisés qui constituent une utilisation abusive¶

La politique d'appel par appel répond bien à une question : ce directeur peut-il exécuter cet outil avec ces arguments ici et maintenant. Une liste d'autorisation par appel n'a pas de mémoire, elle ne peut donc pas déterminer si cet appel est dangereux compte tenu de ce que l'exécution a déjà fait. Trois modèles synthétiques montrent l’écart.

Un agent d'assistance peut lire un enregistrement client, résumer du texte et appeler un webhook de notification. Chaque capacité a une utilisation légitime. La combinaison au sein d’une seule exécution déplace les données réglementées vers une destination externe. Un agent de paiement peut soumettre des paiements inférieurs à un seuil de 500 approval ; soixante de ces appels en un seul coup, 25,000 witho mais une seule décision humaine. Un agent de récupération autorisé à répertorier les clients et un outil d'exportation autorisé à écrire des fichiers sont tous deux banals ; L'énumération suivie d'un export groupé est une forme d'exfiltration classique.

Le mode d'échec est la composition. Chaque porte a vu un appel autorisé, et l'objet dangereux (la séquence, l'agrégat, le flux de données entre outils) n'a jamais existé en tant qu'entrée politique unique. La détection au niveau de l'exécution rend cet objet évaluable.

Ce qu'un point de contrôle d'exécution voit réellement¶

Les politiques KLA évaluent les expressions logiques JSON sur un « GateContext » typé. Les règles par appel indiquent « contexte.action » : le nom de l'outil, les arguments et la destination d'un appel proposé. Les règles de point de contrôle d'exécution se lisent comme « context.run.tools » : un accumulateur que l'exécutant maintient tout au long d'une exécution, saisi par une clé de fait sécurisée par outil.

Chaque entrée d'outil contient quatre faits. calls compte les opérations terminées, avec les clés d'opération réessayées dédupliquées afin qu'une nouvelle tentative temporelle ne puisse pas gonfler le décompte. argValues contient des valeurs en forme d'identifiant dédupliquées, plafonnées et déclarées par le registre. numericSums contient les sommes des entrées numériques finies déclarées par le registre. « numericMaximums » contient le maximum par champ tout au long de l'exécution, un agrégat non ordonné qui empêche une règle répétée de faible valeur de correspondre à un petit nombre d'appels de grande valeur.

La limite de projection est volontairement étroite. Un outil de registre s'inscrit via metadata.run_fact_arg_keys, metadata.run_fact_numeric_keys et un metadata.run_fact_key facultatif ; chaque liste de champs déclarée accepte au plus 32 keys. La projection s'exécute à côté de l'exécuteur de l'outil et l'observation qui pénètre dans le flux de travail temporel contient l'ID du locataire, l'ID d'exécution, la clé de l'outil codée, un résumé d'opération opaque et les valeurs déclarées. Les entrées brutes des outils, le texte libre, les chaînes numériques et l'ordre des événements ne franchissent jamais cette limite, de sorte que les faits d'exécution ne peuvent pas devenir une copie instantanée des charges utiles sensibles.

{
  "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
      }
    }
  }
}

• Propriété : le workflow temporel est propriétaire de l'accumulateur et rejette les observations d'un autre locataire ou s'exécute avant l'agrégation.
• Limites : les identités d'opération distinctes et les valeurs d'identifiant conservées sont plafonnées, de sorte qu'un outil bavard ne peut pas gonfler l'état du flux de travail.
• Liaison d'approbation : un outil dont la sortie est bloquée ne contribue à son fait qu'après que sa propre porte de sortie décide d'approuver. Un appel bloqué, un refus d'affichage sécurisé ou une approbation pour une autre porte n'admet rien.
• Faits d'occurrence : un outil avec une déclaration de fait d'exécution explicite enregistre une entrée "appels" même lorsqu'il ne déclare aucun identifiant ni champ numérique, de sorte qu'une politique peut exiger que le filtrage soit réellement exécuté.

Trois modèles de règles déterministes, configurés par le locataire¶

buildDangerousToolChainRules dans @kla/shared génère trois règles déterministes pour une version de stratégie de locataire. Le locataire fournit les noms des outils de registre, les noms des champs numériques, les seuils et le résultat que chaque règle doit résoudre : warn, require_approval ou block, avec un groupe d'approbateurs où l'approbation s'applique.

Le premier modèle correspond à une exécution dans laquelle un outil de récupération de secret configuré et un outil d'envoi externe configuré se sont tous deux terminés avant le point de contrôle. La seconde correspond à l’énumération des clients concomitante à une exportation dont le nombre d’enregistrements déclaré atteint le volume configuré. Le troisième correspond aux actions répétées de faible valeur : le nombre d'appels et le montant global atteignent leurs seuils tandis que le maximum par appel reste égal ou inférieur à la limite configurée, qui est la signature structurelle de la répartition des seuils.

Les règles générées sont des règles de politique ordinaires. Ils évaluent la version de politique normale du locataire via le même moteur que chaque règle par appel, en mode déterministe, avec des ID de règle et des codes de motif stables. La politique ci-dessous intègre la sortie exacte de l'assistant pour un modèle synthétique ; le test frère dans ce référentiel le régénère à partir de @kla/shared et prouve que les deux correspondent et que le document est validé par rapport au schéma PolicyVersion publié.

{
  "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": []
      }
    }
  ]
}

Où se situe le point de contrôle et ce qui se passe en cas de détection¶

Les règles de politique KLA s'attachent aux points d'interception le long du chemin d'exécution gouverné : input, tool_call, tool_result, step_output et les portes de stratégie de workflow. L'application par appel reste à tool_call, avant chaque effet secondaire, exactement comme le décrit le guide d'audit MCP. Les faits d'exécution sont fournis uniquement aux étapes policy_gate du workflow, donc une règle de chaîne laisse interceptionPoint non défini et se déclenche aux points de contrôle que l'auteur du workflow place après les étapes de l'agent. Un point de contrôle voit les faits des appels terminés avant cette porte, et sa décision est résolue avant l'exécution de toute étape ultérieure ; les appels déjà exécutés conservent leurs propres enregistrements de décision par appel.

Le placement est une décision de conception ayant le même caractère que le placement d'une contrainte de base de données. Un point de contrôle après chaque étape de l'agent limite la quantité qu'une exécution peut composer entre les évaluations. Un seul point de contrôle avant l'étape finale qui en découle (l'envoi, l'export, la libération du lot) concentre la révision là où se produit l'effet irréversible. Les deux placements utilisent les mêmes règles et produisent les mêmes enregistrements.

Lors d'une correspondance, la décision suit la sémantique standard de KLA. block met fin à l'opération et un moteur de stratégie inaccessible résout la fermeture en cas d'échec dans le même état de terminal. require_approval met le flux de travail en pause et achemine un Decision Request vers le groupe d'approbateurs configuré, et l'exécution reprend uniquement sur une approbation autorisée. warn laisse l'exécution se poursuivre et crée un signal révisable. Les déclencheurs d'incidents se déclenchent via le chemin de décision politique existant, qui est également l'endroit où le confinement à l'échelle de l'exécution tel que le kill switch s'attache lorsqu'une détection justifie la suspension de l'agent au-delà de l'exécution en cours.

La preuve qu'une détection produit¶

Une détection de point de contrôle ne crée aucun type d'enregistrement sur mesure. Le point de contrôle évalue via la même activité de porte de politique que toutes les autres portes, de sorte que la décision persistante contient l'ID et la version de la politique, l'ID de règle correspondant, la décision résolue, la raison et les codes de raison, le mode de déterminisme et les champs évalués, qui pour ces règles sont les chemins d'exécution eux-mêmes, tels que « contexte.run.tools.payment_submit.numericSums.amount ». La décision repose sur le cheminement existant en matière d’audit, de déclenchement d’incident et de preuves.

Cette réutilisation est importante pour examen. Dans l'Audit Trail, une chaîne bloquée se lit comme n'importe quelle autre action bloquée : un acteur, une porte, une version de politique, une règle, un code de raison tel que "run_chain_repeated_low_value" et un résultat final, joint à l'exécution par l'identifiant d'exécution. Un auditeur qui peut déjà vérifier une décision par appel peut vérifier une décision en chaîne avec la même procédure, et les nombres évalués par la règle (douze appels, un total de 4,620, un maximum par appel de 480) sont présents dans le contexte de décision sans aucune charge utile de paiement brute à côté d'eux.

Lorsque le résultat est « require_approval », le Decision Request montre au réviseur la règle correspondante, la raison et l'ensemble des faits qui ont dépassé le seuil, et l'approbation ou le rejet est lié à cette demande via le flux standard. L'exportation de preuves scellées contient alors l'arc complet : l'appel par appel permet d'admettre chaque fait, la décision du point de contrôle qui a capturé la composition, la décision humaine lorsqu'elle était requise et l'état final de la course.

Mappage des exemples avec les catégories de menaces agents OWASP¶

Les Top 10 OWASP des applications agentiques, version 2026 nomment les classes de menaces auxquelles ces contrôles s'adressent. Le guide des contrôles d'exécution et des preuves mappe les dix catégories aux contrôles KLA, et le concordance de la loi européenne sur l'IA les mappe aux articles réglementaires. Le tableau ci-dessous place uniquement les détections au niveau de l'exécution dans ce cadre.

Limites de la version 1¶

La version expédiée la mise en œuvre indique ses limites, et un ingénieur en sécurité doit les contourner. Les règles évaluent les décomptes déclarés, les identifiants et les agrégats numériques ; La version 1 does ne conserve ni ne déduit l'ordre des appels, donc une règle de cooccurrence se déclenche si la lecture du secret a eu lieu avant ou après l'envoi externe. Pour un contrôle d’exfiltration, cette asymétrie est acceptable car les deux ordres méritent d’être revus. Les règles n’inspectent pas les charges utiles brutes, le raisonnement du modèle ou les scores d’anomalies statistiques.

Les faits sont présents dans l'état actuel du flux de travail temporel. Il n'y a pas de magasin d'événements d'action durables ordonnés, pas d'inférence de prédécesseur et pas de corrélation entre les exécutions indépendantes, de sorte qu'une chaîne divisée en deux exécutions échappe à un point de contrôle d'exécution unique. Un point de contrôle ne voit que les appels terminés avant cette porte ; un appel consécutif passé après le dernier point de contrôle d'une exécution est régi uniquement par ses portes d'appel et de sortie. Le placement de l'itinéraire reste la propriété de l'auteur du flux de travail.

L'adoption de la production nécessite trois étapes contrôlées par le locataire : des déclarations de registre pour les outils réellement gouvernés, une version de politique de locataire publiée contenant les règles générées et un workflow policy_gate placé après l'étape de l'agent concerné. Le chemin du code et ses éléments déterministes sont livrés dans la plateforme ; les seuils et les résultats sont des décisions de gouvernance que chaque locataire prend en fonction de son propre appétit pour le risque.