Estudos da Wake Forest revelam como agentes de IA e apps para iOS expõem credenciais

Pesquisas da Universidade Wake Forest apontam uma fragilidade recorrente em dois ecossistemas de inteligência artificial que crescem rapidamente: credenciais são colocadas em locais onde agentes, aplicativos ou invasores conseguem encontrá-las e reutilizá-las. Um estudo analisou 17.022 habilidades de terceiros para agentes e identificou 520 itens afetados, com 1.708 problemas de segurança. Em uma investigação relacionada, 282 dos 444 aplicativos para iOS com recursos de modelos de linguagem grande (LLMs) expuseram credenciais ou mecanismos de acesso ao backend durante os testes. 124

O risco prático vai muito além de uma sequência de caracteres vazada. Uma chave de API ou um token exposto pode permitir acesso a dados privados, recursos privilegiados de um agente ou inferências pagas na conta do desenvolvedor.

O que o estudo sobre habilidades de agentes encontrou

Os pesquisadores selecionaram 17.022 habilidades entre 170.226 artefatos disponíveis no SkillsMP, um marketplace de habilidades para agentes. A análise combinou detecção estática de segredos, testes dinâmicos em um ambiente isolado com credenciais fictícias e comparação entre a finalidade declarada de cada habilidade e seu comportamento durante a execução. 34

Os resultados incluíram:

• 520 habilidades afetadas, que reuniam 1.708 problemas de segurança distribuídos em dez padrões de vazamento de credenciais. 416
• 466 das 520 habilidades afetadas expunham credenciais utilizáveis sem privilégios elevados, o que corresponde à taxa relatada de 89,6% de exploração imediata. 14
• 76,3% dos casos de vazamento exigiam a análise conjunta das instruções em linguagem natural e do código da habilidade.
• 3,1% dos casos envolviam injeção de prompt em linguagem natural sem código executável. 4

Na prática, uma revisão focada apenas no código pode não detectar riscos importantes. Uma habilidade pode descrever uma tarefa aparentemente legítima, mas conter instruções ou scripts de apoio que expõem segredos durante a execução.

Como logs de depuração podem entregar segredos ao modelo

Os registros de depuração apareceram como um vetor especialmente relevante. Em frameworks de agentes que enviam a saída padrão para o contexto do modelo, uma credencial exibida por comandos como print ou console.log pode ficar acessível após uma solicitação comum em linguagem natural. O resumo do estudo aponta o logging de depuração como o principal vetor e atribui 73,5% dos vazamentos à exposição da saída para os LLMs. 4

O problema não se limita a chaves de API escritas diretamente no código. Credenciais também podem aparecer em scripts, variáveis de ambiente, logs, instruções de prompt ou na combinação entre código e linguagem natural que só se torna perigosa durante o uso normal.

Desenvolvimento malicioso e descuidado contribuem para o problema

A pesquisa descreve duas causas amplas para o vazamento de credenciais:

• Desenvolvimento malicioso: a habilidade inclui deliberadamente instruções ou cargas criadas para coletar credenciais e dados privados, com a possibilidade de enviá-los a um servidor remoto.
• Desenvolvimento negligente: o desenvolvedor não adota práticas seguras e deixa, sem intenção, credenciais ou caminhos de acesso disponíveis para invasores. 1

A distinção é importante para definir a resposta. Conteúdo malicioso precisa ser identificado e removido; exposições acidentais exigem gestão adequada de segredos, logs mais seguros, controles de autenticação e testes antes da distribuição.

Depois de ser avisada pelos pesquisadores, a SkillsMP informou à Wake Forest que todas as habilidades identificadas como maliciosas foram removidas e que a maioria das habilidades vulneráveis foi corrigida. O estudo, porém, alerta que limpar o repositório original pode não ser suficiente: cópias derivadas — os chamados forks — podem conservar credenciais expostas mesmo depois do reparo da fonte. 14

Apps para iOS abriram outro caminho para o sequestro de contas de IA

A pesquisa relacionada examinou 444 aplicativos para iOS com recursos de LLM e descobriu que 282 — cerca de 64% — expunham credenciais exploráveis ou mecanismos de acesso ao backend no tráfego de rede. 25

