Limite a autoridade de um agente

Descreva a tarefa antes de conceder acesso

Um agente que lê código precisa de autoridade diferente da de um agente que faz deployment de um serviço. Não conceda os dois conjuntos de permissões apenas porque o mesmo produto suporta as duas ações.

Use três partes para definir autoridade: uma ação, um recurso e uma condição. Em uma correção fictícia de relatório, o agente pode escrever em uma branch de funcionalidade enquanto a tarefa estiver ativa. Pode ler arquivos aprovados do repositório. Não pode modificar dados de produção nem regras de proteção do repositório.

A forma exata de impor esses limites depende da ferramenta. Se um token não puder expressar uma restrição de branch, use controles adicionais do repositório ou um serviço de execução. Documente com honestidade a autoridade que resta.

Imponha o limite fora do modelo

Um prompt não é um sistema de controle de acesso. O componente de execução deve verificar a ação e o destino solicitados diante das permissões atuais. Não deve aceitar a afirmação do modelo de que a aprovação já existe.

A AWS recomenda permissões limitadas e credenciais temporárias para cargas de trabalho adequadas. A OWASP aplica o mesmo princípio de menor privilégio a agentes e suas ferramentas. Esses princípios precisam ser implementados nos sistemas reais de identidade e execução. Orientações do AWS IAM, orientações da OWASP para agentes.

Use credenciais de curta duração quando houver suporte. Mantenha segredos sem relação com a tarefa fora do ambiente. Uma tarefa de leitura de repositório não deve herdar uma senha de banco de dados de produção do shell do desenvolvedor.

Vincule a aprovação à ação real

Aprovar a preparação de uma alteração não significa aprovar seu deployment. Uma decisão de deployment deve identificar o artefato, o ambiente de destino e as condições relevantes. Se eles mudarem, a decisão anterior pode deixar de valer.

Considere um agente que propõe uma leitura segura no banco de dados e depois executa uma consulta diferente após receber aprovação. Um mecanismo útil de aprovação verifica a operação que realmente é executada. Uma mensagem genérica de “continue”, sem destino definido, pode ocultar essa diferença.

Separe também identidade de capacidade. Registre qual pessoa ou carga de trabalho iniciou a execução. Verifique se a identidade que a iniciou ainda tem permissão quando a ação ocorrer. A remoção do acesso de uma pessoa deve ter um efeito explícito sobre os trabalhos na fila.

Teste uma recusa e uma interrupção

Verifique mais que o caminho de sucesso. Em um ambiente de teste isolado, tente uma ação fora do recurso permitido. Confirme que o sistema de execução a rejeita. Inspecione o evento de auditoria sem registrar credenciais.

Depois, teste o cancelamento ou a expiração das credenciais. Determine quais trabalhos param imediatamente e qual operação pode terminar. Um botão de parada não necessariamente reverte uma ação que já chegou a outro sistema.

Mantenha um pequeno registro de permissões junto à tarefa. Inclua responsável, escopo aprovado, controles reais, teste de recusa e validade. Isso torna uma revisão posterior específica o suficiente para melhorar o fluxo de trabalho.