A segurança da IA é um desafio em tempo real para todos, inclusive para o Google

Recentemente, tive a oportunidade de conversar com Francis de Souza, diretor de operações (COO) do Google Cloud, nos bastidores de um evento em Los Angeles. Em meio ao barulho ao redor, de Souza — que fala com o tom calmo e ponderado de um professor universitário — ofereceu orientações práticas para empresas que estão lidando com o cenário atual de segurança em IA. Ele observou: “Haverá um período de transição e, depois disso, acredito que chegaremos a um ponto melhor”.

Ele não estava se referindo especificamente ao Google naquele momento, mas fica claro que até mesmo o Google ainda está lidando com esses desafios.

A mensagem central de De Souza é aquela que os profissionais de segurança há muito tentam transmitir aos executivos, e que agora se tornou urgente devido à IA: a segurança não pode ser uma preocupação secundária. “À medida que as empresas embarcam nessa jornada da IA, elas precisam adotar uma abordagem de plataforma”, disse ele. “Segurança não é algo que se possa acrescentar depois, nem algo que se possa deixar a cargo dos funcionários para que eles cuidem por conta própria.” Ele alertou especificamente sobre a “IA paralela” — funcionários que usam ferramentas de consumo sem supervisão da organização — e argumentou que as empresas devem exigir segurança, governança e auditabilidade de suas plataformas desde o início. “Não existe estratégia de IA sem uma estratégia de dados e uma estratégia de segurança. Elas precisam andar de mãos dadas.”

Vale ressaltar: ele não estava promovendo apenas o Google Cloud. Quando eu comentei que seu conselho parecia um anúncio do Google, ele rebateu. O Google, disse ele, está comprometido com uma abordagem multicloud, e argumentou que as empresas que acham que estão operando em uma única nuvem quase certamente não estão. “Mesmo que optem por uma única nuvem, elas dependem de aplicativos SaaS, e há parceiros de negócios que podem estar usando nuvens diferentes”, disse ele. “É importante que as empresas tenham uma postura de segurança consistente entre as nuvens e entre os modelos.”

Ele também argumentou que o cenário de ameaças mudou de forma tão fundamental que os antigos modelos defensivos são lentos demais. Ele observou que o tempo médio entre uma violação inicial e a transição para a próxima etapa de um ataque caiu de oito horas para 22 segundos, e que a superfície de ataque se expandiu para além do perímetro tradicional da rede. “Além de sua infraestrutura habitual, agora você tem modelos. Você tem pipelines de dados usados para treinar os modelos. Você tem agentes, você tem prompts. Tudo isso precisa ser protegido.”

Uma ameaça apontada por de Souza que não recebe atenção suficiente: agentes que se movimentam pelos sistemas internos de uma empresa podem revelar repositórios de dados esquecidos, nos quais ninguém pensava há anos. “Muitas organizações têm servidores SharePoint antigos [e controles de acesso] que não foram realmente atualizados, mas isso não importava porque ninguém sabia ao certo onde eles estavam. Porém, agentes que circulam pela sua empresa encontrarão esses ativos de dados e os exporão.”

A solução, na opinião dele, é combater a velocidade das máquinas com a velocidade das máquinas. “Estamos vendo agora o surgimento de uma defesa totalmente baseada em agentes e nativa de IA, na qual as organizações podem executar agentes que conduzem sua defesa”, disse ele. “Em vez de ter uma defesa liderada por humanos ou mesmo com a participação humana no processo, agora é possível ter pessoas supervisionando uma defesa totalmente baseada em agentes.” Ele acrescentou que isso se tornou uma questão de liderança, não apenas uma questão tecnológica. “Essa é uma questão para o conselho administrativo e para a equipe executiva. Não é apenas uma questão da equipe de segurança.”

Mas, mesmo com a IA assumindo cada vez mais a carga de trabalho defensiva, há escassez de pessoas qualificadas para supervisioná-la — e as vulnerabilidades que a própria IA está introduzindo estão se multiplicando mais rápido do que as equipes de segurança conseguem resolvê-las. “Vamos precisar de pessoas para lidar com o ‘bug-pocalipse’”, disse Lea Kissner, diretora de segurança da informação do LinkedIn, ao *New York Times* nesta semana, acrescentando que não espera que o setor compreenda a segurança da IA de forma sustentável a longo prazo por pelo menos vários anos.

O que nos leva de volta aos próprios provedores de plataforma. O The Register publicou uma série de reportagens nas últimas semanas documentando uma onda de desenvolvedores do Google Cloud que receberam contas de cinco dígitos após chamadas de API não autorizadas para modelos do Gemini — serviços que muitos deles nunca haviam usado ou ativado intencionalmente. Os casos seguiram um padrão familiar: chaves de API originalmente implantadas para o Google Maps, disponibilizadas publicamente de acordo com as próprias instruções do Google, passaram discretamente a ter acesso ao Gemini depois que o Google ampliou seu escopo sem divulgar claramente a mudança.

Rod Danan, CEO da plataforma de preparação para entrevistas Prentus, disse que sua conta chegou a US$ 10.138 em cerca de 30 minutos depois que invasores exploraram sua chave de API comprometida. Isuru Fonseka, um desenvolvedor de Sydney cuja conta foi comprometida de forma semelhante, acordou com cobranças de aproximadamente AUD $17.000, apesar de acreditar que tinha um limite de gastos de $250 definido. O que nenhum dos dois sabia era que os sistemas automatizados do Google haviam atualizado seus níveis de cobrança com base no histórico das contas, elevando seus limites efetivos para até US$ 100.000 sem consentimento explícito.

O Google reembolsou ambos depois que o The Register publicou sua reportagem inicial. Ainda assim, o Google informou ao The Register que não tem planos de alterar sua política de aumento automático de níveis, afirmando que prioriza a prevenção de interrupções no serviço em detrimento da aplicação das preferências orçamentárias declaradas pelos usuários.

Enquanto isso, há a questão separada do que acontece quando um desenvolvedor tenta desativar os serviços. O The Register noticiou esta semana uma pesquisa da empresa de segurança Aikido que constatou que mesmo desenvolvedores que detectam uma chave comprometida e a excluem imediatamente podem não estar a salvo. De acordo com as descobertas da Aikido, os invasores aparentemente podem continuar usando essa chave por até 23 minutos, pois a revogação do Google se propaga gradualmente por toda a sua infraestrutura. O pesquisador da Aikido, Joseph Leon, disse ao The Register que, durante esse intervalo, as taxas de sucesso são imprevisíveis — em alguns minutos, mais de 90% das solicitações ainda são autenticadas — e os invasores podem usar esse tempo para extrair arquivos e dados de conversas armazenados em cache do Gemini.

Leon também observou que os formatos de credenciais mais recentes do próprio Google não parecem apresentar o mesmo problema: as credenciais de API de contas de serviço são revogadas em cerca de cinco segundos, e o formato de chave mais recente do Gemini, com o prefixo AQ, leva cerca de um minuto. “Ambos operam na escala do Google”, escreveu ele no artigo relacionado do Aikido. “Ambos sugerem que isso também é tecnicamente solucionável para as chaves de API do Google.” Em resumo, segundo Leon, a janela de 23 minutos não é uma restrição de engenharia, mas uma questão de prioridades para a empresa.

Vale a pena levar isso em consideração ao ler o conselho de Souza, que é válido e deve ser levado muito a sério. Ele não está errado, mas atualmente há uma discrepância entre o que as plataformas estão recomendando e a rapidez com que elas mesmas estão se adaptando, e é bom estar ciente disso também.