A empresa de segurança em IA PromptArmor divulgou uma cadeia de ataque contra o Databricks Genie Code: um Skill com código malicioso consegue, sem que o usuário perceba, enviar dados do tenant para um servidor do atacante e, ao mesmo tempo, abrir uma janela de login de phishing dentro da interface de chat. Dos quatro tipos de controle de segurança oficiais listados pela PromptArmor, nenhum conseguiu bloquear essa cadeia.
O Genie Code é o assistente agente embutido na Databricks, que permite ao usuário, em linguagem natural, consultar tabelas, executar análises e gerar gráficos, com o resultado renderizado diretamente na janela de chat no navegador. Um Skill é um pacote de capacidades que pode ser enviado ao agente, contendo texto descritivo e, opcionalmente, código executável.
Como o ataque acontece
O fluxo demonstrado pela PromptArmor tem apenas quatro passos. O usuário envia um Skill de análise de dados que parece normal e pede à Genie para usá-lo em um conjunto de dados; a Genie executa o código do Skill, e o agente de guardrail responsável por filtrar não identifica a função maliciosa; a Genie então sugere ao usuário "abrir o resultado completo da análise"; no momento em que o resultado é renderizado, aparece a janela de phishing e, simultaneamente, os dados são enviados.
A técnica de vazamento é bem simples. O código do Skill primeiro lê dados sensíveis do tenant da vítima e os insere em um trecho de HTML que será exibido no chat; o JavaScript desse HTML faz, no próprio navegador do usuário, uma requisição de rede que envia os dados ao servidor do atacante. A janela de phishing também é renderizada pelo mesmo trecho de HTML, sobreposta à página da Genie, induzindo o usuário a digitar login e senha. Em todo o processo, nenhuma etapa exige aprovação manual.
Por que os quatro controles não funcionaram
A PromptArmor comparou, um a um, os quatro tipos de controle citados na documentação da Databricks:
- Governança de Skills em nível organizacional: a Genie carrega Skills também do workspace pessoal do usuário, não apenas de diretórios gerenciados centralmente pela organização, então os administradores não têm controle sobre os Skills que o próprio usuário envia;
- Agente de guardrail: a própria Databricks o define como um "recurso de eficiência de melhor esforço", sem garantir que funcione como barreira de segurança;
- Controle de saída do ambiente de execução de código: limita apenas o tráfego de saída do ambiente de execução de código, mas os dados aqui são enviados a partir do navegador do usuário, fora do alcance dessa camada;
- Sandbox de exibição do chat: o Skill usa os dados já obtidos para montar o conteúdo exibido, sem precisar consultar o tenant de novo na etapa de exibição.
Cada uma das quatro razões faz sentido isoladamente, mas juntas deixam exatamente uma brecha aberta. A PromptArmor reportou o problema à Databricks em 16 de agosto, as duas partes negociaram por um mês, e em 16 de setembro a PromptArmor avisou que se preparava para tornar o caso público.
A postura da Databricks na resposta é bastante clara:
"it is ultimately the user's responsibility to ensure that uploaded skills do not contain malicious content"
(garantir que os Skills enviados não contenham conteúdo malicioso é, em última instância, responsabilidade do usuário.)
Sobre o recurso de aprovação automática, que permite pular a confirmação a cada execução, a Databricks também afirma que "não pretende que ele funcione como barreira de segurança", e a documentação recomenda não usá-lo em ambientes de produção.
O mesmo tipo de brecha também aparece em outras empresas
Colocando lado a lado os relatórios que a PromptArmor publicou no último ano, a superfície de ataque é bastante semelhante. Antes, a empresa já havia revelado vazamento de arquivos no Claude Cowork e vazamento de dados no Google Antigravity, seguindo o mesmo padrão: fazer o agente ler conteúdo sensível e, depois, usar renderização, links ou chamadas de rede para extrair esse conteúdo. A diferença está na porta de entrada: nos casos anteriores, a injeção de prompt era o caminho principal; desta vez, no caso da Genie, trocou-se para o Skill, um tipo de plugin que "ao ser instalado já pode executar código".
Para as empresas, um Skill é mais difícil de conter do que um texto de injeção. Um texto de injeção precisa, no mínimo, se esconder em uma página ou documento e esperar que o agente o leia; já um Skill é instalado ativamente pelo próprio usuário, trazendo confiança embutida por natureza. O meio acadêmico também vem discutindo bastante o tema este ano, e já surgiram no arXiv benchmarks dedicados a avaliar Skills maliciosos, com taxas de falso negativo das ferramentas de detecção geralmente ainda altas.
Muitas equipes na China também estão conectando agentes a plataformas de dados e abrindo marketplaces de plugins, e a lista de verificação que esse incidente traz é bem concreta: se o Skill só pode ser carregado de um diretório revisado por administradores, se o HTML produzido pelo agente pode executar scripts e enviar requisições para domínios externos, e se a chave de aprovação automática vem desativada por padrão em ambientes de produção. Basta um desses três pontos não estar travado para que a cadeia demonstrada pela PromptArmor possa se repetir.
As recomendações da PromptArmor também se concentram nesses pontos: não habilitar aprovação automática com dados de produção e ficar atento a pacotes envenenados em marketplaces de Skills. Se a Databricks vai adicionar algum filtro de saída em nível de produto, por ora não há comunicação pública sobre isso.
Fontes: relatório de pesquisa de segurança da PromptArmor, documentação de produto do Databricks Genie Code, CocoLoop, artigos sobre Skills maliciosos no arXiv; as datas de divulgação e negociação, bem como o texto original da resposta da Databricks, seguem o relatório da PromptArmor.