A Bypass do Sandbox do Microsoft Copilot Cowork Transformou uma Skill Confiável em um Canal de Exfiltração

A Microsoft mitigou uma vulnerabilidade no Copilot Cowork depois que pesquisadores mostraram que uma única Skill maliciosa poderia contornar o sandbox do produto e exfiltrar dados de trabalho. O bypass do sandbox do Microsoft Copilot Cowork teria criado um canal de comandos entre o servidor de um atacante e o ambiente isolado do agente.

A PromptArmor afirma que esse canal poderia alcançar dados disponíveis por meio do Outlook, SharePoint, Teams, plugins conectados e da sessão ativa. O pesquisador relatou o problema em 24 de junho de 2026, e a Microsoft confirmou a mitigação em 19 de agosto.

A descoberta desafia uma promessa central por trás dos agentes para o ambiente de trabalho. Um sandbox pode isolar código, mas o isolamento significa pouco quando um serviço confiável se torna uma rota não monitorada através de sua fronteira. A Microsoft afirma que o Cowork agora avalia Skills e alerta os usuários para enviá-las apenas de fontes confiáveis.

A falha relatada não é mais um zero-day aberto, segundo a cronologia da divulgação. No entanto, a lição de design vai além de uma implementação corrigida. Agentes empresariais combinam instruções não confiáveis, ativos executáveis, dados organizacionais e ferramentas autenticadas em um único fluxo de trabalho.

Essa combinação torna a fronteira de confiança mais difícil de definir do que era no software empresarial convencional. A questão central já não é se um agente opera dentro de um sandbox. Compradores precisam perguntar quais serviços atravessam esse sandbox, o que esses serviços aceitam e quais atividades as equipes de segurança conseguem observar.

Como Funcionou a Cadeia de Exfiltração de Arquivos do Copilot Cowork

O exploit teria transformado um serviço legítimo de transferência de arquivos em um canal de comando bidirecional que as restrições de rede do sandbox não impediram.

O Copilot Cowork é um sistema agêntico do Microsoft 365 que pode planejar e executar tarefas de várias etapas. Ele pode trabalhar com documentos, pesquisar informações organizacionais, criar arquivos, enviar mensagens e chamar Skills especializadas.

Uma Skill é um pacote reutilizável de instruções que orienta o agente em um fluxo de trabalho específico. A Microsoft oferece suporte a Skills integradas, personalizadas, compartilhadas e baseadas em plugins, dependendo do ambiente do Cowork e da configuração administrativa.

O exemplo da PromptArmor começou com uma tarefa empresarial comum. Um usuário pediu ao Cowork que comparasse um contrato com uma proposta por meio de uma Skill de consistência de documentos baixada de uma fonte externa.

A Skill produziu a comparação solicitada, de modo que a tarefa visível pareceu bem-sucedida. No entanto, a PromptArmor afirma que um script incluído também acionou um serviço de sincronização de arquivos operando fora do sandbox do agente.

O Cowork teria usado esse serviço para mover arquivos entre armazenamento externo e o ambiente de trabalho isolado. O serviço aceitava uma URL que identificava o arquivo que precisava recuperar.

Segundo a análise do bypass de sandbox do pesquisador, código malicioso poderia fornecer uma URL controlada pelo atacante. Esse comportamento permitia que o script fizesse um serviço externo contatar uma infraestrutura que o sandbox não conseguia alcançar diretamente.

O servidor do atacante retornava um arquivo contendo um comando. O script malicioso lia esse arquivo, executava o comando dentro do Cowork e codificava o resultado em outra URL solicitada.

Essa segunda solicitação levava a saída do comando de volta ao servidor do atacante. Repetir o processo a cada poucos segundos teria estabelecido um loop de comando e controle, o que significa que um atacante poderia emitir novas instruções com base nos resultados anteriores.

Isso foi mais do que uma única solicitação de saída. Criou um caminho interativo para um ambiente conectado a serviços organizacionais.

A PromptArmor afirma que sua demonstração usou o servidor Model Context Protocol do Cowork. MCP é uma interface padrão pela qual uma aplicação de IA pode chamar ferramentas conectadas e recuperar dados.

