Créditos: o que são e como são consumidos
Last updated: October 19, 2026
O seu plano da Strike é medido em créditos. Cada execução consome créditos do seu plano. Quantos ela consome depende do tipo de testing que você configurou.
Tipos de testing e como cada um consome
Ao configurar uma Threat Emulation, você escolhe entre três tipos de testing. Todos consomem créditos do mesmo plano:
Tipo de testing | O que faz | Como consome créditos |
|---|---|---|
Full security | Testa toda a superfície incluída no scope, com a recorrência que você configurou | De acordo com os paths em scope, a profundidade e a quantidade de execuções por ano |
Focused | Faz uma execução pontual sobre um alvo específico | Um valor fixo por execução |
Change-based | É executada automaticamente quando há mudanças no seu repositório | Um valor fixo por cada execução disparada por um PR ou um release |
Full security
O consumo é calculado com três variáveis:
Paths em scope × profundidade × execuções por ano
Paths em scope: a quantidade de paths incluídos na Threat Emulation. Se você excluir paths, o consumo diminui.
Profundidade: Medium multiplica por 1 e Deep multiplica por 2.
Execuções por ano: dependem da recorrência. Mensal equivale a 12 execuções por ano, trimestral a 4 e semestral a 2. Com a recorrência desativada, é uma única execução.
Exemplo: uma Threat Emulation com 40 paths em scope, profundidade Deep e recorrência trimestral consome 40 × 2 = 80 créditos por execução, ou seja, 320 créditos por ano.
Human hacking. Se você ativar o switch Human hacking, cada execução soma uma revisão humana (human review), que tem um valor fixo em créditos. Esse valor é multiplicado pela quantidade de execuções por ano. Por exemplo, com recorrência mensal, em How it is calculated você verá × 12 human reviews.
Focused
Uma Focused Threat Emulation é executada uma única vez, não é recorrente. Cada execução Focused consome um valor fixo de créditos, do mesmo plano que o restante das suas Threat Emulations.
Change-based
Em uma Change-based Threat Emulation, cada mudança no seu repositório dispara uma execução de acordo com o trigger que você configurou: por cada PR ou por cada release.
Cada execução consome um valor fixo de créditos, que é o mesmo para PR e para release. Não depende do tamanho da mudança: um PR pequeno e um grande consomem o mesmo. Ao configurá-la, a plataforma mostra esse valor por execução.
Por isso, o consumo total em um período depende de quantos PRs ou releases são gerados no seu repositório. Os créditos saem do mesmo plano que o restante das suas Threat Emulations, não de um saldo separado.
Outros módulos e serviços
Além das Threat Emulations, estes módulos e serviços também consomem créditos do seu plano:
Strike Cloud: ao ativar o módulo, uma quantidade de créditos é descontada uma vez por ano.
Projects: ao cotar cada projeto, a equipe da Strike informa quantos créditos ele vai consumir.
Onde ver seus créditos
Ao configurar uma Threat Emulation. Enquanto você define o scope, o tipo de testing, a profundidade e a recorrência, a plataforma mostra uma estimativa de consumo que é recalculada a cada mudança. Em How it is calculated você pode ver o detalhe do cálculo.

Na seção do seu plano, em Settings. Lá você vê:
O total de créditos do seu plano e as datas de vigência.
Os créditos disponíveis, os projetados (o que já está programado) e os consumidos.
O consumo detalhado por tipo de testing ou por Threat Emulation.

Quando são consumidos
Nas Threat Emulations, os créditos são consumidos quando o agente de IA da Strike inicia a execução. Criar ou configurar uma Threat Emulation não consome créditos.
Ação | Consome créditos? |
|---|---|
Execução programada de Full security | Sim |
Human hacking ativado | Sim, uma human review por execução |
Execução adicional fora da recorrência | Sim |
Execução Focused | Sim |
Execução Change-based | Sim |
Execução cancelada | Sim |
Ativação do Strike Cloud | Sim, uma vez por ano |
Projects | Sim, de acordo com a cotação de cada projeto |
Pre-flight Check | Não |
Retest automático | Não |
O que acontece se você ficar sem créditos
Se o seu plano ficar sem créditos, as Threat Emulations são pausadas automaticamente e a plataforma exibe uma mensagem. Para retomar o testing, entre em contato com o seu CSM para adicionar créditos ao seu plano.
Perguntas frequentes
Por que uma Threat Emulation consome mais créditos que outra?
Depende do tipo de testing. Em Full security, o consumo depende da quantidade de paths em scope, da profundidade, da recorrência e se o Human hacking está ativado. Em uma Change-based Threat Emulation, depende de quantos PRs ou releases disparam execuções.
Como posso reduzir o consumo?
Em Full security, você pode excluir paths do scope, escolher a profundidade Medium ou usar uma recorrência menos frequente. As mudanças se aplicam a partir da próxima execução.
Uma Change-based Threat Emulation tem créditos próprios?
Não. Ela consome do mesmo plano que o restante das suas Threat Emulations.
O Pre-flight Check consome créditos?
Não. Os créditos só são consumidos quando a execução começa.
Se eu cancelar uma execução, recupero os créditos?
Não. Os créditos de uma execução cancelada são consumidos mesmo assim. Para mais detalhes, consulte Como pausar uma Threat Emulation ou cancelar uma execução.