Skyhawk Security (Purple Team Autônomo com IA Agentica)

Nota do Capítulo 17, pasta de Purple Teaming Autônomo com IA.
Analisa a proposta da Skyhawk Security de purple team autônomo para nuvem, no qual agentes de IA validam controles continuamente e priorizam caminhos de ataque reais.
Dialoga com as notas de AutoPT e de Continuous Purple Teaming da mesma pasta e com os controles SIM, INS e DAT do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

A biblioteca tratou simulação de ataques nos controles SIM do capítulo 15, com plataformas de ataque gerenciado, emulação de adversários e exercícios purple team conduzidos por pessoas. Esta nota apresenta a evolução proposta pela Skyhawk Security, empresa especializada em segurança de nuvem, que emprega IA agêntica para executar um purple team autônomo em ambientes cloud. A proposta desloca o esforço de validar controles do ritmo dos testes pontuais para um ciclo contínuo, no qual agentes de IA simulam o comportamento do adversário contra o ambiente real, observam como os controles respondem e devolvem lacunas priorizadas ao time de segurança.

O posicionamento na biblioteca é o de exemplo concreto de uma tendência maior descrita nesta pasta, a substituição de campanhas de teste manuais por agentes que rodam em loop. Enquanto a nota de AutoPT aplica a ideia à superfície de LLMs e a nota de Continuous Purple Teaming generaliza o pipeline de validação para detecções tradicionais, a Skyhawk concentra o conceito no espaço de nuvem, onde identidades, configurações e exposições mudam com velocidade que testes trimestrais não acompanham. Para o leitor da biblioteca, o caso ilustra como dados já coletados por plataformas cloud viram insumo de simulação e de priorização.

Para o leitor, a lição central não é o nome da empresa, e sim o padrão arquitetural que a proposta empacota. Dados de postura e de permissão viram grafo de caminho, o grafo vira simulação, a simulação vira evidência e a evidência vira fila de correção priorizada. Qualquer organização pode montar essa cadeia com ferramentas distintas, e a nota descreve o padrão de forma agnóstica de produto, usando a Skyhawk como caso concreto de referência.

2. O Problema que a Proposta Ataca

Ambientes de nuvem acumulam três fontes de risco que evoluem em ritmo semanal ou diário. Configurações mudam a cada deploy, permissões de identidade se acumulam conforme equipes criam papéis e contas de serviço, e novas exposições aparecem quando recursos ganham acesso público ou federam com identidades externas. Ferramentas de postura, como CSPM (Cloud Security Posture Management), listam centenas ou milhares de misconfigurations, mas a lista diz pouco sobre explotabilidade, porque a maioria dessas configurações não compõe um caminho que leve a dados valiosos. O resultado prático, conhecido de qualquer operação cloud madura, é o ruído: times recebem achados que não conseguem priorizar contra o risco real de intrusão.

O teste ofensivo tradicional não fecha essa lacuna por duas razões estruturais. Um pentest de nuvem acontece em uma janela de semanas, captura um retrato do ambiente naquela semana e produz relatório semanas depois, quando o ambiente já mudou. E um red team humano custa caro o suficiente para que a organização só o contrate pontualmente, o que deixa o intervalo entre testes coberto apenas por controles presumidamente funcionais. O purple team autônomo ataca exatamente esse intervalo, validando continuamente se os controles detectariam e conteriam os caminhos de ataque que o ambiente real expõe naquele momento.

O modelo econômico do problema também importa para a leitura executiva. O custo de um pentest humano pontual é alto e fixo, enquanto o custo marginal de uma simulação autônoma é baixo e recorrente, e essa diferença é o que permite revalidar após cada correção, algo inviável no modelo de eventos. A proposta da categoria entrega valor na frequência e na priorização, e não na profundidade de cada exploit individual.

3. Purple Team Autônomo com Agentes de IA

Na proposta da Skyhawk, agentes de IA assumem papéis que em um exercício tradicional caberiam a pessoas, com a vantagem de repetição e de cobertura constante. Um agente planejador constrói grafos de caminho de ataque a partir dos dados do ambiente, combinando identidades, permissões, configurações e exposições em sequências que um invasor real poderia trilhar. Um agente executor simula os passos dessas sequências contra o ambiente, em modo seguro, gerando a telemetria que o adversário real geraria. Um agente observador consulta os controles, como EDR, logs de cloud, regras de detecção e políticas de identidade, para verificar se algum deles reagiu à simulação. Um agente de análise consolida resultados, separa controles que falharam de controles que funcionaram e alimenta a fila de correção.

Três características distinguem essa execução de uma varredura automatizada comum. A simulação é orientada por caminho e não por item isolado, porque o interesse está na cadeia completa, do acesso inicial até o dado sensível. A execução é não destrutiva e controlada, com ações escolhidas para gerar telemetria equivalente à do ataque real sem causar dano, o que permite rodar contra ambiente produtivo sem janela de teste. E o ciclo é contínuo, com revalidação automática quando o ambiente muda, quando novos privilégios aparecem ou quando correções são implantadas, tornando o purple team um serviço permanente e não um evento.