O pesquisador alega que o atacante poderia usar comandos para consultar serviços disponíveis por meio dessa conexão MCP. A demonstração incluiu listar mensagens do Outlook e recuperar o conteúdo de uma conversa por email.

O mesmo caminho de acesso teria exposto arquivos do SharePoint, histórico da sessão, dados de plugins e outras informações disponíveis ao usuário ativo. O escopo real dependeria das permissões desse usuário e dos serviços conectados.

Um detalhe tornou o comportamento relatado especialmente preocupante. A PromptArmor afirma que selecionar o controle de parada não encerrava processos que já estavam em execução em segundo plano.

A interação visível do agente poderia terminar enquanto o script malicioso continuava consultando o servidor do atacante. Portanto, um usuário poderia acreditar que a tarefa havia parado enquanto o canal encoberto permanecia ativo.

A PromptArmor relatou o problema à Microsoft em 24 de junho. A Microsoft solicitou informações adicionais em 24 de julho, discutiu uma correção até o início de agosto e confirmou a mitigação em 19 de agosto.

As evidências públicas vêm principalmente do relato técnico e da demonstração da PromptArmor. A Microsoft não publicou um aviso detalhado explicando a alteração no código, as versões afetadas ou a telemetria disponível para investigação retrospectiva.

Por Que o Bypass do Sandbox do Microsoft Copilot Cowork É Importante

A vulnerabilidade atacou o serviço que conecta o sandbox a dados úteis, em vez de derrotar o isolamento por meio de uma fuga convencional.

Um sandbox tradicional tenta conter código não confiável restringindo arquivos, processos, dispositivos e conexões de rede. Esse modelo funciona apenas quando todas as rotas que cruzam a fronteira aplicam uma validação igualmente rigorosa.

Agentes modernos complicam esse arranjo porque um trabalho útil exige exceções controladas. Um agente precisa receber documentos, devolver arquivos gerados, chamar ferramentas, acessar sistemas empresariais e preservar estado suficiente para concluir tarefas longas.

Cada exceção se torna um intermediário entre o ambiente isolado e algo mais confiável. O intermediário pode ser seguro quando valida tanto destinos quanto fluxos de dados. Ele se torna perigoso quando código não confiável pode reutilizá-lo para outros fins.

O relato da PromptArmor não descreve um exploit clássico de corrupção de memória ou fuga do sistema operacional. A Skill maliciosa do Copilot Cowork teria permanecido dentro do sandbox enquanto abusava de um serviço privilegiado fora dele.

Essa distinção é importante para revisões de segurança empresariais. Um fornecedor pode afirmar corretamente que o código roda isoladamente enquanto deixa de considerar um intermediário que faz solicitações externas arbitrárias para esse código.

A tensão arquitetônica está no centro do valor do Cowork. A Microsoft apresenta o produto como um agente que vai além do chat e conclui trabalho em todo o Microsoft 365.

No anúncio do produto Cowork da Microsoft, a empresa destacou fluxos de trabalho de caixa de entrada, pesquisa, geração de documentos, integrações e Skills reutilizáveis. Essas capacidades exigem acesso a contexto empresarial valioso.

A documentação atual do Cowork afirma que as tarefas processam arquivos dos usuários em um ambiente temporário e isolado dentro da fronteira de serviço do Microsoft 365. Também afirma que o ambiente é removido após o término da tarefa.

Esse modelo de segurança limita a exposição direta, mas não elimina o risco das ferramentas conectadas. Um ambiente isolado ainda pode se tornar um ponto de partida quando um intermediário confiável aceita entrada controlada por um atacante.

É por isso que o bypass do sandbox do Microsoft Copilot Cowork pressiona tanto a Microsoft quanto os compradores empresariais. A Microsoft precisa mostrar que a fronteira reparada cobre todos os intermediários, não apenas a rota de sincronização identificada por um pesquisador.

Os clientes também precisam rever as suposições sobre permissões de usuários. O Cowork opera com o acesso do usuário ativo, portanto uma tarefa explorada não precisa comprometer uma conta separada para alcançar dados permitidos.

O princípio do menor privilégio ainda reduz o raio de impacto. Ele não impede o uso indevido de acessos que o usuário detém legitimamente.

