Qué incluir en el contexto de un asset
Last updated: June 25, 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.
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 —y unos objetivos— de mayor calidad.
Lo que sí tiene que estar
La regla es simple: si no está en el contexto, el agente no lo puede inferir.
Incluye la información específica de tu organización:
Roles y permisos: cada rol de usuario con sus acciones concretas: qué puede ver, crear, modificar y ejecutar. Nada de nombres genéricos: qué hace este Admin en esta aplicación.
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.
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).
Cuentas de prueba: un usuario real por cada rol a evaluar. Si las credenciales van por separado, indica en el contexto que están disponibles y bajo qué nombre.
Restricciones operativas: si el scope es producción, si hay transacciones reales en juego, los horarios permitidos o si existe un bypass de WAF para las IPs de prueba.
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.
Ejemplo anotado
El mismo contexto, con cada parte clasificada según si aporta o no.
Fragmento del contexto | Clasificación |
|---|---|
| Ruido |
| Ruido |
| Ruido |
| Señal |
| Ruido |
| Señal |
| Contexto útil |
| Señal |
| Ruido |
Caso especial: producción con operaciones reales
⚠ Si el scope incluye producción con transacciones reales (PIX, pagos, transferencias), tienes que indicarlo explícitamente en el contexto y confirmar si existe un entorno sandbox. Sin esta aclaración, el agente puede ejecutar operaciones con impacto financiero real durante el test.
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.
Checklist rápido
Antes de enviar el contexto, verifica que tenga lo siguiente:
Un usuario de prueba por cada rol
Las acciones y permisos concretos de cada rol
Los módulos de negocio con su lógica específica
El out-of-scope definido explícitamente
Las regulaciones que aplican y por qué
Si hay producción: la aclaración sobre operaciones reales
Las restricciones de horario o de WAF, si aplican