A segurança de agentes de IA protege os dados, ferramentas, identidades e recursos disponíveis a um agente contra uso indevido e efeitos não autorizados. Ela examina tanto o que pode influenciar o agente quanto o que o sistema ao redor permite que ele faça.
A governança de agentes de IA define a autoridade delegada e as responsabilidades por controlá-la. A segurança acrescenta o modelo de ameaça: como essa autoridade poderia ser usada indevidamente, quais ativos poderiam ser afetados e onde uma restrição independente pode limitar o efeito. Uma instrução que muda o comportamento do modelo não precisa criar novos privilégios se uma ferramenta com capacidades excessivas ou uma credencial poderosa já estiver disponível.
Comece por um ativo e uma tarefa delimitada
Exemplo hipotético: um assistente de armazenamento está autorizado a preparar um relatório de capacidade a partir de registros de uso e chamados de suporte relacionados. Um dos chamados recuperados contém uma instrução, controlada por uma pessoa mal-intencionada, para excluir snapshots de recuperação em um ambiente de produção. A tarefa atribuída autoriza análise, não exclusão.
Suponha que o runtime também disponibilize uma ferramenta de manutenção e uma credencial de serviço capazes de excluir esses snapshots. Elas excedem o que a tarefa de elaboração do relatório exige. O efeito indesejado depende do caminho entre o texto recuperado e uma operação proposta, da autoridade disponível e do componente que poderia executar a mudança. Esse é um projeto hipotético, não um incidente, uma integração de produto ou um resultado de teste.
| Elemento do modelo de ameaça | Escopo no exemplo hipotético |
|---|---|
| Ativo | Snapshots de recuperação e as opções de recuperação que dependem deles |
| Origem da ameaça | Uma pessoa que pode influenciar um chamado recuperado pelo assistente |
| Ponto de entrada | Conteúdo do chamado incluído como contexto para preparar o relatório |
| Limite de confiança | Material de referência tratado como autoridade para alterar recursos de produção |
| Capacidade disponível | Uma operação de manutenção e uma credencial que podem solicitar exclusão |
| Efeito a restringir | Exclusão fora da tarefa aprovada e do processo de mudança |
O impacto precisa ser avaliado conforme o projeto real de recuperação. Um snapshot não comprova a existência de um backup suficiente, e excluí-lo não estabelece que a recuperação seja impossível. Identifique quais opções de recuperação seriam perdidas, quais cópias independentes existem e o que o sistema de armazenamento realmente permite. O modelo de ameaça deve tornar essas dependências visíveis, em vez de inventar uma severidade a partir da palavra “excluir”.
Separe prompt injection da autoridade para agir
Prompt injection tenta redirecionar o comportamento de uma aplicação com modelo de linguagem por meio de instruções presentes em uma entrada ou em material externo. O Prompt Injection Prevention Cheat Sheet da OWASP, em inglês distingue entradas diretas de instruções indiretas incorporadas a conteúdos como documentos, chamados ou resultados de ferramentas. Uma fonte recuperada pode ser relevante para a tarefa sem estar autorizada a redefini-la.
No exemplo de armazenamento, o chamado malicioso tenta transformar uma evidência para o relatório em uma instrução de manutenção. Receber esse texto, propor uma exclusão e excluir um snapshot são eventos diferentes. Uma revisão de segurança precisa estabelecer quais deles ocorreram. A presença de uma tentativa de injeção não comprova que ela influenciou o agente nem que produziu um efeito externo.
Preserve a distinção entre instruções confiáveis da tarefa e conteúdo externo, e examine as ações propostas depois que esse conteúdo é processado. A triagem de conteúdo pode contribuir com um sinal. Ela não determina se uma identidade de serviço específica deveria poder excluir um recurso de produção. Um modelo usado para examinar a entrada de outro modelo também precisa ser avaliado; ele não se torna um limite confiável de autorização apenas por receber o nome de guardrail.
A mesma preocupação se estende ao contexto armazenado. Se material não confiável for retido como instrução futura ou misturado ao contexto de trabalho de outro usuário, sua influência pode persistir além da consulta original. Revise onde o contexto é salvo, quem pode modificá-lo e quais tarefas posteriores podem consumi-lo. O AI Agent Security Cheat Sheet da OWASP, em inglês identifica o envenenamento de memória e o isolamento de contexto como questões de segurança de agentes.
Reduza as capacidades das ferramentas e as permissões excessivas
Uma ferramenta é um caminho para produzir um efeito. Revise as operações disponíveis e a autoridade que ela exerce, além de seu nome de exibição. A OWASP descreve Excessive Agency, em inglês, em termos de excesso de funcionalidades, permissões ou autonomia, incluindo danos provocados por saídas equivocadas ou manipuladas do modelo. Os controles de segurança devem tratar ações indesejadas mesmo quando não há prova de intenção maliciosa.
Para o assistente de relatórios, remover a exclusão do conjunto de ferramentas reduz as operações que ele pode solicitar por essa interface. Restringir a credencial do destino às leituras necessárias ao relatório limita o que ela pode fazer. Esses controles atuam em pontos diferentes. Um botão de manutenção oculto não é suficiente se o mesmo runtime ainda consegue invocar a operação por um cliente de API genérico ou pelo shell.
Revise as operações junto com seus alvos e argumentos. Uma função de manutenção pode ser apropriada em um ambiente e proibida em outro. Um identificador de recurso válido e uma solicitação bem formada estabelecem que a operação é compreensível para a API, não que a tarefa de elaboração do relatório a autoriza. Validação de argumentos e autorização de negócio respondem a perguntas diferentes.
A autorização no destino deve restringir o acesso do chamador de forma independente. A orientação da OWASP sobre excessive agency recomenda aplicar a autorização nos sistemas de destino, em vez de confiar no modelo para decidir o que é permitido. Um destino pode aceitar legitimamente uma credencial de serviço poderosa enquanto a ação proposta ainda excede a tarefa do usuário. Reduza essa diferença de escopo, em vez de interpretar uma autorização bem-sucedida na API como prova de comportamento apropriado do agente.
Proteja dados e credenciais fora do prompt
Um agente pode expor informações por uma resposta gerada, argumentos de ferramenta, um arquivo que escreve ou uma solicitação a outro serviço. A modelagem de ameaças precisa identificar as informações, seu público permitido e os caminhos pelos quais elas poderiam sair desse escopo. Limitar a resposta final no chat não restringe necessariamente uma ferramenta que já transmitiu o mesmo conteúdo.
Diferencie a exposição de uma credencial de seu uso. O modelo não precisa ver um token de serviço para induzir uma ferramenta a agir com as permissões desse token. Por outro lado, uma credencial copiada para o contexto, um arquivo gerado ou um registro de atividade pode criar outro caminho de exposição. Revise onde os segredos são obtidos e mantidos, quais processos podem lê-los e quais operações autorizam. Uma referência à credencial é preferível a copiar seu valor para as evidências.
Minimize o material sensível disponibilizado à tarefa. Para o relatório de capacidade, registros agregados de uso podem ser suficientes; acessar o conteúdo dos documentos armazenados exige outra justificativa. Se o fluxo pode enviar relatórios para outros locais, identifique o destino permitido e o escopo dos destinatários. Um domínio aprovado, isoladamente, pode não identificar a conta, a pasta ou o público permitido dentro daquele serviço.
Os sistemas de governança e monitoramento também processam dados. Reter prompts, entradas de ferramentas e respostas completas pode criar cópias adicionais de informações restritas. Defina o que uma investigação precisa, quem pode acessar esse material e por quanto tempo ele deve permanecer disponível. Coletar mais conteúdo não produz automaticamente uma explicação melhor de um ataque.
Trate o acesso ao shell e ao sistema de arquivos como capacidades
Uma interface de shell genérica pode expor mais operações do que uma ferramenta específica para a tarefa. Seu alcance efetivo depende das permissões do processo, dos programas disponíveis, das credenciais, dos sistemas de arquivos montados e do acesso à rede. Para o assistente de armazenamento, bloquear uma ferramenta de manutenção deixaria uma lacuna se o mesmo processo de shell permitido pudesse chamar a API de armazenamento com uma credencial capaz de excluir recursos.
Revise separadamente leitura, escrita, exclusão e execução de arquivos. Uma tarefa que pode criar um relatório não deveria adquirir acesso irrestrito a arquivos não relacionados apenas porque ambas as operações usam o mesmo sistema de arquivos. Na governança de agentes de código, examine os scripts e o conteúdo do repositório que os comandos vão consumir. Permissão para chamar um comando conhecido não estabelece que toda versão do script referenciado seja apropriada.
O isolamento reduz somente as capacidades que sua configuração realmente exclui. Um sandbox com um diretório compartilhado gravável ou uma credencial de produção disponível ainda pode permitir efeitos por esses recursos. Verifique os sistemas de arquivos montados, a identidade do processo, os caminhos de rede e os serviços alcançáveis conforme a tarefa pretendida. Não use a existência de um sandbox como substituto para examinar seus limites.
Revise servidores MCP e ferramentas de terceiros como dependências
O MCP oferece um protocolo pelo qual uma aplicação pode obter contexto e chamar ferramentas. A avaliação de segurança ainda precisa identificar o servidor real, a implementação da ferramenta, os dados retornados e as credenciais usadas. Um servidor pode fornecer informações ao modelo e participar de operações contra outros sistemas; por isso, revise os dois sentidos dessa relação.
A especificação de ferramentas do MCP, em inglês exige validação de entradas e controles de acesso no servidor. Ela também trata as anotações das ferramentas como não confiáveis, a menos que venham de servidores confiáveis. Uma descrição que chama a ferramenta de “somente leitura” não é evidência suficiente de seu comportamento. Revise a implementação e as permissões relevantes para a operação, incluindo os sistemas de destino que ela pode alcançar.
A especificação de autorização do MCP, em inglês define um fluxo de autorização HTTP; o suporte é opcional nas implementações MCP, e esse fluxo não é o modelo de credenciais de STDIO. Uma conexão autenticada a um servidor não autoriza, por si só, toda ação de negócio exposta por ele. Verifique a identidade e as permissões que se aplicam quando o servidor realiza a operação externa.
Trate uma mudança em ferramenta de terceiros como uma possível mudança no modelo de ameaça. Uma nova operação, credencial mais ampla, destino diferente ou alteração no conteúdo das respostas pode mudar o risco mesmo que o nome da ferramenta exibido ao usuário continue igual. Revise como atualizações são selecionadas e introduzidas, e mantenha um registro da versão e configuração realmente avaliadas. Uma aprovação anterior não é evidência sobre uma substituição que não foi examinada.
O guia de segurança e governança de MCP acompanha essas relações em uma consulta hipotética de inventário, separando o acesso ao servidor da permissão para consultar um registro específico.
Combine controles de política com uma revisão que possa rejeitar
Uma verificação de política deve avaliar a operação proposta conforme os efeitos permitidos à tarefa, usando fatos que consiga estabelecer. No exemplo de armazenamento, excluir recursos de produção está fora da tarefa de elaboração do relatório, por mais persuasivo que seja o chamado sobre a necessidade de limpeza. O avaliador precisa do alvo, da operação, da identidade executora e da delegação; a descrição que o próprio modelo faz da ação não é suficiente.
Algumas mudanças exigem julgamento de uma pessoa autorizada. Se a organização decidir considerar a remoção de snapshots, a proposta deve entrar no processo apropriado de aprovação de manutenção, com os recursos afetados e as consequências para a recuperação visíveis. Essa é uma decisão diferente de aprovar o relatório de capacidade. Não deixe que uma alegação de urgência do agente transforme a revisão em aceitação automática.
O revisor deve ter evidências independentes da fonte questionável, como o inventário real de recursos e a política de mudanças aplicável. Apresente a ação que seria executada, além do resumo do agente sobre por que ela parece segura. A revisão precisa poder rejeitar uma solicitação ou deixá-la sem resolução. A aprovação só tem valor quando o executor respeita seu escopo.
O comportamento em falhas faz parte da avaliação do controle. Se uma verificação ficar indisponível, determine quais operações continuam possíveis e qual autorização ainda é necessária. O pilar de governança em runtime explica os contratos de validade, aplicação e falha da decisão. O guia de arquitetura mostra como essas responsabilidades atravessam os limites entre componentes.
Use a observabilidade para investigar a tentativa completa
As evidências de segurança devem ajudar a distinguir tentativa de influência, proposta alterada, uso de uma capacidade e efeito resultante. Para o cenário de armazenamento, uma investigação útil conectaria o chamado recuperado, a operação proposta, a resposta de política, o comportamento do executor e qualquer resultado observado no armazenamento. Esses são requisitos de evidência para o caso hipotético, não registros coletados de um incidente real.
Um alerta sobre o chamado pode indicar instruções suspeitas. Uma resposta de negação ao uso de ferramenta pode indicar que um adaptador emitiu uma negativa. Nenhum desses fatos, isoladamente, estabelece que outro caminho não executou a exclusão. Investigue a operação e os limites realmente cobertos, e mantenha como desconhecidos os resultados não observados.
Preserve informações de origem suficientes para examinar uma fonte suspeita ou uma mudança de ferramenta, minimizando o conteúdo sensível no registro. Identifique quem pode revisar as evidências e tomar providências. Se for necessário conter a atividade, isso pode envolver a conta, a ferramenta, o processo ou o destino subjacentes, além de encerrar uma conversa. Essas ações exigem autoridade e verificação próprias; um alerta não comprova contenção.
Valide os controles com base no modelo de ameaça
Use um ambiente controlado e recursos sintéticos para verificar se a tarefa permitida de elaboração do relatório continua funcionando e se a exclusão fora do escopo é restringida. Examine uma instrução em material recuperado, uma operação proibida proposta, uma credencial com permissões além do necessário e uma verificação de política indisponível. Inspecione o comportamento real do executor e do destino, além do texto da resposta do modelo. Esses são casos de validação propostos; nenhum ataque ou teste de produto foi executado para esta página.
Registre o que foi testado, quais caminhos de entrada e operação foram cobertos e o que permanece incerto. Reavalie o modelo quando o conjunto de ferramentas, as credenciais, as fontes de dados ou o ambiente de execução mudar. O resultado de um detector pode ser uma evidência útil para as entradas testadas sem estabelecer que todo caminho para um efeito não autorizado está controlado.
A análise sobre a fronteira de segurança de um agente explica como preservar os achados anteriores dentro de suas condições ao avaliar uma ferramenta ou identidade alterada.
Como a KonaSense contribui para a avaliação de segurança
Na implementação Claude Code PreToolUse revisada para o Kona for Agents, uma operação de ferramenta proposta pode ser submetida à avaliação de política. O adaptador pode retornar uma negativa, um pedido de aprovação ao usuário ou argumentos de ferramenta alterados. O caminho de erro de avaliação retorna Allow. O efeito disponível precisa ser avaliado para esse hook e para o comportamento do host instalado.
Esses mecanismos podem contribuir com uma decisão em um ponto de runtime compatível. Eles não comprovam o isolamento do sistema de arquivos, as restrições de credenciais ou a autorização no destino do ambiente em que a integração está instalada. O cenário de snapshots não afirma uma integração de armazenamento suportada nem a detecção verificada de sua instrução maliciosa.
Avalie a integração instalada junto com as ferramentas, identidades, acessos a dados e controles de destino do agente. A questão relevante é qual parte do caminho modelado cada mecanismo consegue restringir e quais evidências comprovam essa restrição para a operação pretendida.