Os padrões de exposição relatados foram:

• Tokens baseados em JWT que podiam ser reutilizados: 48%;
• Proxies de backend sem autenticação: 33%;
• Transmissão de chaves de API em texto simples: 19%. 3

Essas falhas podem ser observadas durante o uso normal do aplicativo. Um invasor que capture uma chave, reutilize um token ou encontre um proxy aberto pode enviar solicitações usando a conta de LLM do desenvolvedor. Isso pode consumir inferência paga, abusar de recursos de nuvem ou gerar cobranças não autorizadas. 25

As evidências sustentam o risco de cobranças muito elevadas ou potencialmente sem limite definido, dependendo dos limites configurados na conta e do tempo que o acesso indevido permanecer ativo. Elas não comprovam, de forma independente, um valor específico de prejuízo — como “centenas de milhares de dólares”.

A correção das falhas também foi lenta. Três meses depois da divulgação responsável, apenas 28% dos aplicativos de iOS afetados haviam corrigido a vulnerabilidade relatada; no acompanhamento do estudo, 72% continuavam exploráveis. 311

Por que isso importa para o desenvolvimento com IA

Em conjunto, os estudos mostram que adicionar um recurso de IA a um aplicativo ou instalar uma habilidade reutilizável de agente pode ampliar a superfície de ataque. Os novos riscos incluem:

• Chaves de provedores incorporadas em aplicativos ou expostas ao contexto de um agente;
• Ferramentas privilegiadas capazes de acessar arquivos, serviços ou dados privados;
• Logs que passam involuntariamente a fazer parte do contexto legível pelo modelo;
• Endpoints de backend que aceitam solicitações sem autenticação suficiente;
• Tokens que podem ser reutilizados por invasores;
• Cobranças de uso de LLM geradas na conta do desenvolvedor.

A preocupação aumenta com a popularização do chamado vibe coding, em que ferramentas de IA geram e integram software rapidamente. Ganhar velocidade não elimina a necessidade de modelagem de ameaças: autenticação, gestão de segredos, autorização, logs e revisão de dependências ainda exigem engenharia cuidadosa. O estudo sobre habilidades de agentes também encontrou sinais de desenvolvimento assistido por IA em 72% dos casos de credenciais inseridas diretamente no código, sugerindo que padrões inseguros podem se espalhar por meio de código gerado ou montado às pressas. 4

Práticas de segurança desde o início

Os resultados apontam para uma linha de base defensiva para equipes que desenvolvem produtos de IA ou distribuem habilidades de agentes:

1. Mantenha chaves de provedores de longa duração fora dos dispositivos dos usuários e do contexto dos modelos. Faça chamadas sensíveis por meio de um servidor autenticado.
2. Use credenciais de curta duração e escopo restrito. Aplique o princípio do menor privilégio e valide tokens, em vez de considerar que a posse de um token basta para autorizar uma ação.
3. Remova segredos de logs e da saída padrão. Tudo o que é enviado ao contexto de um agente deve ser tratado como potencialmente recuperável pelo modelo ou pelo usuário.
4. Analise código, configurações, prompts e dependências em busca de segredos. Os resultados sobre habilidades mostram por que instruções em linguagem natural e código executável precisam ser revisados em conjunto.
5. Teste o tráfego de rede e a autorização do backend. Verifique se uma solicitação interceptada não pode ser reutilizada nem redirecionada por meio de um proxy sem autenticação.
6. Revogue e substitua credenciais expostas; verifique também forks e cópias. Remover um segredo do repositório original não garante que todas as versões distribuídas tenham sido limpas.
7. Inclua revisão da plataforma antes da distribuição. Triagem em marketplaces, orientação para desenvolvedores, divulgação responsável e verificações automatizadas podem complementar a conscientização individual. 34

A principal lição é direta: segurança para IA não pode ser deixada para depois do lançamento. Credenciais, permissões de agentes, contexto dos modelos e controles de cobrança precisam ser tratados como elementos centrais da segurança do produto desde o começo.