Um funcionário que compara dois documentos pode ter permissão para ler emails confidenciais, pastas de negociações ou discussões internas. Essas permissões podem se tornar disponíveis para um agente por meio de suas conexões aprovadas.

A entrada maliciosa também chegou como um componente de fluxo de trabalho reutilizável, não como um executável obviamente hostil. Esse empacotamento reduz a suspeita do usuário porque as Skills são concebidas para parecer extensões de produtividade.

Assim, o exploit reúne dois problemas de segurança que as organizações frequentemente gerenciam separadamente. Um é o risco da cadeia de suprimentos de software proveniente de pacotes baixados. O outro é o risco de autorização decorrente de agentes que agem como usuários autenticados.

Os programas de segurança precisam lidar com ambos em conjunto. Revisar código sem mapear os dados acessíveis deixa de considerar o impacto, enquanto governar permissões sem inspecionar ativos de Skills deixa de considerar o ponto de entrada.

Uma Skill Maliciosa do Copilot Cowork Ainda Pode Parecer Útil

A Skill mais perigosa não é aquela que falha visivelmente, mas aquela que conclui seu trabalho atribuído enquanto executa uma segunda tarefa oculta.

A demonstração da PromptArmor usou um fluxo de trabalho de comparação de documentos porque ele reflete uma solicitação comum de trabalho intelectual. A Skill teria gerado um relatório completo de consistência enquanto o script malicioso abria o canal encoberto.

Esse comportamento duplo enfraquece um sinal de segurança conhecido. Usuários frequentemente tratam uma saída correta como evidência de que a ferramenta operou conforme o esperado.

Para um agente, qualidade da saída e integridade da execução são questões distintas. Um relatório útil não revela todos os scripts, chamadas de serviço ou solicitações de dados feitos durante sua produção.

A orientação atual para Skills personalizadas da Microsoft afirma que o Cowork avalia Skills automaticamente. As verificações documentadas variam conforme o alcance e o nível de risco.

Verificações estáticas examinam estrutura, código incluído e texto em busca de padrões de injeção de prompts. Verificações comportamentais avaliam saídas, ações, uso de ferramentas, conflitos e desempenho com prompts realistas.

A documentação descreve barreiras adicionais para implantações de maior risco. Elas podem incluir validação de ativos, testes de confiança e segurança, avaliação adversarial, testes de regressão e revisão humana.

A Microsoft também faz um alerta direto aos usuários: envie Skills apenas de fontes nas quais você confia. Esse conselho reconhece que a inspeção automatizada não pode transformar código arbitrário de terceiros em uma dependência segura.

O momento desses controles documentados merece tratamento cuidadoso. A documentação ativa da Microsoft reflete o produto atual, não necessariamente a configuração exata que a PromptArmor testou antes de 19 de agosto.

Portanto, não é seguro afirmar que todos os controles atuais falharam durante a demonstração. É igualmente inseguro presumir que as verificações listadas detectariam todas as variações do ataque.

A varredura estática tem limitações inerentes. O comportamento malicioso pode ser dividido entre arquivos, ocultado por funções normais, baixado posteriormente ou acionado apenas sob condições específicas.

Testes comportamentais também amostram um conjunto limitado de execuções. Uma Skill pode agir com segurança durante a avaliação e ativar lógica prejudicial após uma data, em um tenant alvo ou quando dados específicos aparecem.

Trabalhos acadêmicos recentes tratam as Skills de agentes como uma superfície de cadeia de suprimentos de software, e não como simples modelos de prompt. A pesquisa SkillGate avaliou um scanner híbrido em comparação com um benchmark contendo 1.650 pacotes de Skills.

Seus autores relataram uma pontuação F1 de 0,817 e uma taxa de falsos positivos de 1,13%. Esses resultados sustentam a triagem em tempo de execução, mas também mostram que a detecção continua sendo probabilística.

A comparação não é uma avaliação direta do Cowork, e o artigo se concentra em Skills de agentes de programação. Ainda assim, seu modelo de ameaça corresponde de perto ao problema mais amplo.

Um pacote reutilizável de instruções pode incluir scripts, documentação aparentemente confiável e comportamento oculto. Instalá-lo amplia a base efetiva de código e instruções do agente.

