Limitar a autoridade de um agente

Descreva a tarefa antes de conceder acesso

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

Use três elementos para definir a autoridade: uma ação, um recurso e uma condição. Num exemplo fictício de correção de um relatório, o agente pode escrever num único feature branch enquanto a tarefa estiver ativa. Pode ler ficheiros 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 o limite depende da ferramenta. Se um token não permitir restringir o acesso a um branch, use controlos adicionais no repositório ou um serviço de execução. Documente com rigor a autoridade que permanece.

Imponha o limite fora do modelo

Um prompt não é um sistema de controlo de acesso. O componente de execução tem de verificar a ação e o destino pedidos face às permissões atuais. Não deve aceitar uma afirmação do modelo de que a aprovação já existe.

A AWS recomenda permissões limitadas e credenciais temporárias para as cargas de trabalho adequadas. A OWASP aplica um raciocínio semelhante de privilégio mínimo aos agentes e às suas ferramentas. Estes princípios exigem implementação nos sistemas reais de identidade e execução. Orientações da AWS IAM, orientações da OWASP para agentes.

Use credenciais de curta duração quando forem suportadas. Mantenha fora do ambiente os segredos sem relação com a tarefa. Uma tarefa que só lê um repositório não deve herdar da shell do programador a palavra-passe de uma base de dados de produção.

Associe a aprovação à ação real

A aprovação para preparar uma alteração não implica aprovação para fazer o respetivo deployment. Uma decisão de deployment deve identificar o artefacto, o ambiente de destino e as condições relevantes. Se estes mudarem, a decisão anterior pode deixar de se aplicar.

Considere um agente que propõe uma leitura segura da base de dados, mas executa uma consulta diferente depois de receber aprovação. Um mecanismo de aprovação útil verifica a operação que é realmente executada. Uma mensagem genérica «continue», sem um destino definido, pode ocultar esta diferença.

Separe também a identidade da capacidade de agir. Registe a pessoa ou a carga de trabalho que iniciou a execução. Verifique se essa identidade ainda tem permissão quando a ação ocorre. A remoção do acesso de uma pessoa deve ter um efeito explícito sobre o trabalho em fila.

Teste uma recusa e uma interrupção

Verifique mais do que o percurso bem-sucedido. Num ambiente de teste isolado, tente uma ação fora do recurso permitido. Confirme que o sistema de execução a rejeita. Examine o evento de auditoria sem registar credenciais.

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

Mantenha um pequeno registo de permissões junto da tarefa. Inclua o responsável, o âmbito aprovado, os controlos reais, o teste de recusa e o prazo de validade. Isto torna uma revisão posterior suficientemente concreta para melhorar o fluxo de trabalho.