A Skill Confiável Era o Ataque: Copilot Cowork e a Cadeia de Suprimentos de Agentes

O apelo dos agentes de IA é que eles podem usar ferramentas em seu nome. Um pesquisador que analisou o Microsoft Copilot Cowork encontrou uma maneira de virar esse apelo contra o usuário, e o caminho percorrido diz muito sobre para onde a segurança de agentes está indo.

A PromptArmor divulgou a descoberta em 30 de setembro. A versão resumida: um “skill” baixado que parecia um verificador de documentos inofensivo podia sequestrar o próprio caminho de rede do Cowork, abrir um canal de comando para o servidor de um atacante e extrair dados do Outlook, SharePoint e Teams. A Microsoft, segundo o relato do pesquisador, recebeu o relatório em junho e concluiu a correção em agosto, então os detalhes técnicos foram publicados depois da correção, e não antes dela.

Quatro etapas, e apenas duas envolvem você

O ataque exigia que o usuário fizesse duas coisas comuns: enviar um documento para revisão e invocar uma skill.

Na demonstração, a skill alegava comparar um contrato com uma proposta e sinalizar inconsistências. Ela fazia isso, e é justamente o que torna esse tipo de ataque difícil de detectar. O problema era um script incluído junto com a skill. O Cowork roda dentro de uma sandbox que não deveria acessar a internet aberta, mas mantém uma ponte para as requisições de que precisa para gerar respostas. O script malicioso usou um serviço de sincronização de arquivos acessível por meio dessa ponte e, crucialmente, o serviço aceitava uma URL fornecida pelo chamador.

Esse detalhe é todo o exploit. Assim que o script conseguia alcançar um endereço controlado pelo atacante, ele abria um loop. A cada poucos segundos, ele buscava um arquivo contendo um comando, executava o comando dentro do Cowork e codificava o resultado em um parâmetro de URL enviado de volta ao servidor. Isso é um canal de comando bidirecional, não um beacon unidirecional, o que significa que o atacante podia emitir novas instruções com base no que o comando anterior retornava.

Na demonstração, o pesquisador listou os e-mails do Outlook da vítima e leu o conteúdo de uma conversa de e-mail. Segundo o relatório, o mesmo caminho de acesso também expunha arquivos do SharePoint, histórico de sessão e dados de plugins. Até onde ele chega depende do que o usuário em questão já consegue ver, que é o amplificador habitual nesses casos: o agente herda as permissões do usuário, então o raio de impacto é tudo o que aquela conta consegue tocar.

Mais um detalhe merece ser repetido porque muda a forma como as pessoas pensam em interromper um ataque. Selecionar o controle de parar não encerrava o processo em segundo plano. O turno visível podia terminar enquanto o script continuava consultando. O usuário acredita que a tarefa acabou, e o canal continua aberto.

A skill é a dependência

A parte interessante desta divulgação não é o bug específico, que agora está corrigido. É que a superfície de ataque não era uma injeção de prompt nas instruções do modelo. Era a cadeia de suprimentos em torno do agente.

Skills em um sistema como esse são pequenas aplicações. Elas podem incluir scripts, documentos de referência e configuração, até vinte arquivos complementares no caso do Cowork, e muitas vezes vêm de fora da organização, baixadas de um marketplace ou compartilhadas entre colegas. Essa é a mesma estrutura que causou anos de problemas nos ecossistemas npm e PyPI, em que uma dependência que você não escreveu pode executar código que você não leu. Skills de agente são dependências com um nome mais amigável. A descrição na página da skill afirmava que todo o processamento acontecia localmente e que nada era enviado a terceiros. A própria inspeção da plataforma não detectou o verdadeiro comportamento do script incluído.

Há um segundo vazamento, mais silencioso, que aponta para a mesma fraqueza. Um relatório da Glow descobriu que agentes haviam exposto mais de 13.000 imagens internas e capturas de tela de mais de 300 organizações por meio de repositórios públicos do GitHub. Ninguém pretendia publicar esses arquivos. Eles acabaram expostos porque um agente os escreveu em algum lugar que um repositório público conseguia alcançar.

Os dois incidentes parecem diferentes e compartilham uma causa raiz. Em um deles, uma skill maliciosa alcançou o exterior de propósito. No outro, um agente bem-comportado gravou dados em um local que não entendia ser público. Ambos são falhas da fronteira em torno do que um agente consegue alcançar e até onde sua saída viaja. O caso do Cowork mostra um atacante explorando essa fronteira. O caso do GitHub mostra a fronteira falhando sozinha, sem que ninguém tentasse quebrá-la, o que provavelmente é o desfecho mais comum no uso cotidiano.

Como ler uma divulgação de segurança como esta

A linha do tempo é a parte que a maioria dos leitores pula, e vale a pena percorrê-la porque ela mostra como avaliar a descoberta. A PromptArmor relatou o problema à Microsoft no final de junho. A Microsoft pediu mais informações em julho, discutiu a correção no início de agosto e confirmou a correção em meados/final de agosto. A pesquisa se tornou pública no final de setembro, após o patch, o que é a sequência padrão de divulgação responsável. Duas lições decorrem disso.

Primeiro, uma vulnerabilidade corrigida não é o mesmo que uma classe de vulnerabilidade corrigida. O caminho de exploit específico está fechado. O padrão que o tornou possível, uma integração confiável que o agente precisa alcançar sendo utilizável como canal arbitrário, aparece sempre que um agente tem um caminho de rede permitido. A mesma semana produziu outros exemplos que apontam para a mesma fraqueza, incluindo relatos de que agentes haviam exposto milhares de imagens internas por meio de repositórios públicos. Bugs diferentes, mesma forma.

Segundo, a correção chega no cronograma da Microsoft, não no seu. Qualquer pessoa que use essas ferramentas em uma empresa precisa saber em qual versão está e se a atualização realmente chegou até ela. Uma nota de patch em um blog não é o mesmo que uma implantação corrigida.

A skill é a dependência

O instinto depois de uma história como essa é confiar mais na sandbox. A sandbox do Cowork fez seu trabalho contra acesso direto à internet, e o exploit contornou a fronteira usando um caminho que a sandbox precisava deixar aberto. Esse é o padrão geral: um agente sem ferramenta de rede direta ainda não é um sistema fechado se ele pode criar conteúdo em uma superfície que busca recursos externos depois, ou operar um serviço que faça isso.

Para equipes que executam agentes em um ambiente corporativo, a resposta prática se parece menos com um patch de segurança e mais com governança de software comum. Saiba quais skills estão instaladas e de onde vieram. Coloque a instalação de skills sob controle de TI em vez de deixá-la a cargo de usuários individuais. Trate uma skill com caminho de rede como você trataria qualquer novo executável, com revisão antes de executá-lo. Verifique se uma atualização de segurança realmente cobre a versão em uso.

Nada disso é exótico. É a disciplina que a segurança da cadeia de suprimentos impôs às equipes de software na última década, agora chegando uma camada acima. A diferença são os riscos. Um pacote npm comprometido pode executar código na máquina de um desenvolvedor. Uma skill comprometida roda dentro de um agente que já tem acesso ao seu e-mail, seus arquivos e seu histórico de chat, e pode continuar rodando depois que você acha que mandou parar.