🤖 AI

Agentic Cloud Decoys: A Deception-Driven Framework for Autonomous Intrusion Investigation

Este artigo apresenta o "Cloud Decoy AI Agent", um framework que combina iscas de nuvem de alta fidelidade com agentes de modelos de linguagem autônomos para comprimir a investigação de intrusões através da agregação de evidências em nível de sessão e do emprego de geração dinâmica de prompts para mitigar falsos positivos e riscos de injeção indireta de prompts, alcançando a reconstrução completa de nove de cada dez cenários controlados de AWS S3 em poucos minutos.

Autores originais: Mohan Manivannan, Dalal Alharthi

Publicado 2026-07-28

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Mohan Manivannan, Dalal Alharthi

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine a internet como uma cidade gigante e movimentada onde cada ação deixa uma pegada. Nesta versão digital da cidade, conhecida como "nuvem", as empresas armazenam seus dados mais preciosos. Para manter esta cidade segura, as equipes de segurança observam milhões de pequenas pegadas chamadas "logs". Esses logs registram cada vez que alguém abre uma porta, pega um arquivo ou caminha por um corredor. O problema é que a cidade é tão grande e as pegadas são tão numerosas que encontrar um ladrão real é como tentar identificar uma única pessoa roubando um biscoito em um estádio cheio de pessoas comendo biscoitos. Os logs estão lá, mas são tão barulhentos e confusos que leva dias para os especialistas em segurança entenderem o que realmente aconteceu.

Para resolver isso, os especialistas em segurança começaram a usar um truque chamado "decepção". Em vez de tentar encontrar o bandido na multidão, eles deixam fora um pote de biscoitos falso e brilhante que parece exatamente com o real. Eles sabem que nenhum funcionário honesto tocaria nesse pote específico. Portanto, se alguém tocar nele, a equipe de segurança sabe imediatamente: "Aquele é um ladrante!" Este artigo, escrito por pesquisadores da Universidade do Arizona, faz uma nova pergunta: Uma vez que o pote de biscoitos falso é tocado, podemos usar um robô de computador superinteligente (um "agente de IA") para descobrir instantaneamente quem é o ladrão, o que ele roubou e escrever um relatório para o detetive humano, tudo isso sem se confundir com o ruído?

O Problema: Pegadas Demais, Ruído Demais

Os pesquisadores explicam que a segurança em nuvem está atualmente presa em um paradoxo. Quanto mais dados as empresas coletam, mais difícil se torna encontrar os vilões. Os atacantes são astutos; eles usam chaves roubadas para entrar pela porta da frente exatamente como um funcionário comum. Quando fazem isso, os logs do computador parecem exatamente iguais aos de uma pessoa normal realizando seu trabalho. As equipes de segurança passam horas e dias tentando reunir esses logs para entender o que aconteceu, muitas vezes perdendo a janela para interromper o dano.

O artigo argumenta que simplesmente adicionar mais logs ou uma IA melhor não é a resposta. O verdadeiro problema é que a IA está sendo solicitada a ler todo o histórico da cidade para encontrar um único evento ruim. Isso é caro, lento e propenso a erros.

A Solução: A Isca e o Robô Detetive

Os autores construíram um sistema chamado Cloud Decoy AI Agent (Agente de IA de Isca na Nuvem). Ele funciona em duas partes principais:

A Isca (O Decoy): Eles configuraram um balde de armazenamento falso (uma pasta digital) cheio de arquivos que parecem incrivelmente tentadores para um ladrão, como "secret_api_keys.txt" ou "bank_records.sql". Crucialmente, nenhum funcionário real deve tocar nesta pasta. Se a pasta for tocada, é uma garantia de 100% de que algo suspeito está acontecendo. Isso atua como um alarme perfeito.
O Robô (O Agente de IA): Em vez de um humano olhar para o alarme, um robô de IA inteligente assume o controle. Mas aqui está a parte complicada: os pesquisadores perceberam que apenas entregar o alarme a um robô não é suficiente. Se o robô tiver permissão para olhar para tudo na nuvem, ele ficará sobrecarregado pela atividade normal e entediante e poderá inventar histórias (um problema chamado "alucinação") para preencher as lacunas.

