Análisis profundo de ingeniería: detección de cadenas de herramientas peligrosas y uso indebido de agentes a nivel de ejecución

La brecha: llamadas permitidas individualmente que se convierten en uso indebido¶

La política por llamada responde bien a una pregunta: que este director ejecute esta herramienta con estos argumentos aquí y ahora. Una lista de permitidos por llamada no tiene memoria, por lo que no puede responder si esta llamada es peligrosa dado lo que ya hizo la ejecución. Tres patrones sintéticos muestran la brecha.

Un agente de soporte puede leer el registro de un cliente, resumir el texto y llamar a un webhook de notificación. Cada capacidad tiene un uso legítimo. La combinación dentro de una ejecución mueve datos regulados a un destino externo. Un agente de pagos puede enviar pagos por debajo de un umbral de aprobación de 500; Sesenta llamadas de este tipo en una sola ejecución mueven a 25.000 personas sin una sola decisión humana. Un agente de recuperación al que se le permite enumerar clientes y una herramienta de exportación a la que se le permite escribir archivos no tienen nada de especial; La enumeración seguida de una exportación masiva es una forma de exfiltración de libro de texto.

El modo de falla es la composición. Cada puerta vio una llamada permitida, y el objeto peligroso (la secuencia, el agregado, el flujo de datos entre herramientas) nunca existió como una única entrada de política. La detección a nivel de ejecución hace que ese objeto sea evaluable.

Lo que realmente ve un punto de control de ejecución¶

Las políticas de KLA evalúan expresiones lógicas JSON sobre un GateContext escrito. Las reglas por llamada leen context.action: el nombre de la herramienta, los argumentos y el destino de una llamada propuesta. Las reglas de punto de control de ejecución leen context.run.tools: un acumulador que el trabajador de ejecución mantiene durante una ejecución, codificado por una clave de hechos segura por herramienta.

Cada entrada de herramienta contiene cuatro hechos. calls cuenta las operaciones completadas, con claves de operación reintentadas deduplicadas para que un reintento temporal no pueda inflar el recuento. argValues contiene valores en forma de identificador declarados en el registro, limitados y deduplicados. numericSums contiene las sumas de las entradas numéricas finitas declaradas en el registro. numericMaximums mantiene el máximo por campo durante toda la ejecución, un agregado desordenado que evita que una regla repetida de valor bajo coincida con una pequeña cantidad de llamadas de alto valor.

El límite de proyección es deliberadamente estrecho. Una herramienta de registro se inscribe a través de metadata.run_fact_arg_keys, metadata.run_fact_numeric_keys y un metadata.run_fact_key opcional; cada lista de campos declarada acepta como máximo 32 claves. La proyección se ejecuta junto al ejecutor de la herramienta y la observación que pasa al flujo de trabajo temporal contiene el ID del inquilino, el ID de la ejecución, la clave de la herramienta codificada, un resumen de la operación opaco y los valores declarados. La entrada de herramientas sin procesar, el texto libre, las cadenas numéricas y el orden de los eventos nunca cruzan ese límite, por lo que los datos de ejecución no pueden convertirse en una instantánea de las cargas útiles confidenciales.

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

• Propiedad: el flujo de trabajo temporal es propietario del acumulador y rechaza las observaciones de otro inquilino o se ejecuta antes de la agregación.
• Límites: las distintas identidades de operación y los valores de identificadores retenidos tienen un límite, por lo que una herramienta conversacional no puede inflar el estado del flujo de trabajo.
• Vínculo de aprobación: una herramienta cuya salida está bloqueada aporta su hecho solo después de que su propia puerta de salida resuelve aprobar. Una llamada bloqueada, un rechazo de pantalla segura o una aprobación para una puerta diferente no admiten nada.
• Datos de ocurrencia: una herramienta con una declaración explícita de hechos de ejecución registra una entrada calls incluso cuando no declara ningún identificador o campo numérico, por lo que una política puede requerir que la detección realmente se haya ejecutado.

Tres plantillas de reglas deterministas, configuradas por inquilinos¶

buildDangerousToolChainRules en @kla/shared genera tres reglas deterministas para una versión de política de inquilino. El inquilino proporciona los nombres de las herramientas de registro, los nombres de los campos numéricos, los umbrales y el resultado que cada regla debe resolver: warn, require_approval o block, con un grupo de aprobadores donde se aplica la aprobación.

La primera plantilla coincide con una ejecución en la que una herramienta configurada de recuperación de secretos y una herramienta configurada de envío externo se completaron antes del punto de control. El segundo coincide con la enumeración de clientes que coincide con una exportación cuyo recuento de registros declarados alcanza el volumen configurado. El tercero coincide con acciones repetidas de bajo valor: el recuento de llamadas y la cantidad agregada alcanzan sus umbrales mientras que el máximo por llamada permanece en el límite configurado o por debajo de él, que es la firma estructural de la división de umbrales.

Las reglas generadas son reglas de políticas ordinarias. Se evalúan en la versión de política normal del inquilino a través del mismo motor que cada regla por llamada, en modo determinista, con ID de regla y códigos de motivo estables. La siguiente política incorpora el resultado exacto del asistente para una plantilla sintética; la prueba de hermanos en este repositorio lo regenera desde @kla/shared y demuestra que los dos coinciden y que el documento se valida con el esquema PolicyVersion publicado.

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

Dónde se encuentra el puesto de control y qué sucede cuando se detecta¶

