Cómo opera el agente de IA de Strike sobre tus assets: alcance, límites y controles

El agente de IA de Strike es el agente que ejecuta las Threat Emulations sobre tus assets. Este artículo explica cómo está diseñado para operar de forma segura en entornos productivos, qué puede hacer, qué no puede hacer y qué controles existen para auditar su comportamiento.

El objetivo es darte visibilidad completa sobre cómo el agente interactúa con tus sistemas, para que puedas presentar Strike internamente con confianza ante equipos de seguridad, compliance y leadership.

Principios de operación

El agente de IA opera bajo cuatro principios que guían cada decisión que toma durante una ejecución:

• Mínimo impacto: el agente busca evidencia suficiente para confirmar una vulnerabilidad utilizando, por defecto, la mínima evidencia necesaria. Cuando el cliente lo autoriza explícitamente, Strike puede realizar una explotación controlada para validar el impacto real del hallazgo.

• Solo lectura por defecto: nunca modifica, elimina ni persiste datos en producción como comportamiento predeterminado. Cuando una validación requiere acciones adicionales, estas solo se realizan con autorización explícita del cliente y dentro del alcance definido.

• Scope estricto: opera únicamente sobre los assets que tú autorizas. No se mueve lateralmente hacia sistemas adyacentes ni accede a recursos fuera del scope definido.

• Postura de atacante externo: salvo cuando configuras credenciales de prueba para testear lo que está detrás del login, el agente actúa como un atacante externo sin privilegios previos. Solo accede a lo que cualquier actor externo podría ver desde fuera de tu organización.

Qué hace el agente de IA

El agente ejecuta las técnicas que un pentester profesional aplicaría sobre tus assets, dentro de los límites del scope autorizado:

• Reconocimiento y enumeración: identifica superficies expuestas, endpoints, parámetros y comportamientos del asset.

• Detección de vulnerabilidades: prueba vectores de ataque comunes (OWASP Top 10, fallas de lógica de negocio, IDOR, broken access control, inyecciones, fallas de autenticación, entre otros).

• Validación de impacto: por defecto, el agente demuestra que el acceso es posible sin extraer datos. Cuando el cliente lo autoriza explícitamente, Strike puede realizar una explotación controlada para validar el impacto real.

• Documentación con evidencia: cada hallazgo queda registrado con los pasos seguidos, el payload utilizado y la evidencia mínima que prueba la vulnerabilidad.

Sobre la escalación de privilegios

Sí, el agente puede intentar escalar privilegios cuando es necesario para validar el impacto real de una vulnerabilidad, siempre dentro del alcance autorizado y con el menor impacto posible.

Cierta familia de vulnerabilidades (como IDOR, broken access control o fallas de privilegios) solo puede confirmarse probando con múltiples contextos de usuario. Decir "este endpoint parece vulnerable" no es lo mismo que demostrar "este usuario puede acceder a datos del rol X". Por eso el agente puede intentar escalar privilegios cuando es la única forma de cuantificar el impacto real del hallazgo.

Lo que el agente nunca hace con los privilegios que obtiene:

• Usar el acceso obtenido para moverse lateralmente hacia sistemas fuera del scope.

• Acceder a recursos que no estén explícitamente autorizados.

• Persistir el acceso, instalar puertas traseras o mantener sesiones activas más allá de la ejecución.

El objetivo siempre es demostrar el riesgo con el menor impacto posible, no abusar del acceso ni exceder el alcance autorizado.

Qué nunca hace el agente de IA

Estos comportamientos están explícitamente prohibidos en las reglas que gobiernan al agente y forman parte del diseño del sistema.

No accede a cuentas de otros clientes en producción

En plataformas multi-tenant, el agente tiene explícitamente fuera de scope cualquier dato o cuenta que pertenezca a otros clientes o tenants. Esto está garantizado por varias capas:

