por AgentPolicy (LX AI)

Ferramentas permitidas vs agentes de fim aberto

O apelo de um agente de fim aberto é real: dê-lhe um shell, um navegador e uma caixa de correio, e ele pode resolver problemas que você não programou. O custo é o raio de ação. Cada ferramenta que você adiciona é um caminho que uma instrução injetada pode percorrer. A pergunta de design não é se conceder capacidade, mas como concedê-la de forma suficientemente estreita para que um passo errado permaneça contido.

Definições de ferramentas de privilégio mínimo

Começo escrevendo um contrato de ferramenta que especifica exatamente o que o agente pode fazer e o que não pode. Uma ferramenta de "leitura de ticket" deve expor apenas uma operação GET em um identificador de ticket específico, sem a capacidade de alterar o ticket, anexar arquivos ou chamar outros endpoints. Uma ferramenta de "envio de e-mail" deve aceitar apenas uma lista de destinatários pré-definida, um modelo de linha de assunto fixo e um corpo que é sanitizado para injeção de nova linha. Ao restringir o contrato, um único erro na saída do modelo se torna um evento limitado em vez de uma cascata.

Defina o conjunto de verbos

Liste todos os métodos HTTP, comandos de banco de dados ou operações de arquivo que a ferramenta precisa. Se a ferramenta só precisa ler, omita POST, PUT, DELETE e quaisquer comandos administrativos. Mantenho uma planilha que mapeia cada nome de ferramenta para os verbos permitidos e a reviso sempre que um novo endpoint é adicionado.

Restrinja argumentos

Para cada argumento, especifico um tipo, um limite de comprimento e um conjunto de caracteres permitido. Um ID de ticket pode ser um UUID, limitado a 36 caracteres. Um caminho de arquivo pode ser restrito a um subdiretório sob /var/agent/data e não deve conter ".." ou caminhos absolutos. Utilizo uma biblioteca de validação de esquema que rejeita qualquer solicitação que não esteja em conformidade antes que a ferramenta seja executada.

Versão do contrato

Armazeno a definição da ferramenta como um arquivo JSON no controle de versão. Qualquer alteração dispara uma solicitação de pull que requer aprovação de um revisor de segurança. Isso cria um registro de auditoria que mostra quando a superfície de privilégio foi expandida e por quê.

Para ver como a injeção de prompt pode abusar de ferramentas excessivamente amplas, revise a orientação OWASP LLM01: https://genai.owasp.org/llmrisk/llm01-prompt-injection. A folha de dicas mostra exemplos concretos onde um modelo foi enganado para invocar um comando de shell porque a ferramenta aceitou entrada não restrita.

Nome da ferramenta | Verbo permitido | Restrições de argumento | Chamada segura de exemplo read_ticket | GET | ticket_id: UUID, 36 caracteres | /tickets/123e4567-e89b-12d3-a456-426614174000 send_email | POST | para: lista de domínios aprovados, assunto: máximo 78 caracteres, corpo: sanitizado | {"para":["usuário@example.com"],"assunto":"Atualização","corpo":"Por favor, revise o relatório anexado."} list_files | GET | caminho: deve começar com /var/agent/data/, sem ".." | /var/agent/data/logs/2024-09-01.txt

Confirmação de ações irreversíveis

Ações que alteram o estado fora da caixa de areia do agente - como enviar uma mensagem, excluir um registro ou implantar uma compilação - devem ser controladas por uma etapa de aprovação separada que o agente não pode invocar em si mesmo. Trato essas ações como portas de mão única e projeto a política para exigir um token humano ou um serviço de aprovação de curta duração antes que a ferramenta seja executada.

Endpoint de aprovação separado

Exponho uma API interna que aceita uma solicitação assinada do agente, registra a solicitação e, em seguida, aguarda que um humano clique em "aprovar" em uma interface do usuário ou responda a um comando de bate-papo. O agente recebe apenas um identificador pendente; ele não pode sondar o endpoint de aprovação para forçar uma concessão.

Tokens com limite de tempo

Quando a aprovação é concedida, o sistema emite um token que é válido para um único uso e expira após cinco minutos. O endpoint da ferramenta verifica a assinatura e a expiração do token antes de prosseguir. Se o token estiver faltando ou estiver vencido, a ferramenta retorna um erro e a tentativa é registrada.

Registro do portão

Cada solicitação de aprovação e decisão é escrita em um registro imutável com carimbos de data/hora, o identificador do agente, o nome da ferramenta e os argumentos que foram apresentados. Esse registro permite que eu reconstrua se uma instrução envenenada conseguiu contornar o portão ou foi interrompida na etapa de aprovação.

Para orientação sobre a higiene de credenciais em pipelines automatizados, consulte a folha de riscos de segurança OWASP CI/CD: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Isso reforça o princípio de que segredos nunca devem ser armazenados em um local onde um agente possa lê-los sem um fluxo de aprovação explícito.

Registros de auditoria como controle, não como um afterthought

Trato o registro de auditoria como a principal evidência de que uma política está sendo aplicada. Sem um registro confiável, as declarações sobre privilégio mínimo são alegações não verificáveis. Projeto a camada de registro para ser somente para escrita, do ponto de vista do agente, e para ser armazenada em um sistema que o agente não pode alterar ou excluir.