O loop agêntico precisa de supervisão explícita para operar contra ambiente produtivo, e a proposta define guardrails próprios para a simulação, com ações marcadas como teste, credenciais dedicadas, orçamento de execução e proibição de payloads destrutivos. A tabela abaixo resume os estágios do loop e o que cada estágio entrega ao seguinte, na mesma lógica de ciclo da nota de AutoPT.

4. Priorização por Caminhos de Ataque Reais

O diferencial de valor da proposta está na priorização. Em vez de entregar milhares de achados de configuração, o purple team autônomo entrega caminhos, e cada caminho é uma sequência verificada que liga uma posição inicial alcançável a um ativo valioso. A priorização segue a lógica do adversário: um achado de CSPM sem caminho até dado crítico espera, enquanto um encadeamento de privilégio excessivo, papel federado e segredo exposto que termina no cofre de chaves vira o topo da fila. Essa é a mesma filosofia de priorização por explotabilidade que a biblioteca defende nos controles INS.3 e INS.4, aplicada com automação de agentes.

A tabela de critérios serve de gabarito para qualquer implantação, mesmo que a organização use outra ferramenta ou construa a própria rotina de simulação. O princípio a preservar é que o número de itens priorizados deve ser pequeno o suficiente para caber no backlog de engenharia, porque caminhos validados sem dono e sem prazo viram apenas mais uma lista, com a diferença de que agora a lista carrega evidência de explotabilidade.

Um exemplo concreto ajuda a fixar a diferença entre lista e caminho. Um bucket com permissão de leitura pública é achado de postura, e sozinho tem gravidade incerta. O mesmo bucket, quando o papel de leitura pode ser assumido por uma identidade federada com trust mal configurado, e essa identidade tem rota até o cofre de segredos, compõe um caminho com impacto real. A priorização por caminho é o que impede que a correção do primeiro item ofusque o segundo, porque a evidência de explotabilidade já vem acoplada ao achado.

5. Relação com CNAPP e CIEM

A proposta da Skyhawk não substitui as plataformas de segurança de nuvem, ela se alimenta delas. Um CNAPP (Cloud-Native Application Protection Platform) consolida visibilidade de postura, cargas de trabalho, identidades e exposição em um só lugar, e essa telemetria é a matéria-prima dos grafos de caminho de ataque. O CIEM (Cloud Infrastructure Entitlement Management) fornece o mapa de permissões efetivas, que é o componente mais difícil de obter e o mais determinante para avaliar se um caminho é real, já que privilégio excessivo de identidade é o fio condutor da maioria das intrusões em nuvem. O CSPM contribui com misconfigurations e o CWPP (Cloud Workload Protection Platform) com sinais de runtime das cargas.

A leitura correta dessa relação evita uma expectativa comum de compra de ferramenta. Sem CNAPP e CIEM saudáveis, com inventário confiável e mapeamento de permissões efetivas, o purple team autônomo simula caminhos sobre dados ruins e produz conclusões ruins. Com essas plataformas alimentando o ciclo, a simulação passa a exercitar o que os achados de postura apenas descrevem, respondendo a pergunta que a lista de misconfigurations nunca respondeu, que é se alguém de fora conseguiria realmente chegar ao dado por aquele caminho.

O mapeamento de pilares também orienta a integração técnica no ambiente do cliente. A ingestão típica consome inventário e achados via API do CNAPP e permissões efetivas via CIEM, e devolve resultados para a fila da plataforma ou para o ticket externo, com o caminho como objeto de primeiro nível. Para o arquiteto da solução, a pergunta de desenho é qual sistema detém a verdade sobre permissões efetivas, porque caminho construído sobre permissões teóricas de documento de design vira simulação de fantasia.

6. Exemplo de Ciclo de Validação

Considere um ambiente multicloud com identidade federada entre provedores e um cofre de segredos crítico. O ciclo começa com o agente planejador construindo um grafo a partir dos dados de CIEM e CSPM, no qual identifica que uma identidade de serviço com privilégio amplo pode ser assumida por uma identidade federada de menor confiança, e que essa identidade tem acesso de leitura ao cofre. O agente executor simula a sequência em modo seguro, assumindo a identidade em ambiente controlado e tentando a leitura de referência no cofre, sem copiar conteúdo, apenas suficiente para gerar os mesmos eventos de API que uma exfiltração real geraria. O agente observador verifica os controles: os logs de CloudTrail registram a chamada, mas nenhuma regra de detecção alerta, o alerta de anomalia de identidade não dispara porque a ação é rara, porém válida para o papel, e nenhuma política de identidade bloqueia a operação.

O resultado entra na fila como caminho crítico validado, com evidência, passos reproduzíveis e apontamento da lacuna de detecção, e o time de engenharia corrige restringindo a condição de trust da identidade federada e criando regra de alerta para operações de leitura em massa no cofre. Semanas depois, o ciclo revalida o mesmo caminho automaticamente, agora com o bloqueio funcionando e o alerta disparando, e o caso é encerrado com evidência de correção. Esse par de execução e revalidação, com timestamps comparáveis, é o entregável que diferencia o ciclo autônomo de um relatório pontual de assessment.