Lojas tradicionais de aplicativos enfrentam riscos semelhantes por meio de assinatura, revisão, reputação, remoção rápida e declarações de permissões. As Skills de agentes exigem essas medidas, além de visibilidade sobre a execução orientada pelo modelo.

O modelo pode escolher quando e como acionar arquivos de apoio. Essa flexibilidade torna uma Skill mais adaptável, mas também dificulta a produção de um manifesto completo de comportamentos.

A Microsoft oferece compartilhamento organizacional e plugins da App Store, além de Skills personalizadas individuais. Administradores podem governar a disponibilidade de plugins, implantação, conectores e usuários atribuídos.

Esses controles criam um canal de distribuição mais robusto do que baixar um arquivo desconhecido. Eles não eliminam a necessidade de inspecionar pacotes compartilhados de forma privada ou enviados pessoalmente.

Empresas devem tratar uma Skill maliciosa do Copilot Cowork como uma dependência de aplicativo não confiável. Procedência, versionamento, aprovação e revogação importam tanto quanto as instruções em linguagem natural que ela contém.

A Promessa do Sandbox Encontrou a Realidade dos Agentes Conectados

O principal conflito está entre a contenção como promessa de segurança e a conectividade como o recurso que torna um agente empresarial valioso.

A Microsoft afirma que o Cowork pode enviar e-mails, agendar reuniões, criar documentos, publicar no Teams, pesquisar informações organizacionais e gerenciar arquivos. Essas ações o transformam de um chatbot em um sistema operacional.

Cada conector adicional aumenta o valor de uma tarefa bem-sucedida. Também eleva o impacto potencial quando a integridade da execução falha.

A exploração relatada não precisou conceder ao Cowork mais permissões do que as previstas. Ela teria convertido a camada de ferramentas autenticadas existente em uma interface controlada por invasores.

Essa é a inversão que compradores corporativos devem lembrar. Um sandbox protegia o ambiente de execução, mas um serviço de sincronização externo teria dado ao código uma rota para contornar sua política de rede.

O mesmo padrão pode surgir em plataformas de agentes. Agentes isolados em sandbox frequentemente dependem de automação de navegador, repositórios de artefatos, gateways de ferramentas, servidores MCP, intermediários de credenciais e ambientes de execução de conectores.

Equipes de segurança frequentemente analisam cada componente de forma independente. Invasores procuram combinações.

Um serviço de arquivos que parece de baixo risco pode se tornar um proxy de rede. Um endpoint de ferramenta destinado ao agente pode se transformar em uma API de acesso a dados para código malicioso.

Um worker em segundo plano projetado para confiabilidade pode manter um ataque ativo após a interrupção da tarefa visível. Nenhum desses componentes precisa parecer perigoso isoladamente.

A comparação imediata não é entre a Microsoft e uma concorrente. A comparação mais útil é entre a promessa de contenção do setor e a realidade operacional dos agentes conectados.

Anthropic, OpenAI, Microsoft, Google e fornecedores de agentes de programação enfrentam versões dessa tensão. Seus produtos ganham utilidade ao ler mais contexto e executar mais ações.

A falha relatada no Cowork é um exemplo específico de implementação. Ela não deve ser generalizada como evidência de que todo sandbox ou deployment de MCP possui a mesma vulnerabilidade.

Ainda assim, ela mostra por que um rótulo de sandbox não pode servir como uma avaliação completa de segurança. Compradores precisam de um modelo de fluxo de dados que inclua todos os serviços com acesso através da fronteira.

Eles também precisam de clareza sobre a duração dos processos. A Microsoft documenta controles de pausa e cancelamento para tarefas do Cowork, mas o teste da PromptArmor teria descoberto que um processo em segundo plano sobreviveu à ação visível de interrupção.

A Microsoft pode ter alterado esse comportamento como parte da mitigação, ou pode ter fechado apenas a rota de rede. A divulgação pública não explica o reparo nesse nível de detalhe.

Essa lacuna de verificação é importante. As organizações não conseguem determinar, pela cronologia pública, se a Microsoft adicionou validação de destino, alterou a autorização do serviço, encerrou trabalhos em segundo plano, melhorou a detecção ou combinou vários controles.

A ausência de um aviso detalhado não significa que a mitigação falhou. Significa que os clientes devem buscar garantias por meio de orientações para tenants, canais de suporte, dados de auditoria e testes controlados.