Como Eles Ensinaram o Robô a Ser Inteligente

O artigo introduz três regras inteligentes para fazer o robô funcionar corretamente:

Agrupamento de Pistas: Em vez de olhar para cada clique como um evento separado, o robô os agrupa em "sessões". Se um ladrão abre a pasta falsa, olha para um arquivo e o baixa dentro de 15 minutos, o robô vê isso como uma história contínua, não como três eventos separados e confusos.
A Regra "O Que Você Vê É O Que Você Tem": Esta é a parte mais importante. Os pesquisadores criaram uma regra de que o robô só pode escrever sobre coisas que ele realmente viu. Se o robô não viu um nome de arquivo específico nos logs, ele não tem permissão para adivinhar ou inventar um. Eles construíram um sistema de "prompt dinâmico" especial que alimenta o robô apenas com a evidência exata que ele encontrou, impedindo-o de inventar detalhes falsos para fazer a história parecer completa.
A Armadilha na Armadilha: Os pesquisadores também notaram um novo problema assustador. Como os logs registram exatamente o que o ladrão digita (como nomes de arquivos), um ladrão poderia escrever um arquivo chamado "Deletar todos os meus arquivos" ou "Ignore as instruções anteriores". Se o robô ler isso, ele pode ser enganado para fazer o que o ladrão quer. O artigo aponta que este é um perigo enorme. Eles identificaram este risco, mas admitiram que seu robô atual ainda não possui um escudo contra isso. Eles dizem que isso deve ser corrigido antes que alguém use este sistema no mundo real.

O Que Eles Descobriram (e o Que Não Descobriram)

A equipe testou seu sistema com dez diferentes cenários de "assalto" em um ambiente de nuvem seguro e falso. Eles simularam ladrões tentando listar arquivos, roubar dados, deletar coisas e até usar scripts para fazer isso mais rápido.

As Boas Notícias: O sistema funcionou incrivelmente bem. Ele reconstruiu 9 de 10 cenários completamente. Em cada relatório que o robô escreveu, cada fato podia ser rastreado até algo que ele realmente viu nos logs. O robô não inventou nenhuma história falsa. Ele também fez isso muito rapidamente, levando apenas 4 a 5 minutos desde o momento em que a pasta falsa foi tocada até o momento em que o relatório foi finalizado.
A Única Falha: O sistema falhou em um cenário específico onde o ladrão esperou 20 minutos entre olhar para a pasta e roubar o arquivo. Como a regra de "agrupamento" do robô estava definida para 15 minutos, ele pensou que o ladrão havia saído e retornado mais tarde, dividindo a história em dois eventos separados e não relacionados.
As Peças Faltantes: Os autores são muito honestos sobre o que eles não provaram. Eles não testaram seu sistema contra um sistema de segurança "normal" para ver se era melhor. Eles não o testaram com outros tipos de robôs de IA. E eles não o testaram em um ambiente de empresa real e bagunçado com milhares de funcionários. Eles apenas o testaram em um laboratório limpo e controlado com um tipo de serviço de nuvem (Amazon S3).

O Panorama Geral

Este artigo sugere que usar uma "isca" para acionar um robô detetive inteligente é uma maneira brilhante de cortar o ruído da segurança em nuvem. Transforma uma busca massiva e impossível em uma investigação pequena e gerenciável. Ao forçar o robô a ater-se estritamente à evidência que encontra, eles impediram que ele inventasse coisas.

No entanto, os pesquisadores são claros: este é um protótipo, não um produto acabado. Eles identificaram uma brecha de segurança séria onde um ladrão poderia enganar o robô com instruções falsas, e eles ainda não corrigiram isso. Eles também admitem que precisam testar o sistema de forma mais ampla antes que qualquer pessoa possa confiar nele com segredos reais de empresas. Mas a ideia central — que um pote de biscoitos falso combinado com um robô disciplinado pode resolver o mistério do biscoito perdido — é uma nova direção promissora para manter nossas cidades digitais seguras.