O que registrar

- Carimbo de data e hora com precisão de milissegundos - Identificador do agente (versão do modelo, ID de implantação) - Nome da ferramenta e o verbo exato chamado - Todos os argumentos passados para a ferramenta, após validação - Código de status do resultado e resumo dos dados retornados (tamanho, não conteúdo completo) - Fonte do pedido (iniciado pelo usuário, gatilho agendado ou mecanismo de política)

Garantias de armazenamento

Escrevo cada entrada de registro em um armazenamento somente para adição, como um log de pré-escrita em um bucket de armazenamento em nuvem com versionamento de objetos habilitado. A política do bucket nega qualquer operação de exclusão ou sobrescrita da conta de serviço do agente. Isso garante que, mesmo que o modelo seja comprometido, o histórico permaneça intacto.

Consultando para investigações

Quando um incidente é relatado, executo uma consulta simples, semelhante a SQL, contra o índice de registro para encontrar todas as execuções de uma ferramenta específica dentro de uma janela de tempo. Evito junções complexas que possam ser lentas; em vez disso, confio em tabelas particionadas por data e nome da ferramenta. A consulta retorna a lista de identificadores que, em seguida, extraio para uma análise forense mais aprofundada.

Para entender como a validação de entrada pode prevenir argumentos maliciosos de alcançar uma ferramenta, consulte a folha de dicas de prevenção de injeção de SQL: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. A folha mostra consultas parametrizadas e tipagem estrita, que espelham a abordagem de validação de argumentos que uso para ferramentas de agente.

Quando o acesso aberto é justificado

Existem casos legítimos em que um agente precisa de acesso mais amplo, como análise de dados exploratória ou caça a ameaças em um ambiente isolado. Nesses casos, concedo abertura apenas após colocar o agente em um sandbox que bloqueia qualquer caminho para dados de produção ou sistemas de pagamento externos.

Limites do sandbox

O sandbox fornece um shell, um mecanismo de navegador e uma caixa de correio que pode enviar mensagens apenas para um domínio de teste dedicado. A política de rede bloqueia o tráfego de saída para qualquer endereço IP que pertença às faixas de CIDR internas da empresa. A saída é permitida apenas para um conjunto de espelhos públicos aprovados para instalação de pacotes.

Isolamento de credenciais

Nenhum segredo de produção é montado no sistema de arquivos do sandbox. Em vez disso, o agente recebe um token temporário que pode ler de um bucket de conjunto de dados público. Se o agente tentar ler um arquivo fora do ponto de montagem permitido, o kernel retorna um erro de permissão e a tentativa é registrada.

Sessões com tempo limite

Cada sessão do sandbox dura no máximo duas horas. Após o tempo limite, o ambiente é desmontado e uma imagem fresca é iniciada. Isso limita a janela durante a qual um agente com mau comportamento pode explorar ou exfiltrar dados.

Ainda aplico definições de ferramentas de privilégio mínimo dentro do sandbox; a diferença é que as consequências de um erro são contidas no ambiente descartável, em vez de sistemas de produção.

Tratar políticas geradas como rascunhos

Quando um modelo ou um engenheiro júnior produz um arquivo de política, eu o reviso exatamente como eu revisaria código não confiável que está prestes a ser implantado em um serviço crítico. A lista de verificação da revisão inclui verificar cada regra contra as definições de ferramenta reais, confirmar que existem caminhos de negação e garantir que o arquivo esteja versionado.

Mapeamento de regra para ferramenta

Eu crio uma planilha que lista cada ferramenta em um eixo e cada regra de política no outro. Para cada célula, eu marco se a regra permite, nega ou está silenciosa sobre a operação da ferramenta. Qualquer célula silenciosa dispara um comentário que pede ao autor para esclarecer a intenção.

Verificação de negação por padrão

Eu executo um script de análise estática que tenta invocar cada ferramenta com um conjunto de argumentos malformados. Se o script encontrar uma combinação que a política permite, mas que deveria ser negada (por exemplo, uma ferramenta "excluir" que aceita um identificador wildcard), o script falha na compilação e a política deve ser revisada.

Controle de versão e revisão

O arquivo de política vive em um repositório Git com proteção de branch que exige duas aprovações antes de mesclar. Eu etiqueto cada versão liberada com um número semântico (por exemplo, v1.2.0) e anexo a snapshot correspondente da definição da ferramenta. Isso torna possível reverter para um estado conhecido como bom se uma nova versão introduzir uma regra excessivamente permissiva.

Eu nunca considero uma política gerada como final até que ela tenha passado por esse ciclo de revisão. Uma política que nunca é examinada cria uma falsa sensação de segurança e pode esconder lacunas que só aparecem sob carga real do mundo.

O que isso NÃO é

Este guia não promete que seguir os passos eliminará todos os modos de falha possíveis. Eu não afirmo 100 % de proteção contra injeção de prompt, vazamento de credenciais ou erros de lógica. Eu também não afirmo que um agente nunca perderá uma instrução maliciosa; a detecção depende da qualidade dos logs, da oportunidade da revisão humana e da correção dos contratos de ferramenta. Trate os padrões como medidas de redução de risco, não como uma garantia de segurança absoluta.