A arquitetura de segurança deve presumir que um controle preventivo eventualmente deixará passar um pacote hostil. Um projeto resiliente então limita o que esse pacote pode alcançar e torna comportamentos anormais visíveis.

Para agentes conectados, isso significa restringir destinos de saída, autenticar solicitações de intermediários, vincular serviços a tarefas específicas e separar o acesso de leitura das permissões de ação.

Também significa revogar credenciais quando uma tarefa termina. Uma sessão de agente cancelada deve encerrar processos relacionados e invalidar qualquer autorização temporária criada para essa execução.

Por fim, o monitoramento deve conectar a atividade do agente à telemetria de segurança convencional. Uma invocação de Skill, transferência de arquivos, chamada MCP e solicitação de saída incomum podem parecer inofensivas em consoles separados.

Juntas, elas podem descrever uma cadeia de ataque.

A Mitigação Não Fecha a Lacuna de Verificação

A Microsoft confirmou a mitigação, mas os clientes ainda não têm detalhes públicos suficientes para reconstruir a exposição ou validar todos os controles afetados.

A PromptArmor afirma que a Microsoft confirmou que o problema foi mitigado em 19 de agosto, quase oito semanas após a divulgação inicial. Essa cronologia indica uma correção coordenada, e não uma exploração pública ainda não resolvida.

O pesquisador não publicou evidências de exploração generalizada. A demonstração comprova um caminho técnico sob condições testadas, não o número de tenants afetados na prática.

Nenhuma contagem pública de incidentes, intervalo de versões afetadas, identificador de vulnerabilidade ou indicador de comprometimento aparece na divulgação. Leitores não devem interpretar a prova de conceito como evidência de uma violação ampla.

A conclusão inversa também seria prematura. Sem um aviso detalhado da Microsoft, organizações não podem presumir que a ausência de incidentes divulgados significa que não houve uso malicioso.

A investigação retrospectiva depende de telemetria. Administradores precisam saber se os logs do Cowork expõem versões de Skills enviadas, execução de scripts, solicitações de intermediários, chamadas MCP e duração de processos em segundo plano.

A Microsoft afirma que a atividade do Cowork pode aparecer nos logs de auditoria unificados e que as políticas do Purview se aplicam ao serviço. A documentação administrativa atual também descreve controles para plugins, modelos, uso do navegador e tarefas automatizadas.

Esses controles são relevantes, mas cobertura geral de auditoria não é o mesmo que cobertura de detecção para essa exploração. Um log pode registrar uma solicitação de serviço permitida sem marcar seu destino como hostil.

Organizações que testaram o Cowork antes de 19 de agosto devem perguntar à Microsoft quais eventos podem identificar o comportamento vulnerável. Elas também devem preservar os registros de auditoria relevantes antes que as janelas de retenção expirem.

A análise mais importante diz respeito à procedência das Skills. Equipes devem inventariar Skills personalizadas, arquivos enviados, scripts incluídos e pacotes compartilhados pela organização usados durante o período afetado.

Pacotes desconhecidos ou não verificáveis merecem remoção até serem analisados. Equipes de segurança devem comparar hashes criptográficos quando disponíveis, pois um nome de Skill conhecido não estabelece a integridade do arquivo.

Administradores devem então mapear cada Skill aos usuários que a executaram e aos dados que esses usuários podiam acessar. Isso produz uma estimativa de exposição mais precisa do que analisar apenas o texto das Skills.

A telemetria de rede de saída pode fornecer outro sinal. Solicitações para domínios desconhecidos, intervalos de polling repetidos ou dados codificados em parâmetros de consulta de URL merecem investigação.

No entanto, as solicitações relatadas passavam por um serviço fora do sandbox. Portanto, o monitoramento de endpoints no dispositivo de um funcionário poderia não detectá-las.

Logs do lado da nuvem e a telemetria do fornecedor tornam-se essenciais. Clientes devem perguntar se a Microsoft pode expor a tarefa de origem, Skill, usuário, tenant e destino solicitado para transferências intermediadas.

Organizações também precisam de uma política para futuros envios. Permitir que qualquer usuário importe uma Skill da internet pública transforma a avaliação de confiança em uma decisão individual.