• El agente opera como un atacante externo sin privilegios previos. Trabaja con cuentas que él mismo registra durante la ejecución, o con cuentas de prueba que tu equipo le provee. No utiliza, ni tiene forma de utilizar, cuentas reales de otros usuarios de tu plataforma.

• En sus reglas de operación, el acceso a cuentas o datos de otros clientes está marcado como un límite duro: el agente no tiene autorización para intentarlo, aunque técnicamente fuera posible.

• Si durante una ejecución detecta una vulnerabilidad que podría permitir acceso a datos de terceros (por ejemplo, un IDOR que expone registros de otros usuarios), el agente documenta la existencia del problema con evidencia mínima. Típicamente confirma que el endpoint es vulnerable y obtiene un registro o un conteo, pero no descarga ni extrae datos reales de otros clientes.

No destruye ni modifica datos en producción

El agente tiene prohibida cualquier acción destructiva sobre datos productivos:

• No elimina registros, archivos ni configuraciones.

• No modifica datos existentes (no edita registros de otros usuarios, no cambia configuraciones del sistema, no altera el estado de transacciones).

• No envía emails, notificaciones ni acciones reales en nombre de usuarios reales.

• No realiza transacciones financieras ni operaciones con efectos económicos.

Cuando una vulnerabilidad teórica requeriría una acción destructiva para confirmarse, el agente documenta el hallazgo con la evidencia que tenga hasta el punto previo a la acción destructiva, y deja constancia de por qué la acción no se completó.

No se mueve fuera del scope autorizado

Cada Threat Emulation tiene un scope delimitado por los assets que incluye, las restricciones que defines y, en una Change-based Threat Emulation, los repositorios vinculados. El agente no se mueve a:

• Otros assets que no estén incluidos en la Threat Emulation, aunque sean accesibles desde un asset en scope.

• Sistemas adyacentes (bases de datos, servicios internos, redes corporativas) que estén accesibles desde el asset.

No persiste acceso

El agente no instala backdoors, no crea usuarios nuevos con privilegios elevados, no deja webshells y no mantiene sesiones activas más allá del tiempo de ejecución. Cada ejecución es un evento autocontenido que comienza y termina en una ventana de tiempo definida.

No expone PII en los reportes

Cuando una vulnerabilidad involucra datos personales o sensibles, el agente enmascara la PII antes de incluir la evidencia en el reporte. Lo que aparece en el reporte es prueba de que el acceso fue posible, no los datos reales.

Cómo se controla y audita el comportamiento del agente

El agente de IA no es una caja negra. Su comportamiento está controlado por múltiples capas y queda registrado de punta a punta.

Capas de control

• Reglas de operación (system rules): el agente opera bajo un conjunto explícito de reglas que definen qué puede y qué no puede hacer. Incluye los límites duros mencionados arriba (no tocar cuentas de otros clientes, no destruir datos, no salir del scope, entre otros).

• Capa de ética: una capa adicional que aplica principios transversales: solo lectura por defecto, minimización de impacto y protección de PII.

• Scope técnico configurado: los assets que incluyes en la Threat Emulation, sus credenciales y documentación técnica, y las restricciones que defines acotan el espacio en el que el agente puede operar.

• Triage humano: todo hallazgo del agente de IA pasa por triage del equipo de Strike antes de ser publicado, y el 100% de los hallazgos críticos además se reproduce y valida manualmente. El triage incluye validar que el agente operó dentro del scope acordado y que la evidencia recolectada es proporcional al hallazgo.

Trazabilidad completa

Cada ejecución queda registrada con:

• Traces de cada paso: la pestaña Trace dentro de cada ejecución muestra el log completo de las acciones del agente: qué endpoints tocó, qué payloads envió, qué respuestas recibió y qué decisiones tomó.

• Evidencia por hallazgo: cada vulnerabilidad reportada incluye los pasos exactos para reproducirla, con request/response y payload utilizado.