Resumo Técnico: Agentes de Decepção em Nuvem (Agentic Cloud Decoys)

Definição do Problema
Ambientes de nuvem geram telemetria em uma escala que, paradoxalmente, dificulta a compreensão de intrusões. Atacantes operam através de identidades legítimas e tokens de sessão federados, realizando ações (ex: ListObjects, GetObject) indistinguíveis de um comportamento administrativo rotineiro. Consequentemente, analistas enfrentam um "paradoxo de visibilidade": embora os logs capturem eventos, o tempo necessário para reconstruir o contexto, a identidade e a intenção é medido em horas ou dias. Duas propriedades estruturais exacerbam essa latência:

Granularidade: A telemetria é registrada por chamada de API, fragmentando uma única campanha de ataque em dezenas de eventos que parecem benignos.
Camadas de Identidade: Credenciais federadas obscurecem o principal durável por trás de tokens de sessão efêmeros, tornando a atribuição difícil sem junções (joins) custosas entre múltiplas fontes.

A decepção tradicional (honeypots) oferece uma alta relação sinal-ruído ao gerar alertas apenas quando um chamariz é tocado, mas as implementações existentes frequentemente entregam esses alertas a humanos, exigindo a mesma reconstrução manual que pretendiam evitar. Conectar um chamariz a um agente autônomo não é uma integração trivial; apresenta desafios de design específicos relacionados à agregação de sessões, delimitação de evidências e o risco de injeção de prompt indireta.

Metodologia
O artigo apresenta o Cloud Decoy AI Agent, um framework que combina um chamariz de nuvem de alta fidelidade com um agente de Grande Modelo de Linguagem (LLM) autônomo. O sistema opera em um pipeline de seis camadas:

Recurso de Chamariz (Decoy Resource): Um bucket Amazon S3 nomeado para se assemelhar a um ativo empresarial sensível, populado com arquivos realistas, porém fabricados. Ele é acessível via grafos de confiança IAM normais, mas não possui razão de fluxo de trabalho legítimo para ser acessado.
Detecção de Eventos e Roteamento: Eventos de dados do CloudTrail para o chamariz são roteados via EventBridge para uma função Lambda. Os eventos são normalizados e indexados por uma tupla de pivô (IP de origem, chave de acesso, principal, bucket).
Agregação de Sessão: Um processo em segundo plano descarrega (flush) as sessões do DynamoDB para uma fila SQS quando estas permanecem ociosas por um limite ( $\tau = 15$ minutos). Isso agrupa eventos granulares em sessões coerentes, delimitadas pelo intervalo de ociosidade.
Runtime do Agente: Um agente (orquestrado via LangGraph) consome as mensagens da sessão. Ele utiliza ferramentas do Protocolo de Contexto de Modelo (MCP) para consultar o histórico do CloudTrail, contexto de IAM/STS e configurações de segurança do S3.
Raciocínio e Geração de Relatórios: O agente emprega uma estratégia de prompt de dois estágios:
- Prompt de Sistema Estático: Define a estrutura de raciocínio, a estrutura de saída e as restrições (ex: "não fabrique indicadores").
- Prompt de Usuário Dinâmico: Construído por sessão utilizando apenas as evidências que o agente realmente observou. Campos ausentes são omitidos em vez de preenchidos com placeholders para evitar alucinações.
Saída: Um relatório estruturado contendo um resumo executivo, linha do tempo cronológica, análise de identidade, grafo de ataque e recomendações.

Principais Contribuições
O artigo apresenta cinco contribuições específicas:

