Esta publicação baseia-se na conversa da Mackenzie com Abdel Sghiouar no podcast «The Secure Disclosure». Ouça o episódio completo ou veja-o abaixo.
Se conceder a um agente acesso total ao seu cluster, este poderá rastrear um problema através de todas as camadas da pilha mais rapidamente do que qualquer engenheiro de plantão. Mas é precisamente esse alcance que torna o agente um alvo atraente para ser sequestrado. Retirar-lhe o acesso de escrita impede-o de danificar o cluster, mas um agente apenas de leitura ainda pode ler todos os segredos que o cluster lhe revelar, e um agente sequestrado pode ser levado a divulgá-los.
Abdel Sghiouar trabalha há 13 anos na Google e é atualmente um promotor sénior de desenvolvimento na nuvem, especializado em Kubernetes e tecnologias nativas da nuvem. Ele considera que o termo «injeção de prompts» não abrange todo o âmbito da vulnerabilidade dos agentes. «Envenenamento de prompts» é a expressão que ele prefere utilizar. Mackenzie conversou com ele sobre a segurança dos agentes de IA no Kubernetes e sobre o que muda quando um agente assume o controlo.
A resposta de Abdel é «confiar, mas verificar», embora admita que a questão da confiança continua a ser um problema por resolver.
O que é que um agente de IA pode aceder no seu cluster?
Assim que um agente é envolvido, a primeira questão é saber se este dispõe do nível adequado de permissão. No Kubernetes, isso resume-se ao controlo de acesso baseado em funções (RBAC). Um agente de operações acaba normalmente por ter um acesso de leitura alargado, uma vez que necessita de sinais provenientes de todo o cluster para desempenhar as suas funções, e esse acesso é exatamente o que um atacante procura.
Abdel identifica duas formas pelas quais um atacante pode usar esse acesso contra si. A primeira consiste em adulterar o que o agente lê. Os registos da aplicação são um dos sinais que um agente de operações recolhe; assim, um atacante que consiga inserir texto nesses registos pode fazer com que esse texto apareça no prompt do agente. «A aplicação receberia os dados, gravaria tudo isso no disco e, em seguida, o agente iria lê-los.»
É por isso que Abdel prefere o termo «envenenamento de prompt». A «injeção de prompt» suscita comparações com a injeção de SQL, que pode ser resolvida com consultas parametrizadas, mas um modelo de linguagem de grande dimensão não dispõe de uma forma equivalente de separar as instruções da entrada. Ele processa o prompt do sistema, as instruções do utilizador, o histórico da conversa e tudo o que tiver incorporado no contexto nesse mesmo momento, pelo que uma linha de registo escrita por um atacante pode ter o mesmo peso que uma instrução do operador.
O segundo risco prende-se com o que o agente consegue ler assim que for comprometido. Se as suas permissões abrangerem tudo o que o pod consegue ver, «pode ler secrets, pode ler variáveis de ambiente», e tudo fica exposto no momento em que o agente segue a instrução errada. O «poisoning» permite ao atacante infiltrar-se no agente, e um acesso de leitura excessivamente abrangente determina o quanto este consegue levar consigo.
Por que razão o acesso apenas de leitura não é suficiente
A maioria das equipas que o Abdel viu a utilizar o Kubernetes com agentes inicia-os no modo de leitura apenas. Isso protege o cluster, uma vez que um agente que apenas pode ler não consegue eliminar uma implementação nem esvaziar um nó. E, como a Mackenzie salientou, sem acesso de leitura, o agente é praticamente inútil. Mais importante ainda, um agente de leitura apenas continua a ler o ficheiro « secrets » e continua a recolher qualquer «veneno» que tenha chegado aos registos.
Mackenzie apontou para o mesmo padrão fora do cluster. Aikido A equipa de segurança descobriu uma injeção de prompt (ou envenenamento de prompt) no fluxo de trabalho do GitHub que o Google utiliza para triar problemas no seu repositório Gemini CLI, onde um problema especialmente criado poderia levar o agente a revelar as variáveis de ambiente às quais tinha acesso. A correção do Google impediu o agente de revelar essas variáveis, o que resolveu essa fuga específica, mas deixou o sistema vulnerável ao envenenamento de prompt desde o início.
Na opinião de Abdel, os mecanismos de segurança em que as equipas já confiam «continuam a aplicar-se aos agentes». O que muda é que agora existe um componente a tomar decisões que não se podem aceitar sem mais nem menos. Um modelo de linguagem pode produzir alucinações, pelo que «não se pode confiar totalmente que o raciocínio do agente esteja correto». A sua resposta é «confiar, mas verificar», com um ser humano a intervir para verificar o que o agente faz, embora ele admita abertamente que este é «um dos maiores problemas para o futuro» e algo que a indústria ainda não resolveu.
O papel da Segurança « Aikido »
Aikido pentest de IA permite testar as capacidades de IA. Introduz dados maliciosos através de documentos recuperados e resultados de ferramentas para verificar se algum deles se sobrepõe às instruções do agente e se um agente comprometido pode ser levado a aceder a ferramentas ou sistemas a que não deveria aceder. Também permite saber se o seu agente pode ser persuadido a trabalhar para outra entidade.
O resto depende do alcance que esse agente consegue ter, caso tenha sido comprometido. As verificações de «infraestrutura como código» detetam um ClusterRole ou uma função de gestão de identidades e acessos na nuvem excessivamente abrangente na solicitação de integração, incluindo aquelas que o próprio agente propõe, e a análise «secrets » identifica credenciais codificadas de forma estática antes de estas acabarem numa variável de ambiente que o agente possa ler. A análise de imagens «Container » abrange as cargas de trabalho em que o seu agente confia, bem como a própria imagem do agente, sinalizando pacotes vulneráveis e malware em ambas.
Assim que o agente estiver em execução, Aikido Cloud verifica as permissões de que dispõe, que nem sempre são as que a solicitação de pull concedeu. Identifica ligações RBAC do Kubernetes que conferem ao agente mais acesso do que o necessário para a sua tarefa, e as verificações de postura detetam quando a identidade da carga de trabalho do agente corresponde a uma função na nuvem com direitos de administrador. A análise de acessibilidade e de caminhos de ataque cruza então esses resultados, mostrando quais os que um agente poderia encadear para passar do seu pod para algo relevante, como uma base de dados de produção ou credenciais de administrador da nuvem.
{{cta}}
