Riscos de segurança do agente AI: criar um Ledger de ameaças operacionais

A forma prática de lidar com os riscos de segurança dos agentes AI é a modelagem de ameaças de cada operação de efeitos colaterais antes da chamada de ferramenta. Registre quais ativos podem ser alterados, qual a autoridade de identidade fornecida, quais os escopo são necessários, de onde veio a instrução, como o efeito será limitado e quais as evidências tornam uma nova tentativa segura. Se algum campo for desconhecido, pare naquela fronteira em vez de pedir ao modelo para inferir permissão. Isto produz uma decisão útil, não outra lista de riscos. O operador pode prosseguir, restringir uma credencial, remover permissões excedentes, rever uma instrução não confiável, definir um limite de efeito ou reconciliar um resultado ambíguo antes de retomar. Uma resposta válida não é suficiente: a segurança depende da autoridade utilizada e do efeito externo produzido. A ameaça modelo da operação, não só o modelo Um agente é mais do que um LLM. Ele une um modelo, tempo de execução, credenciais, ferramentas, conteúdo externo e sistemas de destino em um único caminho de ação. O Segurança do papel AI Agentes torna esta distinção explícita: os agentes usam ações geradas por modelos para invocar ferramentas que podem afetar sistemas reais, criando preocupações de confidencialidade, integridade e disponibilidade além do alinhamento do modelo. Comece com uma operação proposta e trace quatro limites: 1. Fonte de instrução: Intenção do usuário, conteúdo recuperado, saída da ferramenta e memória entram no contexto do modelo. 2. AFonte de autoridade: o tempo de execução atribui uma identidade ou credencial à chamada de ferramenta proposta. 3. E Limite de efeito: a ferramenta pode ler ou alterar um recurso externo. 4. Retry boundary: Os resultados incertos de transporte ou de ferramentas podem fazer com que o tempo de execução repita um efeito. O Iniciativa de Segurança Agencial da OWASP descreve a sua orientação como uma referência baseada em um modelo de ameaça para os riscos agentes emergentes. Esta é a postura correta de partida: identificar ativos, atores, mudanças de confiança e possíveis efeitos antes de escolher controles. Use um livro de risco de nível de execução em vez de notas de forma livre: Não coloque valores secretos no livro. Referências de armazenamento, identificadores de emissor e público, expiração, escopo, identidade de operação e locais de evidência. O artefacto deve responder: "O que pode mudar, sob a autoridade de quem e como saberemos?" sem se tornar outro vazamento de credenciais. O padrão razoável é criar uma linha do livro de conta por operação externa. Um modelo geral de ameaça de nível de agente ainda ajuda com a arquitetura, mas não pode dizer lhe se esse pagamento em particular, mensagem, libertação ou mutação de arquivo é seguro agora. Verificar a identidade das credenciais antes de verificar o pedido Uma credencial não é segura apenas porque autentica. Para cada operação, registar: Quem ou o que representa a credencial; Onde foi emitida e onde pode ser apresentada; Se é compartilhada entre agentes ou ambientes; O seu caminho de expiração e revogação; O público de recursos exato; uma referência não secreta que permita ao operador girá la. O Especificação da autorização do MCP de junho de 2025 é concreto sobre o limite HTTP. Os clientes incluem um indicador de recursos, os servidores validam que um token foi emitido para o público pretendido, e uma autorização inválida ou insuficiente recebe um erro. O relacionado Orientações para a segurança dos PCM proíbe a passagem de tokens e explica por que a confusão do público enfraquece os limites de controle, atribuição e confiança. As referidas regras aplicam se diretamente às autorizações HTTP MCP. O princípio operacional também funciona bem: nunca deixe um símbolo opaco permanecer silenciosamente em cada destino. Um token de administrador compartilhado sem proprietário de tarefa e sem público estreito pode funcionar perfeitamente enquanto destrói a atribuição e amplia o raio da explosão. A segurança da instrução e a saúde credenciais são separadas. Um prompt limpo não pode reparar um token expirado, e um token válido não torna uma instrução não confiável legítima. Verifique a evidência de credenciais primeiro porque cada controle posterior depende de saber qual identidade atravessará o limite da ferramenta. Quando faltam evidências, use stop credential , não probablemente autorizado. A reparação é mecânica: emitir uma credencial de curta duração e revocavel para o agente exato, tarefa, público e ambiente. Mantém o modelo fora dessa decisão. Compare permissão exigida com permissão concedida O mínimo privilégio só se torna testável quando se comparam dois conjuntos para uma operação: Se o surplus não estiver vazio, interromper e substituir a concessão. Uma ferramenta autorizada não é suficiente. O mesmo cliente de ferramentas pode levar escopo não relacionado ao trabalho atual, e essas permissões adormecidas ficam disponíveis quando o contexto é envenenado, um argumento de ferramenta é substituído, ou o modelo simplesmente escolhe a operação errada. Rejeitar também os escopes necessários faltantes. Esse caso é geralmente menos perigoso do que o excedente de autoridade, mas cria retos ruidosos e incentiva soluções inseguras, como a troca de uma credencial mais ampla. Uma descoincidência de permissão deve produzir um estado explícito e uma reparação, não um convite para o agente caçar segredos mais fortes. Os controlos de autorização precisam de uma descrição dos efeitos. Usar a ferramenta do repositório é muito ampla; Criar um candidato a liberação no repositório X fornece um limite de recursos e impacto. Se for necessário, vincular a aprovação à descrição congelada. A revisão humana é valiosa para operações de alto impacto ou sem confiança, mas não se deve pedir a uma pessoa que aprova uma ação que ainda tenha recursos não identificados ou efeitos ilimitados. É aqui que um modelo de ameaça difere de uma implementação de guarda. O registro de ameaças identifica a autoridade e o efeito que exigem proteção. Política, aprovação, sandboxing e verificação são controles selecionados posteriormente. Começar com controles sozinhos muitas vezes deixa equipes protegendo o prompt enquanto uma credencial dominada permanece inalterada. Tratar instruções, efeitos e retestes como riscos separados O conteúdo externo pode influenciar um agente sem se tornar autoridade. A origem da instrução é marcada como trusted , untrusted external content ou mixed . Se o conteúdo não confiável contribuir para uma ação de efeitos colaterais, congelar o recurso e os argumentos propostos, então exigir uma decisão de política ou revisão humana fora desse caminho de conteúdo. Não resolva isto excluindo todas as instruções externas. Um agente pode precisar de documentos recuperados ou de ferramentas de saída para trabalhar. O limite de segurança é se esse conteúdo pode silenciosamente escolher um efeito privilegiado. Uma análise de somente leitura e um envio de mensagem pública não devem ter a mesma regra de revisão. Em seguida, define o efeito independentemente da resposta da ferramenta: recurso de destino exato; Número máximo ou tamanho máximo de alterações; Reversibilidade e proprietário de retrocesso; Identidade de operação estável; Uma leitura de dados ou outra evidência de resultados autorizada. Os retries merecem sua própria linha porque um timeout não significa que não aconteceu nada. O AWS Builders Guia de biblioteca sobre APIs idempotentes mostra como um identificador de solicitação de cliente estável pode tornar repetidas solicitações semânticamente equivalentes. Esse contrato suporta tentativas de segurança por defeito. Não autoriza a ação original e não ajuda se o runtime gerar um novo identificador para a segunda tentativa. Após um intervalo ambíguo, use esta ordem: 1. manter a identidade original da operação; 2. consultar o destino autorizado; 3. Classificar o efeito como presente, ausente, parcial ou desconhecido; 4. Só se o contrato garantir a segurança de outra tentativa; 5. Verificar o resultado prometido após a tentativa final. Se o destino não oferecer nem idempotencia nem efeito de busca, o estado correto é reconcile before retry . Isso pode exigir uma pessoa. Ainda é melhor do que transformar provas de transporte faltantes em um pagamento duplicado, mensagem, libertação ou exclusão. Reproduzir o livro de ameaças de nove casos O dispositivo de acompanhamento torna a regra da decisão inspecionável. A security risk cases.json contém nove operações propostas. A evaluate ai agent threat ledger.mjs verifica os limites numa ordem fixa: 1. Presença de credenciais, expiração, partilha, revocabilidade e audiência; 2. Os domínios exigidos em relação aos domínios concedidos; 3. proveniência não confiável de instruções para escritos; 4. Definição do recurso e do efeito máximo; 5. Identidade de operação, independência e reconciliação antes das retomadas; 6. Evidências independentes de efeitos. Faça isso com: O resumo reproduzido é o seguinte: Apenas dois casos prosseguem. Uma é uma leitura limitada. A outra é uma escrita idempotente com uma audiência exata, um conjunto de escopo exato, um recurso nomeado, o máximo impacto e evidências independentes. Os restantes casos demonstram uma credencial de administrador compartilhada, um token de tarefa expirado, um escopo de exclusão de exclusão, uma instrução externa não revisada, uma exportação ilimitada, uma nova tentativa com uma nova identidade de operação e uma resposta de sucesso sem prova de efeito. A ordem é importante. Se a permissão for verificada antes do público credencial, um token de serviço cruzado pode parecer seguro porque seus escopo coincide. Se as evidências de efeito forem verificadas antes de uma nova tentativa de identificação, o operador pode rotular a corrida apenas incompleta, enquanto outra tentativa insegura já é possível. O primeiro limite inseguro de confiança deve determinar a disposição. Adapte o aparelho com os seus efeitos e escopo reais. Adicione um caminho de revogação faltante, ambiente errado, aprovação obsoleta, substituição de recursos, escrita parcial, falha de retrocesso e desacordo entre o estado de saída e destino da ferramenta. O objetivo não é prever todos os ataques. É fazer com que a autoridade e a incerteza sejam impossíveis de se esconder dentro de um estado de agente verde. Mantém operacional o modelo de ameaça Revisar o livro razão quando uma ferramenta, âmbito, emissor de credenciais, API de destino, política de retest ou fonte de instruções mudam. Não precisa de um workshop completo para cada execução; gerar a maioria dos campos a partir de esquemas de ferramentas, metadados de identidade, receitas de política e operação, e depois perguntar a uma pessoa apenas sobre o impacto ou incerteza que o código não pode resolver. A regra da decisão compacta é: Prossegue somente quando a identidade é limitada ao público, permissões iguais ao conjunto requerido, instruções não confiáveis não podem autorizar silenciosamente efeitos, o impacto é limitado, retemptos preservam a identidade da operação, e o destino pode provar o resultado. Esta regra tem limites. Os metadados podem mentir ou ficar obsoletos. Um escopo exato ainda pode permitir um argumento perigoso. A impotência pode expirar. Um canal de leitura pode ser comprometido com o escritor. O livro razão reduz, portanto, a ambigüidade; não demonstra a segurança de todo o sistema. Combine o com autorização a jusante, isolamento, registos de auditoria, testes e resposta a incidentes adequados ao impacto. A Sidewisp está atualmente em prévia privada. É concebido como uma camada de saúde em torno dos tempos de execução dos agentes existentes, mas a coleta e recuperação de agentes de produção e saúde não são enviados no repositório atual do site. Este padrão de registro de ameaças é algo que os operadores podem implementar no seu próprio tempo de execução agora, não uma alegação de que a Sidewisp atualmente protege ou monitora agentes vivos. Se estiver a avaliar o Sidewisp para futuros fluxos de trabalho em saúde dos agentes, junte se à prévia privada. Até lá, mantenha o livro de ameaças perto do limite da ferramenta e deixe que evidências desconhecidas parem a ação antes que se torne um incidente.