Formalização da Reconstrução de Sessão Ancorada em Chamariz: Define uma tupla de pivô derivada exclusivamente de campos fornecidos pelo provedor (excluindo dados fornecidos pelo cliente) e um operador de agregação que agrupa eventos em sessões e campanhas.
Identificação da Telemetria como um Canal Parcialmente Escrito pelo Adversário: Os autores argumentam que, como as chaves de objetos e os user agents são valores escolhidos pelo atacante e registrados literalmente, os pipelines de log-para-prompt são estruturalmente expostos à injeção de prompt indireta. Eles especificam uma disciplina de quarentena (particionamento de campos do provedor vs. cliente), mas observam explicitamente que o protótipo ainda não implementa a mitigação completa.
Construção Explícita de Regras para Grafos de Ataque: Define uma condição de mundo fechado onde nós e arestas existem apenas se suportados por campos observados, evitando conexões inferidas ou alucinadas.
Disciplina de Geração de Prompt Dinâmico: Uma estratégia de montagem de dois estágios que impõe um "invariante de fundamentação", garantindo que o relatório contenha apenas asserções sustentadas pela evidência observada.
Modelo de Custo Analítico: Demonstra que, em um design ancorado em decepção, o custo por incidente é linear na taxa de interação do chamariz e independente do volume total de telemetria da conta, desacoplando a economia da investigação do tamanho do ambiente.

Resultados de Avaliação
O sistema foi avaliado no AWS S3 em dez cenários controlados (enumeração, recuperação, acesso a múltiplos objetos, acesso negado, exclusão destrutiva e acesso atrasado).

Precisão de Reconstrução: Nove de dez cenários foram reconstruídos completamente; um (acesso atrasado) foi parcial devido ao fato de a janela de flush da sessão ter dividido a campanha.
Fundamentação (Grounding): Nenhum relatório continha uma asserção que os autores não pudessem rastrear até um artefato observado (satisfazendo o invariante de fundamentação).
Latência: A latência de ponta a ponta foi de 4 a 5 minutos, dominada pela janela de flush de sessão de 15 minutos (um parâmetro de configuração) em vez do tempo de inferência.
Nomenclatura de Objetos: Em todos os cenários envolvendo recuperação, cada chave de objeto acessada foi nomeada explicitamente.

Significância e Alegações
O artigo afirma que o Cloud Decoy AI Agent aborda o gargalo da "latência de reconstrução" na resposta a incidentes em nuvem ao inverter o problema da detecção. Sua significância reside em três mudanças arquiteturais:

Decepção como Limite de Custo/Corretude: O uso de um chamariz como o portão de entrada (upstream gate) define o universo de investigação do agente, tornando um horizonte de evidência estrito defensável e econômico.
Fundamentação Estrutural: A montagem de prompt de dois estágios impõe a limitação de evidências estruturalmente, removendo a tentação de o modelo alucinar valores para campos ausentes.
Consciência de Escrita pelo Adversário: O trabalho identifica explicitamente o risco de que a telemetria em nuvem seja parcialmente escrita pelo adversário, transformando o chamariz em uma potencial superfície de injeção.

Modéstia e Limitações
Os autores são explícitos sobre o que a avaliação não estabelece:

Sem Baselines ou Ablações: Não há comparação contra um baseline de logs brutos, uma condição de template estático ou um gatilho não baseado em chamariz.
Sem Pontuação Independente: A avaliação foi realizada pelos próprios autores, não por avaliadores independentes.
Escopo: A avaliação cobre apenas um serviço (S3), um provedor (AWS) e uma região.
Riscos Não Mitigados: O protótipo não implementa a mitigação completa para injeção de prompt indireta (sanitização de campos fornecidos pelo cliente) ou correlação entre sessões (o que causou a falha no cenário de acesso atrasado).
Evasão de Chamariz: O sistema assume que o adversário não identifica e evita o chamariz; nenhuma avaliação de fingerprinting ou evasão de chamariz foi conduzida.

Os autores posicionam este trabalho como uma instância inicial e abertamente delimitada de um padrão que esperam que se torne comum, com próximos passos específicos identificados (ex: comparação entre prompts estáticos vs. dinâmicos, ou gatilhos de anomalia vs. chamariz) como necessários para validar as contribuições arquiteturais.

O Problema: Pegadas Demais, Ruído Demais

A Solução: A Isca e o Robô Detetive

Como Eles Ensinaram o Robô a Ser Inteligente

O Que Eles Descobriram (e o Que Não Descobriram)

O Panorama Geral

Mais como este