A responsabilidade está sendo transferida para os utilizadores
Com a adoção acelerada de inteligência artificial no ambiente corporativo de TI, ganha força um paradoxo: as mesmas soluções vendidas como defesa contra ciberameaças podem introduzir novas vulnerabilidades. Para agravar, desenvolvedores têm classificado esses problemas cada vez mais não como falhas, mas como “comportamento esperado”.
Esse posicionamento vem deixando de ser exceção e passa a parecer regra. As empresas são incentivadas a usar IA para identificar ataques, automatizar a proteção e administrar infraestrutura. No entanto, quando fragilidades aparecem dentro dos próprios instrumentos de segurança e automação, frequentemente não há correção de fato - no máximo, surgem atualizações na documentação.
Exemplo com agentes de IA: GitHub Actions, Claude, Gemini e Copilot
Um caso ilustrativo é um estudo recente que mostrou como agentes de IA populares, integrados ao GitHub Actions, podem ser comprometidos. Entre os alvos estavam o Claude Code Security Review, da Anthropic, o Gemini CLI Action, do Google, e o GitHub Copilot, da Microsoft. As brechas permitiam que atacantes roubassem chaves de API e tokens de acesso.
As empresas confirmaram os achados e pagaram recompensas, mas a resposta foi limitada. A Anthropic pagou $100 e atualizou a secção de “considerações de segurança”; o Google pagou $1,337; e o GitHub, após recusar inicialmente, reconheceu o problema e pagou $500. Ainda assim, nenhuma delas atribuiu às vulnerabilidades identificadores oficiais CVE (Common Vulnerability Exposures Scoring, sistema que dá às vulnerabilidades uma nota de risco de 0 a 10) e tampouco publicou alertas públicos.
MCP (Model Context Protocol) da Anthropic: risco “de fábrica” em grande escala
Um episódio potencialmente mais grave envolve a própria arquitetura do Model Context Protocol (MCP), criado pela Anthropic. Segundo a avaliação de pesquisadores, o princípio de funcionamento adotado no protocolo pode, “de fábrica”, colocar em risco até 200 mil servidores. Apesar de várias tentativas de contacto, a empresa recusou alterar o mecanismo base, afirmando que ele “funciona como foi concebido”.
O cenário piora porque a vulnerabilidade é descrita como sistémica. Embora já existam pelo menos dez CVE (para ferramentas específicas) com níveis alto e crítico de severidade, a causa raiz continua sem mudanças. De acordo com os pesquisadores, corrigir esse ponto reduziria o risco para programas cuja soma de downloads ultrapassa 150 milhões.
Na prática, a responsabilidade pela segurança desses sistemas é deslocada para desenvolvedores e para utilizadores corporativos - incluindo todos os que usam o SDK do MCP ou incorporam ferramentas de IA em produtos e infraestrutura.
Falta de regras claras e impacto na confiança
Tudo isso acontece num contexto de ausência de exigências regulatórias bem definidas. Nos Estados Unidos, continua a não existir um sistema federal completo de controlo da segurança de desenvolvimentos em IA. Isso ocorre mesmo com declarações das próprias empresas sobre riscos potenciais das suas tecnologias: por exemplo, a Anthropic já afirmou anteriormente que um dos seus modelos é eficiente demais na busca por vulnerabilidades para estar disponível abertamente.
Pesquisadores observam que a indústria esbarra numa dificuldade fundamental: sistemas de IA complexos e não determinísticos são difíceis de tornar totalmente seguros. Ainda assim, a prática atual - em que os riscos são reconhecidos, mas não eliminados - corrói a confiança nessas tecnologias.
À medida que a dependência do setor empresarial em IA aumenta, a discussão sobre quem responde pelo seu comportamento torna-se central. E, se a lógica de “não é bug, é característica” continuar, as consequências podem extrapolar, em muito, incidentes isolados de segurança.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário