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 de este artículo 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: demostrar el riesgo, no causarlo. El agente busca evidencia suficiente para confirmar una vulnerabilidad, no para explotarla más allá de eso.

• Solo lectura por defecto: nunca modifica, elimina ni persiste datos en producción. Cuando una vulnerabilidad requiere acción para ser confirmada, el agente lo documenta como hallazgo sin ejecutar la acción destructiva.

• 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 en pentests whitebox, donde se le entregan credenciales de prueba, 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 tu asset, dentro de los límites del scope autorizado:

• Reconocimiento y enumeración: identifica superficies expuestas, endpoints, parámetros, 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: una vez detectada una vulnerabilidad, el agente busca confirmar su existencia con la mínima evidencia necesaria. Si se trata de un acceso indebido, registra que el acceso es posible, no extrae el dato.

• 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 — pero únicamente como técnica de detección, no como objetivo final.

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, no abusar del acceso.

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 en el curso de un test 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, no descarga ni extrae datos reales de otros clientes.

No destruye ni modifica datos en producción

El agente tiene prohibido 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 claramente delimitado por el asset configurado, las restrictions definidas y los repos vinculados (en el caso de Change-Based Tests). El agente no se mueve a:

• Otros assets no autorizados, aunque sean accesibles desde el asset bajo test.

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

• URLs o endpoints excluidos explícitamente en las restrictions del asset.

No persiste acceso

El agente no instala backdoors, no crea usuarios nuevos con privilegios elevados, no deja webshells, no mantiene sesiones activas más allá del tiempo de ejecución. Cada threat emulation 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, etc.).

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

• Scope técnico configurado por asset: las restrictions, credenciales y archivos que configuras a nivel asset 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. Esto 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 tab Trace dentro de cada threat emulation muestra el log completo de las acciones del agente: qué endpoints tocó, qué payloads envió, qué respuestas recibió, qué decisiones tomó.

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

• PRs cubiertos (Change-Based): en ejecuciones change-based, la tab PRs tested detalla exactamente qué cambios del código se incluyeron en el scope.

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 que confiemos 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 aquellas necesarias para mantener su propia sesión (por ejemplo, registrar una cuenta de prueba) o cuando se le solicita explícitamente que valide un flujo específico en un Focused Test.

• 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é restrictions 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.

• 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 un test?

No. El agente tiene prohibido cualquier acción destructiva sobre datos productivos. Si durante un test 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 tu asset durante el test, lo que en algunos casos puede implicar consumo de servicios. Esto está acotado por las restrictions del asset (rate limits, endpoints excluidos, ventanas de tiempo permitidas). Si tu asset depende de servicios externos pagos sensibles al volumen, configura las restrictions correspondientes en la configuración del asset.

¿Qué pasa si el agente afecta la disponibilidad de mi asset durante un test?

El agente está diseñado para minimizar 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 durante un test, puedes pausar la ejecución desde la plataforma y contactar a tu Customer Success Manager para revisar el incidente.

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

Tú. Strike no descubre ni testea assets que no hayas configurado explícitamente. 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 y revisa la tab Trace. Vas a ver el log completo de acciones del agente: endpoints accedidos, payloads enviados, respuestas recibidas y decisiones tomadas. Para hallazgos específicos, cada uno incluye los pasos exactos de reproducción.