O trecho abaixo ilustra a configuração de um ciclo segmentado por criticidade, com frequência e orçamento distintos, no padrão recomendado para conter o custo de execução sem perder cobertura nos ativos que sustentam o negócio.

ciclos:
  - nome: coroa_da_empresa
    escopo: caminhos_que_tocam_dado_critico
    frequencia: diaria
    orcamento: alto
  - nome: identidades_secundarias
    escopo: caminhos_sem_dado_critico_na_ponta
    frequencia: semanal
    orcamento: medio
  - nome: exposicao_externa
    escopo: caminhos_com_ponto_de_entrada_publico
    frequencia: semanal
    orcamento: medio
  - nome: regressao_correcoes
    escopo: caminhos_corrigidos_nos_ultimos_30_dias
    frequencia: apos_cada_correcao
    orcamento: baixo

7. Métricas e Critérios de Sucesso

O programa deve ser medido por variáveis que mostrem redução de risco real e não volume de execução. A taxa de caminhos bloqueados mede a proporção de caminhos simuados em que algum controle impediu a progressão, e a taxa de caminhos detectados mede quantos, mesmo sem bloqueio, geraram alerta para o SOC. O tempo de correção de caminho crítico mede o intervalo entre a validação da lacuna e a revalidação bem-sucedida, e a tendência de caminhos abertos mostra se o ambiente melhora ou degrada ao longo dos meses. Um indicador de maturidade complementar é a razão entre caminhos críticos e total de achados de postura, que deve cair conforme o time corrige o que realmente importa.

A leitura executiva das métricas deve separar capacidade do programa de estado do ambiente. Cobertura e tempo de correção falam do programa, enquanto taxa de caminhos bloqueados e tendência de caminhos abertos falam do ambiente, e misturar as duas leituras na mesma frase gera decisões erradas, como punir o programa por caminhos que o ambiente acabou de criar com um novo deploy de identidade.

8. Limitações e Cuidados

A simulação autônoma tem limites que a comunicação executiva deve reconhecer. Agentes trilham caminhos construídos a partir dos dados que as plataformas fornecem, e permissões que o CIEM não enxerga, como papéis temporários mal controlados ou ferramentas de shadow IT, ficam fora do grafo. Simulações em modo seguro geram telemetria equivalente, mas não idêntica, e controles que dependem de comportamento fino do payload, como análise de memória ou de conteúdo, podem não ser exercitados em profundidade. E há o risco organizacional de o time tratar caminho não simulado como caminho inexistente, confusão que a seção de erros comuns retoma.

O custo operacional também merece atenção, porque cada execução consome créditos de API do provedor e atenção do time para triagem. A recomendação prática é segmentar a frequência por criticidade, com caminhos que tocam coroa da empresa revalidados diariamente e caminhos secundários em janela semanal, sempre com orçamento de execução explícito. Essa segmentação mantém o programa financeiramente sustentável e evita que a primeira fatura surpreenda quem aprovou a iniciativa.

Vale distinguir ainda simulação autônoma de red team humano em nuvem, porque a proposta cobre o meio do espectro e deixa pontas de fora. Explorações reais com impacto, evasão de defesas e criatividade de cadeia continuam dependendo de pessoas, e o programa maduro usa o autônomo como rotina de base e o humano como exploração de topo. A expectativa correta do patrocinador é cobertura contínua e priorização honesta, e não substituição de assessment.

9. Erros Comuns e Pontos de Atenção

Um cuidado final é o da comunicação com donos de negócio. Caminho de ataque é vocabulário técnico, e o relatório executivo deve traduzir cada caminho em cenário de negócio, com o dado em risco, o cenário de impacto e a correção pedida. Essa tradução é o que converte a evidência técnica em decisão de investimento, e ela segue o mesmo princípio dos relatórios de inteligência da seção 5 da biblioteca, que pedem produto diferente por público.

10. Integração com o Restante da Biblioteca

A nota dialoga primeiro com o controle SIM.3 do capítulo 15, que define o exercício purple team com equipes humanas, e esta nota mostra a variante autônoma desse exercício para nuvem, com os mesmos entregáveis de ficha de resultado e revalidação. Dialoga também com os controles INS.3 e INS.4, porque os grafos de caminho dependem do inventário e do monitoramento de exposição que esses controles exigem, e com o grupo DAT, já que a observação de simulações depende da coleta de logs de cloud e de identidade. Para o leitor que vem do capítulo 08, os caminhos de nuvem são a extensão natural das técnicas de hunting em cloud e SaaS, agora exercitadas ofensivamente de forma contínua.

Em relação às notas vizinhas do capítulo 17, o AutoPT fornece o modelo de ciclo aplicado a LLMs e a nota de Continuous Purple Teaming fornece a generalização de pipeline, e a Skyhawk ocupa o nicho cloud dessa mesma lógica, com priorização por caminho como assinatura própria. O leitor deve sair desta nota entendendo que a combinação viável é camada de dados de CNAPP e CIEM, motor de simulação agêntico e esteira de correção com dono e prazo, e que qualquer um desses três elos faltando reduz o programa a mais um gerador de listas.