• PRs cubiertos: en una Change-based Threat Emulation, la pestaña PRs tested de cada ejecución detalla exactamente qué cambios del código se incluyeron.

Esto significa que, si tu equipo de seguridad o compliance pregunta "¿qué hizo exactamente el agente sobre el asset?", la respuesta está en el trace de la ejecución. No requiere confiar en lo que el agente dice haber hecho.

Cómo presentar esto a tu equipo de seguridad

Si tu equipo interno te pide garantías sobre cómo opera Strike sobre tus sistemas productivos, los puntos clave a transmitir son:

• Postura de atacante externo: el agente actúa con los privilegios mínimos necesarios, sin acceso especial.

• Solo lectura por defecto: nunca modifica datos productivos. Las únicas acciones de escritura que ejecuta son las necesarias para mantener su propia sesión (por ejemplo, registrar una cuenta de prueba), cuando se le pide explícitamente que valide un flujo específico en una Focused Threat Emulation, o cuando el cliente autoriza explícitamente una explotación controlada como parte de la validación.

• Cuentas de otros clientes fuera de scope: explícito en las reglas del agente y reforzado por la postura de atacante externo.

• Scope acotado y controlable: tú defines qué assets, qué restricciones y qué credenciales. El agente no se mueve fuera de eso.

• Triage humano del equipo de Strike: ningún hallazgo se publica sin validación humana, y los hallazgos críticos además se reproducen manualmente.

• Trazabilidad total: cada acción queda registrada y es auditable desde la plataforma.

Preguntas frecuentes

¿Strike puede borrar datos de mi base de datos durante una ejecución?

No. El agente tiene prohibida cualquier acción destructiva sobre datos productivos. Si durante una ejecución se detecta una vulnerabilidad que podría permitir borrado de datos (por ejemplo, un endpoint vulnerable a inyección SQL con DELETE), el agente documenta el hallazgo con la evidencia previa a la acción destructiva. Nunca ejecuta el borrado.

Si el agente encuentra un IDOR que permite ver datos de otros clientes, ¿qué hace?

Documenta la existencia del IDOR con la evidencia mínima necesaria para confirmar el hallazgo: típicamente un registro o un conteo que prueba que el acceso es posible. No descarga ni extrae datos reales de otros clientes. La PII que pudiera aparecer en esa evidencia mínima queda enmascarada en el reporte.

¿El agente puede generar costos en mi cuenta (por ejemplo, llamadas a APIs pagas)?

El agente puede generar tráfico hacia tus assets durante una ejecución, lo que en algunos casos puede implicar consumo de servicios. Ese tráfico queda acotado por las restricciones de la Threat Emulation (rate limit, restricciones horarias y tipos de test excluidos). Si tu asset depende de servicios externos pagos sensibles al volumen, configura las restricciones correspondientes en la Threat Emulation.

¿Qué pasa si el agente afecta la disponibilidad de mi asset durante una ejecución?

El agente está diseñado para minimizar el impacto sobre la disponibilidad: respeta rate limits, evita técnicas que generen DoS y prioriza profundidad sobre volumen. Si aun así detectas un problema de disponibilidad, puedes detener la ejecución en curso con Cancel execution y contactar a tu Customer Success Manager para revisar el incidente. Para más detalle, consulta Cómo pausar una Threat Emulation o cancelar una ejecución.

¿Quién decide qué assets y qué scope?

Tú. Strike solo testea los assets que incluyes en tus Threat Emulations. El scope de cada Threat Emulation está definido por la configuración que tu equipo carga en la plataforma.

¿Cómo puedo auditar lo que hizo el agente en una ejecución específica?

Abre la Threat Emulation, entra a la ejecución desde la pestaña Executions y revisa la pestaña Trace. Vas a ver el log completo de acciones del agente: endpoints accedidos, payloads enviados, respuestas recibidas y decisiones tomadas. Además, cada hallazgo incluye los pasos exactos de reproducción.