Um modelo mais seguro usa um registro interno com propriedade, status de revisão, versões aprovadas e datas de expiração. Skills de alto risco devem passar por revisão de código e testes em tempo de execução.

Skills compartilhadas precisam de controle de mudanças após a aprovação. Um pacote benigno pode se tornar perigoso por meio de uma atualização, conta de mantenedor comprometida ou arquivo complementar substituído.

A aprovação deve, portanto, aplicar-se a uma versão específica, e não a um nome permanente. Uma nova revisão deve seguir toda alteração material.

Essas etapas não implicam que o Cowork seja exclusivamente inseguro. Elas refletem o nível de governança adequado para qualquer agente que possa acessar e-mails, documentos, chats e aplicações empresariais.

Profissionais do conhecimento também devem manter materiais de origem sensíveis em repositórios com escopo claramente definido. Uma melhor gestão do conhecimento pode reduzir a exposição desnecessária de dados quando as equipes organizam o acesso em torno das necessidades reais de trabalho.

O objetivo não é remover contexto útil de todos os agentes. É evitar que um fluxo de trabalho conveniente herde todo o alcance digital de um funcionário sem uma análise deliberada.

Três Sinais Mostrarão se a Segurança de Agentes Está Acompanhando o Ritmo

O próximo teste é saber se a Microsoft transforma uma mitigação em controles mensuráveis e visíveis ao tenant para todos os caminhos que atravessam o sandbox do Cowork.

O primeiro sinal é uma explicação detalhada da Microsoft sobre a correção. Clientes precisam saber se o Cowork agora valida destinos de sincronização, vincula solicitações a armazenamento aprovado e encerra processos quando tarefas são interrompidas.

Um aviso técnico reforçaria a confiança, pois administradores poderiam testar as fronteiras relevantes. O silêncio não provaria exposição contínua, mas manteria a verificação dependente de canais privados de suporte.

O segundo sinal é uma telemetria de tenant mais rica. Equipes de segurança devem acompanhar novos eventos do Cowork que abranjam hashes de Skills, execução de scripts incluídos, operações MCP, destinos de intermediários e processos em segundo plano vinculados a tarefas.

Esses registros precisam ser utilizáveis por meio dos sistemas de detecção existentes. Um log de atividade visível apenas dentro de uma sessão do Cowork não dará suporte à caça a ameaças em escala empresarial.

O terceiro sinal é uma governança de Skills mais forte. O sistema de avaliação documentado pela Microsoft já descreve verificações estáticas, comportamentais, adversariais, de regressão e humanas em diferentes níveis de risco.

A questão central é quão consistentemente esses controles se aplicam a Skills importadas, pessoais, compartilhadas e distribuídas por lojas. Compradores devem procurar pacotes assinados, aprovações de versão fixa, listas centralizadas de permissões e revogação rápida.

A Microsoft também deve esclarecer se os arquivos complementares de uma Skill recebem o mesmo escrutínio que seu arquivo principal de instruções. O cenário da PromptArmor dependia de código malicioso incluído, e não apenas de texto enganoso.

Esses sinais fortalecerão ou enfraquecerão o argumento mais amplo em favor de agentes autônomos no ambiente de trabalho. Uma verificação melhor mostraria que os fornecedores estão tratando Skills como componentes executáveis da cadeia de suprimentos.

Visibilidade limitada deixaria os clientes arcando com uma grande parcela do risco. Eles seriam convidados a confiar em um sandbox corrigido sem ver as fronteiras que mudaram.

Para empresas que avaliam o Cowork agora, a resposta prática é uma implantação ponderada. Confirme a mitigação, restrinja quem pode enviar Skills, revise pacotes existentes, minimize o acesso e monitore serviços conectados.

A suposta correção do bypass da sandbox do Microsoft Copilot Cowork não elimina seu alerta arquitetural. Os agentes concentram instruções, código, credenciais e contexto organizacional em um único caminho de execução.

Antes de ampliar a implantação, faça uma pergunta concreta: sua equipe de segurança consegue reconstruir cada Skill, processo, chamada de ferramenta e solicitação externa por trás de uma tarefa concluída? Se a resposta não estiver clara, torne essa visibilidade um requisito antes de conceder acesso mais amplo.