Uma revisão de segurança sustenta conclusões sobre o sistema e as condições que examinou. Manter o modelo de um agente não comprova que suas ferramentas, identidades ou acesso a outros sistemas continuam dentro dessas condições.
A resposta adequada a uma mudança de configuração é identificar quais conclusões ainda se aplicam e quais perguntas agora precisam de evidência. Descartar toda a avaliação anterior desperdiça trabalho útil. Levar sua aprovação para um novo escopo de execução sem ressalvas pode atribuir a esse trabalho um significado que ele nunca sustentou.
Uma nova capacidade muda a pergunta
Considere uma avaliação hipotética de um agente de planejamento de eventos configurado para ler calendários e preparar sugestões de agenda. A revisão examina esse arranjo, incluindo as entradas disponíveis e o acesso de leitura. Uma configuração proposta depois acrescenta uma ferramenta que pode alterar convites sob outra identidade executora, mantendo o mesmo modelo.
São condições de uma revisão e de um pedido de mudança imaginados, não uma integração real de produto, um teste executado ou um incidente observado. Não se afirma que a nova ferramenta foi usada. A mudança está no que a configuração proposta poderia fazer e na identidade por meio da qual agiria.
Achados sobre as sugestões de agenda podem continuar relevantes dentro das condições examinadas. Eles não estabelecem quais convites a ferramenta acrescentada pode modificar, de quem é a autoridade usada ou como o destino restringe essas alterações. Essas perguntas estavam fora de uma revisão limitada a ler calendários e produzir sugestões.
O pilar de segurança de agentes de IA fornece o modelo de ameaça mais amplo. Na revisão de uma mudança, a tarefa específica é conectar uma conclusão às capacidades e restrições que permitiam sustentá-la.
Leia uma conclusão junto de suas condições
Um achado precisa de contexto suficiente para que outra pessoa determine onde ele se aplica. No exemplo de planejamento de eventos, isso inclui a tarefa, os dados de calendário disponíveis, as operações expostas, a identidade executora e as permissões no destino relevantes à conclusão. “O modelo foi revisado” não identifica as condições de acesso ao redor dele.
O AI RMF Playbook do NIST recomenda documentar os materiais de avaliação e demonstrar critérios de garantia sob condições semelhantes às de implantação. Também recomenda documentar diferenças entre o ambiente de medição e o de implantação. Esses princípios ajudam a avaliar se as evidências anteriores respondem às questões de uma configuração proposta; não comprovam que qualquer teste descrito neste exemplo ocorreu. NIST AI RMF Playbook, MEASURE 2.1 e 2.3.
Registre os pressupostos que dão sustentação relevante ao achado. Se uma conclusão dependia de permissões somente de leitura, preserve essa condição junto da evidência. Se a revisão não estabeleceu qual identidade uma operação remota usaria, mantenha essa omissão visível. Um fato ausente não se torna uma restrição verificada apenas por não aparecer no relatório.
Preserve as evidências que continuam aplicáveis
A avaliação anterior pode continuar sendo uma referência útil. Seus achados sobre o comportamento nas entradas examinadas ainda descrevem aquela avaliação. A possibilidade de sustentarem uma previsão sobre a configuração alterada depende do que mudou e dos pressupostos usados pelo achado. Uma nova ferramenta não invalida automaticamente toda observação do modelo, mas pode alterar as decisões ou o contexto que o agente encontra.
Separe um fato que não mudou de uma conclusão que dependia de uma restrição anterior. Neste exemplo, manter o modelo é um fato inalterado. Uma afirmação sobre os efeitos disponíveis ao agente com acesso somente de leitura dependia da ausência de um caminho de escrita. Acrescentar uma operação de edição de convites muda essa base antes mesmo de alguém observar uma alteração indesejada.
O esforço de revisão deve acompanhar essa dependência. Estabeleça os alvos permitidos, a identidade executora e o comportamento dos controles da nova operação; retome a avaliação do modelo ou do fluxo quando a nova capacidade mudar as perguntas que essas avaliações precisam responder. Essa é uma proposta para delimitar a avaliação adicional, não uma afirmação de que toda mudança exige a mesma bateria de testes ou de que componentes inalterados dispensam revisão.
O pilar de governança de agentes de código aplica uma distinção relacionada a workspaces e runners. A lição geral para uma avaliação é preservar as evidências com suas condições, sem tratar o nome de um modelo ou uma aprovação anterior como a fronteira do sistema.
Revise a fronteira em que a autoridade mudou
Um agente pode atravessar várias fronteiras de confiança: do ambiente de execução para um serviço de ferramenta, desse serviço para um destino e do material retornado para seu contexto de trabalho. A fronteira de segurança discutida aqui inclui essas relações. Não é um perímetro único que envolve o modelo e torna irrelevante tudo o que está fora dele.
No exemplo de agenda, identifique onde a operação de convite recebe permissão para agir e quais recursos de calendário essa permissão alcança. Uma restrição no processo local do agente não estabelece as permissões de um serviço remoto que atua sob identidade própria. Se MCP fornecer a interface da ferramenta, o guia de segurança e governança de MCP explica por que o acesso ao servidor e a autorização no destino precisam ser examinados separadamente.
A orientação da OWASP sobre Excessive Agency relaciona os riscos de aplicações baseadas em LLM às funções disponíveis, permissões, autonomia e sistemas conectados. Ela recomenda limitar permissões e aplicar autorização no destino. Isso sustenta o exame da aplicação ao redor do modelo; não implica que todo agente use um LLM ou que a mudança hipotética tenha causado dano. OWASP Excessive Agency.
As pessoas que controlam a ferramenta, a credencial e o destino precisam fornecer as evidências pertinentes. Uma avaliação empresarial pode coordenar essas contribuições sem presumir que uma única equipe controla todos os componentes. O pilar de segurança de IA empresarial explica como conectar a proteção de recursos a responsáveis capazes de agir.
Escreva uma conclusão que a próxima revisão possa usar
Para a mudança proposta no planejamento de eventos, a revisão deve identificar a operação e a identidade acrescentadas, os achados anteriores preservados dentro de seu escopo e as novas perguntas que foram ou não resolvidas. Uma conclusão pode ser restrita e útil. Ela não precisa declarar todo o agente seguro nem toda a avaliação anterior obsoleta.
Quando uma avaliação adicional for realizada, diferencie o que foi inspecionado, testado ou inferido. Evidências de permissão podem estabelecer quais calendários uma identidade pode modificar sem comprovar como a ferramenta aplica uma decisão de política. Um teste bem-sucedido de uma edição permitida não estabelece o comportamento de todos os caminhos de negação ou exceção. Mantenha esses limites junto da afirmação resultante.
Aplique a mesma disciplina ao avaliar o Kona for Agents. Defina em conjunto a configuração do agente, as integrações e as questões de segurança em análise; depois avalie o que as evidências disponíveis estabelecem para esse arranjo. Uma revisão se torna reutilizável quando seus pressupostos e limites são claros o suficiente para comparar com a próxima mudança.