Las reglas de políticas de KLA se adjuntan a puntos de intercepción a lo largo de la ruta de ejecución gobernada: input, tool_call, tool_result, step_output y puertas de políticas de flujo de trabajo. La aplicación por llamada permanece en tool_call, antes de cada efecto secundario, exactamente como lo describe la guía de auditoría de MCP. Los datos de ejecución se proporcionan solo a los pasos de policy_gate del flujo de trabajo, por lo que una regla de cadena deja interceptionPoint sin configurar y se activa en los puntos de control que el autor del flujo de trabajo coloca después de los pasos del agente. Un punto de control ve los hechos de las llamadas completadas antes de esa puerta y su decisión se resuelve antes de que se ejecute cualquier paso posterior; las llamadas que ya se ejecutaron mantienen sus propios registros de decisiones por llamada.

La ubicación es una decisión de diseño con el mismo carácter que colocar una restricción de base de datos. Un punto de control después de cada paso del agente limita cuánto puede componer una ejecución entre evaluaciones. Un único punto de control antes del consiguiente paso final (el envío, la exportación, la liberación del lote) concentra la revisión donde se produce el efecto irreversible. Ambas ubicaciones utilizan las mismas reglas y producen los mismos registros.

En un partido, la decisión sigue la semántica estándar del KLA. bloque finaliza la operación y un motor de políticas inalcanzable resuelve el cierre fallido en el mismo estado de terminal. require_approval pausa el flujo de trabajo y dirige una solicitud de decisión al grupo de aprobadores configurado, y la ejecución se reanuda solo con una aprobación autorizada. advertir permite que la ejecución continúe y crea una señal revisable. Los desencadenantes de incidentes se activan a través de la ruta de decisión de políticas existente, que también es donde se conecta la contención del alcance de la ejecución, como el [interruptor de apagado] (/blog/ai-agent-kill-switch-interception-architecture), cuando una detección justifica la suspensión del agente más allá de la ejecución actual.

La evidencia que produce una detección.¶

Una detección de punto de control no crea ningún tipo de registro personalizado. El punto de control se evalúa a través de la misma actividad de puerta de política que cualquier otra puerta, por lo que la decisión persistente lleva el ID y la versión de la política, el ID de la regla coincidente, la decisión resuelta, el motivo y los códigos de motivo, el modo de determinismo y los campos evaluados, que para estas reglas son las rutas de ejecución de los hechos, como context.run.tools.payment_submit.numericSums.amount. La decisión recae en la ruta existente de auditoría, desencadenante de incidentes y evidencia.

Esa reutilización es importante para su revisión. En el seguimiento de auditoría, una cadena bloqueada se lee como cualquier otra acción bloqueada: un actor, una puerta, una versión de política, una regla, un código de motivo como run_chain_repeated_low_value y un resultado de terminal, unidos a la ejecución mediante el identificador de ejecución. Un auditor que ya puede verificar una decisión por llamada puede verificar una decisión en cadena con el mismo procedimiento, y los números que la regla evaluó (doce llamadas, un total de 4620, un máximo por llamada de 480) están presentes en el contexto de la decisión sin ninguna carga útil de pago sin procesar junto a ellos.

Cuando el resultado es require_approval, la solicitud de decisión muestra al revisor la regla coincidente, el motivo y los hechos agregados que cruzaron el umbral, y la aprobación o el rechazo se vincula a esa solicitud a través del flujo estándar. La exportación de evidencia sellada contiene entonces el arco completo: los permisos por llamada que admitieron cada hecho, la decisión del punto de control que captó la composición, la decisión humana donde se requirió y el estado terminal de la ejecución.

Asignación de ejemplos a categorías de amenazas agentes de OWASP¶

El [OWASP Top 10 para aplicaciones agentes, versión 2026] (https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) nombra las clases de amenazas que abordan estos controles. La guía de pruebas y controles en tiempo de ejecución asigna las diez categorías a los controles del KLA, y el cruce peatonal de la Ley de IA de la UE las asigna a artículos reglamentarios. La siguiente tabla coloca solo las detecciones a nivel de ejecución en ese marco.

Límites de la versión 1¶

La implementación enviada establece sus límites y un ingeniero de seguridad debe diseñar en torno a ellos. Las reglas evalúan recuentos, identificadores y agregados numéricos declarados; La versión 1 no retiene ni infiere el orden de las llamadas, por lo que se activa una regla de coocurrencia si la lectura secreta ocurrió antes o después del envío externo. Para un control de exfiltración esa asimetría es aceptable porque ambos órdenes merecen revisión. Las reglas no inspeccionan cargas útiles sin procesar, razonamiento de modelos ni puntuaciones de anomalías estadísticas.

Los hechos viven en el estado actual del flujo de trabajo temporal. No existe un almacén ordenado de eventos de acción duraderos, ni inferencia de predecesores ni correlación entre ejecuciones independientes, por lo que una cadena dividida en dos ejecuciones evade un punto de control de una sola ejecución. Un punto de control sólo ve las llamadas completadas antes de esa puerta; una llamada consecuente realizada después del último punto de control de una ejecución se rige únicamente por sus puertas por llamada y salida. La ubicación de la ruta queda en manos del autor del flujo de trabajo.

La adopción de producción requiere tres pasos controlados por los inquilinos: declaraciones de registro para las herramientas gobernadas reales, una versión de política de inquilinos publicada que contiene las reglas generadas y un flujo de trabajo policy_gate colocado después del paso del agente relevante. La ruta del código y sus accesorios deterministas se envían en la plataforma; los umbrales y los resultados son decisiones de gobernanza que cada inquilino toma según su propio apetito de riesgo.