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 questão de design não é se conceder capacidade, mas como concedê-la de forma suficientemente restrita 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 "ler ticket" deve expor apenas uma operação GET em um identificador de ticket específico, sem capacidade de alterar o ticket, anexar arquivos ou chamar outros endpoints. Uma ferramenta de "enviar 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.

Definir o conjunto de verbos

Listar 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, omitir POST, PUT, DELETE e quaisquer comandos administrativos. Mantenho uma planilha que mapeia cada nome de ferramenta para os verbos permitidos e reviso-a sempre que um novo endpoint é adicionado.

Restringir argumentos

Para cada argumento, especifico um tipo, um limite de comprimento e um conjunto de caracteres permitidos. 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.

Versionar o 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 argumentos | Chamada segura de exemplo ler_ticket | GET | ticket_id: UUID, 36 caracteres | /tickets/123e4567-e89b-12d3-a456-426614174000 enviar_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."} listar_arquivos | 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

As ações que alteram o estado fora da sandbox do agente - como enviar uma mensagem, excluir um registo, ou implementar uma compilação - devem ser controladas por um passo de aprovação separado que o agente não pode invocar em si mesmo. Trato essas ações como portas de um só sentido e desenho a política para exigir um token humano ou um serviço de aprovação de curta duração antes de a ferramenta executar.

Endpoint de aprovação separado

Exponho uma API interna que aceita um pedido assinado do agente, regista o pedido e, em seguida, aguarda que um humano clique em "aprovar" numa interface de usuário ou responda a um comando de chat. O agente recebe apenas um identificador pendente; 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 expiração do token antes de prosseguir. Se o token estiver faltando ou estiver obsoleto, a ferramenta devolve um erro e a tentativa é registada.

Registando o portão

Todos os pedidos de aprovação e decisões são escritos num registo imutável com carimbos de data e hora, o identificador do agente, o nome da ferramenta e os argumentos que foram apresentados. Este registo permite reconstruir se uma instrução envenenada conseguiu contornar o portão ou foi interrompida no passo de aprovação.

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

Registos de auditoria como controlo e não como um pensamento posterior

Trato o registo de auditoria como a principal evidência de que uma política está a ser aplicada. Sem um registo fiável, as afirmações sobre privilégio mínimo são alegações não verificáveis. Desenho a camada de registo para ser apenas de escrita a partir da perspetiva do agente e para ser armazenada num sistema que o agente não pode alterar ou eliminar.

O que registar

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

Garantias de armazenamento

Escrevo cada entrada de registo para um armazenamento apenas de acréscimo, como um registo de antecipação em um balde de armazenamento em nuvem com versionamento de objetos ativado. A política do balde nega qualquer operação de eliminação ou sobreposição a partir da conta de serviço do agente. Isso garante que, mesmo que o modelo seja comprometido, o histórico permaneça intacto.

Consulta para investigações

Quando um incidente é relatado, executo uma consulta simples semelhante a SQL contra o índice de registo para encontrar todas as execuções de uma ferramenta específica dentro de uma janela de tempo. Evito juntas complexas que possam ser lentas; em vez disso, confio em tabelas particionadas por data e nome da ferramenta. A consulta devolve 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 atingir 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 de abertura é justificado

Existem casos legítimos em que um agente precisa de uma abrangência mais ampla, 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 uma shell, um mecanismo de navegador e uma caixa de correio que só pode enviar mensagens 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 é lançada. Isso limita a janela durante a qual um agente com mau comportamento poderia explorar ou exfiltrar dados.

Eu 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 nos sistemas de produção.

Tratar políticas geradas como rascunhos

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

Mapeamento de regra para ferramenta

Eu crio uma folha de cálculo 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 omissã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 de "exclusão" que aceita um identificador de caractere curinga), o script falha na compilação e a política deve ser revista.

Controlo de versão e revisão

O ficheiro de política vive em um repositório Git com proteção de ramo que exige duas aprovações antes de mesclar. Eu etiqueto cada versão lançada 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 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 este ciclo de revisão. Uma política que nunca é examinada cria uma falsa sensação de segurança e pode ocultar lacunas que só aparecem sob carga real do mundo.

O que isto não é

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