AI Agente Guardrails: Construa um Portão de Ação de Quatro Controle

Os barris de proteção do agente AI não devem ter um único comando, um único classificador ou um único botão de aprovação. Para um agente que pode alterar o estado externo, o padrão prático é um portão de ação de quatro controles: decidir se a ação é permitida, provar que o chamador tem autoridade para essa ação exata, limitar a tentativa, em seguida, verificar o efeito externo. Cada controlo responde a uma pergunta diferente. Combiná los em uma única bandeira safe: true esconde se um agente está bloqueado, à espera de uma pessoa, fora do orçamento de retomada, ou simplesmente falta provas após uma chamada de ferramenta. Mantém esses estados separados e o sistema pode falhar fechado sem tratar cada pausa como um incidente. Colocar a política na fronteira da ação Comece reduzindo o que o agente pode pedir a uma ferramenta para fazer. Um portal de política deve receber dados de acção estruturados, não apenas em prosa: O resultado da política deve ser um allow , deny ou unknown . O Unknown é importante. Uma classificação faltante não é permissão, e forçar a ambigüidade na allow ou na deny torna o modelo inventar certeza em nome do operador. Este portal também deve verificar se a ferramenta pertence ao conjunto de capacidades do agente. O Orientações da OWASP sobre a agência excessiva identifica funcionalidade, permissões e autonomia excessivas como causas raiz separadas. As suas mitigações são correspondentemente concretas: expõem apenas as extensões necessárias, preferem funções estreitas aos comandos abertos, concedem permissões mínimas a jusante e aplicam a autorização no sistema a jusante. Esse último limite é importante. Uma instrução como never delete production data é um contexto útil, mas não é um controlo de autorização. Um endpoint de exclusão deve rejeitar uma identidade não autorizada mesmo quando um agente apresenta uma razão persuasiva. Da mesma forma, um fluxo de trabalho de somente leitura não deve receber um cliente cujas credenciais podem ser escritas. Os modelos de guarda ainda têm um trabalho, mas conheçam o seu tempo. O Documentação do SDK OpenAI Agents distingue as barrancas de entrada/saída do agente das barrancas de ferramentas funcionais. Observa também que um protector de entrada paralelo pode terminar depois que o agente já tenha consumido tokens ou executado ferramentas. Para um limite de efeitos colaterais, use um controle de bloqueio imediatamente antes da execução, apoiado por uma autorização downstream real. O padrão razoável é: Recusar a utilização de ferramentas fora de uma lista de autorizações por agente; Calcular os escopo necessários da ação estruturada; Forçar esses domínios fora do modelo; Retorno de unknown quando as entradas de política são incompletas; Registrar a versão da política e a versão de acção com a decisão. Os filtros de conteúdo não substituem este portal. O Documentação de proteção do relógio Connect AI da AWS abrange tópicos negados, filtros de conteúdo, verificações de grounding, filtros de palavras e controles de informações sensíveis, enquanto também documenta os limites de configuração e as compensações de latência. Estas são salvaguardas úteis para as entradas e saídas. Não provam que uma liberação, pagamento, mensagem ou mutação de arquivo seja autorizada. Ligue a aprovação a uma ação, não a uma conversa Approvado é muito vago para ser executado. Uma aprovação segura é um envelope de curta duração da autoridade vinculado à ação exata da pessoa analisada. No mínimo, insistir: Recompõe a digestão de ação imediatamente antes da execução. Se o recurso, os argumentos, o ator, a ferramenta, o impacto ou a expiração forem diferentes, a aprovação não coincide. Pergunte novamente em vez de estender uma velha decisão sobre um novo trabalho. Isto evita uma classe silenciosa, mas grave de falhas. Uma pessoa pode aprovar um candidato de liberação para um repositório, então o contexto do agente muda, uma nova tentativa reconstitui argumentos diferentes ou outra execução reutiliza o mesmo estado de conversa. Um booleano flutuante livre sobrevive a todos os três erros. Um recibo vinculado à ação não. A aprovação também requer um proprietário e um estado reiniciável. O awaiting approval não é o stuck : tem uma decisão nomeada, uma rota para a pessoa certa e uma expiração. Após uma decisão, retomar do envelope de ação congelada, em vez de repetir o planejamento e esperar que o modelo proponha a mesma operação. Nem todas as ações precisam de um ser humano. Usar o impacto para decidir: As ações reversíveis de escasso alcance, apenas de leitura, podem ser executadas sob uma política permanente; As alterações com retrocesso limitado e bem testado podem utilizar limites e auditoria explícitos; As ações públicas, financeiras, destrutivas, de mudança de privilégios ou de outro modo de alto impacto exigem aprovação exata; ambiguidade sobre as rotas de impacto para uma pessoa. A revisão humana é, portanto, um controle dentro da pilha, não a pilha em si. Execução obrigatória mesmo após autorização Uma ação autorizada e aprovada pode ainda correr mal. O executor precisa de limites rígidos que o agente não pode renegociar silenciosamente: um prazo absoluto, verificado antes de cada tentativa; um número máximo de tentativas; Uma chave de impotência para efeitos colaterais; um limite máximo de recursos e de impacto; um caminho de cancelamento; Uma regra para o que acontece quando o resultado é ambíguo. A identidade da operação deve manter se estável em todas as tentativas. Se ocorrer um intervalo de tempo de transporte após a alteração do destino, a emissão de uma nova identidade de operação pode duplicar o efeito. Se o destino suportar a idempotencia, reutilizar a mesma chave. Se for uma pesquisa autorizada, reconciliar antes de tentar novamente. Se nenhum deles existe, pare com o unverified em vez de adivinhar que outra tentativa é segura. Mantenha o executor em estado mecânico. Um modelo pode recomendar uma nova tentativa, mas o código deve decidir se attempt < maxAttempts , o prazo é novo, o recurso ainda corresponde, e a ação tem uma chave de idempotencia utilizável. Este é um dos raros lugares onde os condicionantes entediantes são exatamente o design certo. Os limites não são apenas para a contenção dos danos. Eles preservam o diagnóstico. Sem eles, uma chamada repetida pode parecer persistência, uma operação expirada pode parecer progresso lento e um efeito duplicado pode parecer recuperação. Com limites explícitos, o operador pode distinguir os estados de trabalho, espera, bloqueado e incerto. Verificar o efeito de forma independente Uma resposta da ferramenta prova o que a ferramenta relatou, não necessariamente o que o usuário precisava. O portão final compara uma pós condição observável com o resultado prometido. Preferimos evidências deterministas: Obter o objeto criado por ID estável; Leia a secção de destino ou o registo de liberação; Verificar a existência do arquivo esperado e a correspondência do hash; Realizar os ensaios pertinentes; confirmar que uma mensagem aparece no destino previsto; Comparar os valores antes e depois do recurso exato. Não utilize o mesmo sinal fraco duas vezes. Se o ponto final de escrita retornar { "ok": true } , copiar esse campo em um registro de conclusão não é verificação independente. Leia do destino autorizado ou inspecione o produto prometido. Alguns resultados não podem ser verificados imediatamente. Uma notificação pode ser aceita, mas não entregue, um fornecedor externo pode não ter uma API de leitura ou um canal de observação pode estar obsoleto. Representar que como unverified , incluir as provas faltantes e a próxima verificação segura, e evitar relatar o sucesso. É aqui que a saúde e a segurança operacionais se encontram. A política e a autorização impedem ações proibidas; a verificação de efeitos impede a realização falsa. Um agente pode obedecer a todas as regras de acesso e ainda falhar na sua tarefa. Por outro lado, um resultado bem sucedido não desculpa um caminho não autorizado. Repete nove caixas antes de confiar no projeto O artefato que acompanha transforma os quatro controles num pequeno teste executável. A guardrail cases.json contém nove acções propostas. A evaluate agent guardrails.mjs aplica uma prioridade fixa: 1. política; 2. Áreas de aplicação e autoridade de homologação; 3. limites de execução; 4. Evidências de efeito. Faça isso com: O resumo reproduzido é o seguinte: Os casos interessantes não são a passagem limpa ou a negação óbvia. Uma aprovação expirou. Outra foi emitida para uma impressão digital de ação diferente. Uma carta esgotou o orçamento da nova tentativa. Um comando correu sem efeito observável. Uma política não pode classificar a acção. Esses casos mostram por que a prioridade do Estado deve ser explícita. Verifique primeiro a evidência do efeito e uma ação não autorizada pode ser rotulada como simplesmente não verificada. Verifique a aprovação antes da política e pode pedir a uma pessoa que autorize uma ferramenta que nunca deveria ter estado disponível. Colapso desconhecido em negação e o operador perde um sinal de qualidade de dados reparável; colapso em permitir e o sistema inventa autoridade. Adapte o aparelho às suas próprias ferramentas. Adicionar casos de substituição de recursos, perda de alcance, não aprovação reutilizada, versões de políticas obsoletas, expiração do prazo, efeitos parciais, falha de retrocesso e um canal de verificação que não concorda com a resposta da ferramenta. O portão só estará pronto quando esses falhas produzirem o estado e a próxima ação que pretendia. Mantém a fronteira honesta Os guardrails de agentes AI funcionam quando cada controlo pode vetar a ação por seu próprio motivo e expor provas dessa decisão. A regra compacta é: A política decide se a ação pertence. A autoridade obriga quem pode fazer exatamente o que. Os limites limitam a tentativa. A verificação provou o efeito. Isto custa mais do que adicionar um classificador. As aprovações exatas adicionam tempo de espera. Os cheques de leitura após a escrita adicionam chamadas. Ferramentas estreitas exigem engenharia. Os estados desconhecidos precisam de manipulação do operador. O comércio vale a pena para efeitos colaterais porque a ambigüidade permanece visível em vez de se tornar autoridade silenciosa ou falso sucesso. 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. A pilha de controle aqui é um padrão de implementação que você pode testar agora, não uma afirmação de que Sidewisp atualmente o impõe. Se estiver a avaliar o Sidewisp para futuros fluxos de trabalho em saúde dos agentes, junte se à prévia privada. Enquanto isso, mantenha o envelope de ação e a sua evidência no seu próprio tempo de execução: o guarda roupa mais seguro é aquele que ainda se mantém quando o modelo está confiantemente errado.