Créditos: qué son y cómo se consumen
Last updated: October 26, 2026
Tu plan de Strike se mide en créditos. Cada ejecución consume créditos de tu plan. Cuántos consume depende del tipo de testing que configuraste.
Tipos de testing y cómo consume cada uno
Al configurar una Threat Emulation eliges entre tres tipos de testing. Todos consumen créditos del mismo plan:
Tipo de testing | Qué hace | Cómo consume créditos |
|---|---|---|
Full security | Testea toda la superficie incluida en el scope, con la recurrencia que configuraste | Según los paths en scope, la profundidad y la cantidad de ejecuciones por año |
Focused | Hace una ejecución puntual sobre un objetivo específico | Un valor fijo por ejecución |
Change-based | Se ejecuta automáticamente cuando hay cambios en tu repositorio | Un valor fijo por cada ejecución que dispara un PR o un release |
Full security
El consumo se calcula con tres variables:
Paths en scope × profundidad × ejecuciones por año
Paths en scope: la cantidad de paths incluidos en la Threat Emulation. Si excluyes paths, el consumo baja.
Profundidad: Medium multiplica por 1 y Deep multiplica por 2.
Ejecuciones por año: dependen de la recurrencia. Mensual equivale a 12 ejecuciones por año, trimestral a 4 y semestral a 2. Con la recurrencia desactivada, es una sola ejecución.
Ejemplo: una Threat Emulation con 40 paths en scope, profundidad Deep y recurrencia trimestral consume 40 × 2 = 80 créditos por ejecución, es decir 320 créditos por año.
Human hacking. Si activas el switch Human hacking, cada ejecución suma una revisión humana (human review), que tiene un valor fijo en créditos. Ese valor se multiplica por la cantidad de ejecuciones por año. Por ejemplo, con recurrencia mensual, en How it is calculated verás × 12 human reviews.
Focused
Una Focused Threat Emulation se ejecuta una sola vez, no es recurrente. Cada ejecución Focused consume un valor fijo de créditos, del mismo plan que el resto de tus Threat Emulations.
Change-based
En una Change-based Threat Emulation, cada cambio en tu repositorio dispara una ejecución según el trigger que configuraste: por cada PR o por cada release.
Cada ejecución consume un valor fijo de créditos, que es el mismo para PR y para release. No depende del tamaño del cambio: un PR chico y uno grande consumen lo mismo. Al configurarla, la plataforma te muestra ese valor por ejecución.
Por eso, el consumo total en un período depende de cuántos PR o releases se generen en tu repositorio. Los créditos salen del mismo plan que el resto de tus Threat Emulations, no de una bolsa aparte.
Threat Emulations de infraestructura
En una Threat Emulation de infraestructura, cada IP en scope consume 85 créditos por ejecución:
IPs en scope × 85 créditos × ejecuciones por año
Se cuentan todas las IPs incluidas en la Threat Emulation. Si activas Human hacking, cada ejecución suma una human review, igual que en Full security.
Ejemplo: una Threat Emulation con 3 IPs y recurrencia trimestral consume 3 × 85 = 255 créditos por ejecución, es decir 1.020 créditos por año.
Para más detalle, consulta Qué es una Threat Emulation de infraestructura.
Otros módulos y servicios
Además de las Threat Emulations, estos módulos y servicios también consumen créditos de tu plan:
Strike Cloud: al activar el módulo se descuenta una cantidad de créditos una vez por año.
Projects: al cotizar cada proyecto, el equipo de Strike te indica cuántos créditos va a consumir.
Dónde ver tus créditos
Al configurar una Threat Emulation. Mientras defines el scope, el tipo de testing, la profundidad y la recurrencia, la plataforma muestra una estimación de consumo que se recalcula con cada cambio. En How it is calculated puedes ver el detalle del cálculo.
En la sección de tu plan, en Settings. Ahí ves:
El total de créditos de tu plan y las fechas de vigencia.
Los créditos disponibles, los proyectados (lo que ya está programado) y los consumidos.
El consumo desglosado por tipo de testing o por Threat Emulation.
Cuándo se consumen
En las Threat Emulations, los créditos se consumen cuando el agente de IA de Strike empieza la ejecución. Crear o configurar una Threat Emulation no consume créditos.
Acción | ¿Consume créditos? |
|---|---|
Ejecución programada de Full security | Sí |
Human hacking activado | Sí, una human review por ejecución |
Ejecución adicional fuera de la recurrencia | Sí |
Ejecución Focused | Sí |
Ejecución Change-based | Sí |
Ejecución de una Threat Emulation de infraestructura | Sí, 85 créditos por IP |
Ejecución cancelada | Sí |
Activación de Strike Cloud | Sí, una vez por año |
Projects | Sí, según la cotización de cada proyecto |
Pre-flight Check | No |
Retest automático | No |
Qué pasa si te quedas sin créditos
Si tu plan se queda sin créditos, las Threat Emulations se pausan automáticamente y la plataforma muestra un mensaje. Para retomar el testing, contacta a tu CSM para sumar créditos a tu plan.
Preguntas frecuentes
¿Por qué una Threat Emulation consume más créditos que otra?
Depende del tipo de testing. En Full security, el consumo depende de la cantidad de paths en scope, la profundidad, la recurrencia y si tiene Human hacking activado. En una Change-based Threat Emulation, depende de cuántos PR o releases disparan ejecuciones.
¿Cómo puedo reducir el consumo?
En Full security puedes excluir paths del scope, elegir profundidad Medium o usar una recurrencia menos frecuente. Los cambios aplican desde la próxima ejecución.
¿Una Change-based Threat Emulation tiene créditos propios?
No. Consume del mismo plan que el resto de tus Threat Emulations.
¿El Pre-flight Check consume créditos?
No. Los créditos se consumen recién cuando empieza la ejecución.
Si cancelo una ejecución, ¿recupero los créditos?
No. Los créditos de una ejecución cancelada se consumen igual. Para más detalle, consulta Cómo pausar una Threat Emulation o cancelar una ejecución.