Qué incluir en la Description de un asset y en Additional information
Last updated: October 26, 2026
El contexto le da al agente de IA de Strike la información específica de tu empresa que no puede inferir por sí solo. Todo lo que el agente ya sabe por su entrenamiento es ruido, y el ruido diluye los resultados.
Hay dos lugares donde cargas contexto:
Description, en el asset: describe qué es el asset y cómo funciona. Vale para todas las Threat Emulations que lo incluyen.
Additional information, en la Threat Emulation: detalles que aplican solo a esa Threat Emulation.
Por qué importa lo que incluyes
El agente conoce OWASP, PCI DSS, las técnicas de escalación de privilegios y cómo probar la autenticación. Ese conocimiento ya está incorporado: no necesitas explicárselo.
Lo que el agente no conoce es la arquitectura de tu empresa: qué puede hacer cada rol de usuario, qué módulos de negocio tienen lógica crítica o qué regulación específica aplica a tu industria.
Un contexto bien construido produce objetivos de testing focalizados en lo que es único de tu sistema. Un contexto con ruido hace que el agente pierda foco en lo que realmente importa.
Lo que no necesitas incluir
No repitas conocimiento de pentest estándar. Si lo puedes encontrar en cualquier guía de OWASP o en un curso de seguridad, el agente ya lo sabe.
Omite lo que el agente ya sabe:
OWASP Top 10 / OWASP API Top 10
Checklists de autenticación y sesiones
Listados de SQLi, XSS, SSRF, etc.
La descripción de qué es PCI DSS o ISO 27001
El formato de reporte y la estructura de hallazgos
La metodología genérica de pentest
Incluir todo esto agrega información que el agente no necesita. Un detalle curado sobre lo que importa produce un contexto de mayor calidad, y también mejores objetivos de testing.
Lo que sí tiene que estar
La regla es simple: si no está en el contexto, el agente no lo puede inferir.
En la Description del asset
Qué hace el asset: su propósito y sus flujos principales.
Módulos de negocio: los módulos propios de tu sistema con su lógica específica: flujos de aprobación, límites financieros, cadenas de autorización, operaciones que involucran dinero real.
Datos sensibles: qué tipo de información maneja el asset.
Regulaciones aplicables: solo las que aplican realmente a tu caso. No listes todas las que existen; indica cuáles son obligatorias y por qué (industria, país, tipo de dato).
Multi-tenancy: si la plataforma sirve a múltiples empresas o clientes, indícalo. El aislamiento entre tenants es uno de los vectores más críticos y requiere contexto específico.
Entorno y operaciones reales: si el asset es productivo y ejecuta transacciones reales, y qué partes no se pueden tocar. Ver el caso especial más abajo.
En la Description de un asset de infraestructura
Si el asset es una IP de tu infraestructura, el agente usa el contexto para orientar el ataque. Incluye:
Rol del host: para qué se usa, por ejemplo servidor de correo, gateway de VPN o servidor de base de datos.
Tipo de equipo: por ejemplo servidor Windows o Linux, appliance de borde (VPN, firewall, gateway) o equipo de red.
Documentación técnica: adjunta la que tengas sobre el host o la red, por ejemplo diagramas de arquitectura.
En Additional information de la Threat Emulation
Flujos críticos que cruzan varios assets de la Threat Emulation.
El foco o las aclaraciones que aplican solo a esa Threat Emulation.
Algo que queda fuera de scope solo en esa Threat Emulation.
Lo que tiene su propio campo
Algunas cosas no van en el texto, porque tienen un lugar específico en la plataforma:
Qué | Dónde se configura |
|---|---|
Usuarios y contraseñas, cookies o headers de prueba | En las credenciales del asset. |
Horarios en los que no se puede testear | En Schedule restrictions, dentro de las restricciones de la Threat Emulation. |
Tests que no quieres que se ejecuten | En Exclude tests, dentro de las restricciones de la Threat Emulation. |
IPs de Strike en tu firewall o WAF | Se autorizan de tu lado. Consulta Cómo autorizar las IPs de Strike. |
Caso especial: producción con operaciones reales
Si el asset es productivo y ejecuta transacciones reales (PIX, pagos, transferencias), indícalo explícitamente en su Description y aclara si existe un entorno sandbox. Sin esta aclaración, el agente puede ejecutar operaciones con impacto financiero real durante el testing.
Incluye cuando hay dinero real en juego:
Entorno: producción, staging o sandbox. Si es producción, confírmalo explícitamente.
Operaciones reales: si los módulos financieros ejecutan transacciones reales o simuladas, y si el proveedor de pagos tiene un modo de prueba.
Fuera de scope: qué no se puede tocar. Es tan importante como el scope: sin límites definidos, el agente no tiene un ancla para detenerse.
Si algo queda fuera de scope solo en una Threat Emulation puntual, indícalo en su Additional information.
Checklist rápido
Antes de confirmar, verifica que tengas:
En la Description: las acciones y permisos concretos de cada rol.
En la Description: los módulos de negocio con su lógica específica.
En la Description: las regulaciones que aplican y por qué.
En la Description: si hay producción, la aclaración sobre operaciones reales y el fuera de scope.
En las credenciales: un usuario de prueba por cada rol.
En las restricciones de la Threat Emulation: los horarios y tests excluidos, si aplican.
En Additional information: lo que aplica solo a esa Threat Emulation.