# Revisão semanal de segurança de agentes: uma rotina prática de 35 minutos Uma **revisão semanal de segurança de agentes** deve levar menos de uma hora, produzir poucas decisões e deixar evidências que alguém possa consultar depois. Se ela virar uma busca por milhares de registros sem uma pergunta clara, o projeto já falhou. Já vi equipes cometerem o mesmo erro com tarefas automatizadas: elas coletam registros de atividade porque sabem que deveriam, mas só os abrem depois de uma surpresa desconfortável. Nessa altura, o contexto útil já esfriou. A pessoa que iniciou a execução passou para outra tarefa, a credencial temporária desapareceu e ninguém consegue dizer se aquele comando estranho foi um reparo legítimo ou o primeiro sinal de um limite de permissões inadequado. Uma revisão semanal resolve um problema mais específico. Ela identifica desvios de acesso enquanto as pessoas e as tarefas ainda podem ser reconhecidas. Também força uma distinção que costuma se perder: um registro de que um agente tinha permissão para agir não prova que suas ações fizeram sentido. ## Uma revisão semanal identifica desvios antes que pareçam normais A revisão semanal funciona porque o acesso dos agentes tende a mudar em pequenos incrementos fáceis de esquecer. Alguém adiciona um token para desbloquear um teste. Uma tarefa de programação se transforma em uma alteração de implantação. Um agente repete uma chamada de API até que um caminho alternativo funcione. Nenhum desses eventos necessariamente exige uma resposta a incidente. Juntos, ao longo de várias semanas, eles podem criar um padrão de acesso que ninguém aprovou de propósito. Revisar todos os eventos em tempo real parece mais seguro, mas a maioria das equipes não consegue manter o nível de atenção necessário. Os revisores começam a aprovar ou descartar registros por padrão. Deixam de perguntar por que um agente que editava documentação se conectou a um host de produção. É fadiga de aprovação usando um crachá de segurança. Esperar por uma revisão trimestral falha pelo motivo oposto. Um trimestre contém execuções demais, repositórios alterados demais e lembranças expiradas demais. No fim, você conta eventos em vez de entendê-los. Defina uma janela semanal fixa e revise os sete dias anteriores sempre no mesmo horário. Escolha um momento em que a pessoa responsável possa entrar em contato com quem executou tarefas incomuns. A tarde de sexta-feira funciona para algumas equipes; a manhã de segunda-feira é melhor se a automação do fim de semana precisar de atenção. O dia importa menos do que manter o horário estável. A revisão deve responder a cinco perguntas: - Quais novos processos de agente receberam autoridade? - Quais ações foram diferentes da tarefa ou do destino normal? - Quais falhas indicam uma integração quebrada ou um comportamento de sondagem? - Quais sessões uma pessoa revogou e a revogação realmente interrompeu o uso? - Quais credenciais precisam de uma decisão do responsável antes do próximo uso? Não acrescente uma sexta pergunta só porque um painel consegue exibi-la. Uma rotina semanal sobrevive quando tem um objetivo limitado. Ela morre quando vira uma reunião genérica de segurança com logs em uma tela. A NIST SP 800-92, *Guide to Computer Security Log Management*, destaca algo que continua útil aqui: as organizações precisam de processos definidos para analisar logs, não apenas de um lugar para armazená-los. Os registros de agentes tornam esse ponto ainda mais claro, porque um agente pode agir de forma rápida e repetida. O armazenamento fornece evidências. Uma rotina dá a essas evidências a chance de mudar uma decisão. ## Comece pelas novas sessões, não pelas chamadas individuais Comece revisando as novas sessões, porque uma sessão é a unidade em que a autoridade começa. Você precisa saber qual processo obteve a permissão, qual identidade apresentou, quando a execução começou e se havia um propósito plausível. Uma revisão de sessões não é um exercício de inventário. Não leia uma lista, reconheça o nome de uma pessoa conhecida e siga em frente. Uma identidade de processo assinada informa algo útil sobre a origem do processo, mas não diz que ele foi iniciado para uma tarefa sensata. Trate a identidade do processo como evidência de origem, não como evidência de intenção. Para cada nova sessão, responda a estas perguntas em uma nota de revisão: 1. Quem iniciou ou é responsável pela execução? 2. Qual repositório, chamado, tarefa de manutenção ou investigação a justificou? 3. Quais classes de credenciais a execução poderia usar? 4. A sessão terminou quando a tarefa terminou? 5. Apareceu outra sessão repetindo o mesmo trabalho com uma identidade diferente? A última pergunta identifica uma falha que as equipes costumam não perceber. Uma pessoa vê uma ferramenta falhar sob uma conta restrita, executa tudo novamente por outro processo de agente e obtém o resultado. O registro de atividade pode mostrar duas sessões comuns. O significado de segurança é diferente: o primeiro limite funcionou, enquanto a segunda execução pode ter contornado o motivo desse limite. Marque uma sessão para acompanhamento se ela não tiver um responsável reconhecível, uma referência de tarefa, duração incomum ou autoridade sem relação com o trabalho declarado. “Duração incomum” não significa que toda execução longa seja suspeita. Grandes refatorações e suítes de testes lentas demoram. Uma sessão que continua ativa muito depois do desaparecimento do contexto humano merece atenção, porque é fácil esquecer uma autoridade obsoleta. Mantenha uma lista curta de permissões para automações recorrentes, organizada por finalidade, não por um rótulo vago como “confiável”. Por exemplo, uma atualização agendada de dependências pode legitimamente acessar um registro de pacotes e abrir pull requests. Essa descrição oferece algo verificável ao revisor. “Bot de programação confiável” não oferece nada. ## Um comando incomum precisa de contexto antes de receber culpa Um comando SSH ou uma solicitação HTTP incomum é uma evidência para investigar, não um veredito. Os revisores erram nos dois sentidos. Alguns descartam comandos estranhos porque o agente estava autorizado. Outros tratam qualquer comando desconhecido como hostil. As duas reações tornam o log menos útil. Construa o contexto esperado a partir da tarefa. Uma solicitação para ler o status de uma implantação de homologação pode fazer sentido em uma investigação de lançamento. A mesma solicitação durante uma tarefa de ajuste de um README não faz sentido sem explicação. Um comando que arquiva resultados de compilação pode ser normal. Um comando que arquiva um diretório pessoal, lê o histórico do shell ou altera arquivos de inicialização remotos exige uma análise mais cuidadosa. Para a atividade SSH, compare o comando com quatro limites: - O host que a tarefa deveria acessar. - A conta e o diretório necessários para essa tarefa. - O tipo de alteração permitido pela tarefa. - A consequência esperada se o comando for bem-sucedido. O quarto limite importa. `git status` em um host de compilação tem poucas consequências. Um comando que edita uma definição de serviço, altera a propriedade de arquivos ou cria uma tarefa agendada muda o comportamento futuro. Essas chamadas devem ter uma referência de tarefa específica e uma pessoa responsável. Os registros HTTP precisam do mesmo tratamento, embora os indícios sejam diferentes. Observe o destino, o método da solicitação, o caminho, a classe da resposta e o volume de solicitações. Um novo `GET` para um serviço esperado pode ser rotineiro. Uma sequência de respostas de autorização negada, tentativas contra caminhos administrativos ou uma solicitação de escrita para um serviço sem relação com a tarefa exigem explicação. Não crie uma lista enorme de strings proibidas e chame isso de revisão. Os agentes podem chamar ferramentas legítimas em contextos inadequados, e um comando inocente pode parecer alarmante sem seus argumentos. O revisor precisa de evidências ao redor do evento para entender o que o agente estava tentando fazer. Uma conclusão útil tem esta forma: “A sessão S-184 executou uma tarefa de manutenção de repositório. Usou SSH no host de implantação e alterou uma configuração de serviço. O registro da tarefa não incluía trabalho de implantação. A pessoa responsável pela sessão confirmou que a alteração ocorreu porque o comando errado foi selecionado por acidente. Revogamos a sessão e restauramos a configuração anterior.” Isso oferece a outro revisor fatos, uma explicação e uma ação concluída. Uma conclusão fraca seria: “Comando suspeito observado.” Essa frase cria ansiedade e deixa para o próximo revisor a tarefa de reconstruir o evento inteiro. ## Chamadas malsucedidas mostram falhas e testes de limites As chamadas malsucedidas merecem uma análise própria, porque as falhas transmitem um tipo de sinal diferente das ações bem-sucedidas. Uma escrita bem-sucedida pode alterar um sistema. Uma falha pode revelar que um agente tentou acessar algo que jamais deveria ter considerado. Primeiro, separe a falha normal de integração da repetição suspeita. Um token expirado, um caminho de API alterado, um tempo limite de rede ou um limite de requisições do provedor geram falhas durante o trabalho normal. A correção pode ser operacional, sem relação com segurança. Registre a tendência das falhas, identifique o responsável e corrija o problema antes que o agente aprenda a contornar uma rota quebrada. Depois, procure padrões que mudem a interpretação: - A mesma chamada rejeitada se repete muitas vezes sem um recuo adequado ou uma mudança na tarefa. - O agente tenta caminhos próximos depois de uma rejeição de autorização. - Uma execução muda de destino depois de uma negativa, em vez de informar a negativa. - Uma chamada malsucedida tem como alvo um host, serviço ou conta fora do limite da tarefa. - Uma falha aparece imediatamente antes de uma ação bem-sucedida por meio de uma credencial mais ampla. É nesse último padrão que um projeto fraco de credenciais se esconde. Imagine que um agente tente atualizar uma implantação usando um token limitado e receba um erro de autorização. Em seguida, ele use um token geral de operações e tenha sucesso. Os logs podem mostrar uma tarefa “recuperada”. A revisão deve classificá-la como uma falha de escopo. O token limitado negou corretamente a solicitação; o token amplo escondeu a incompatibilidade entre a tarefa e o acesso permitido. Não diga às equipes para fazer rotação de uma credencial toda vez que uma solicitação de API retornar 401 ou 403. Esse conselho é popular porque parece decisivo. Também é desperdício. A rotação não corrige um escopo ausente, um endpoint errado ou um agente que escolhe repetidamente a ação incorreta. Ela pode dificultar a próxima revisão ao substituir a trilha de evidências por uma nova credencial com as mesmas permissões inadequadas. Em vez disso, classifique uma chamada malsucedida em uma destas quatro categorias: falha operacional esperada, defeito de configuração, violação do limite da tarefa ou possível uso indevido de credencial. O revisor deve escrever por que escolheu a categoria. Se as evidências não sustentarem uma categoria, pergunte à pessoa responsável pela sessão enquanto a execução ainda estiver recente. ## A revogação precisa fechar a rota que causou preocupação Uma sessão revogada deve impedir que um processo ativo use a autoridade recebida, mas isso não corrige automaticamente todos os riscos relacionados. A revisão semanal precisa verificar o próprio evento de revogação e as rotas de acesso ao redor dele. Para cada sessão revogada, registre o motivo. Uma pessoa pode revogar porque a tarefa terminou, porque uma aprovação foi acidental, porque a identidade do processo parecia errada ou porque a execução se comportou de modo inesperado. Cada motivo leva a uma correção diferente. Uma revogação normal ao fim da tarefa pode não exigir nenhuma ação adicional. Uma identidade de processo inesperada pode exigir uma investigação da estação de trabalho e do caminho de inicialização. Depois, verifique a atividade posterior à revogação. Qualquer chamada feita depois da revogação precisa de explicação. Ela pode resultar de uma diferença de interpretação dos horários, de um processo autorizado de forma independente ou de um defeito na maneira como o revisor vinculou os registros. Não presuma o pior, mas também não descarte o fato sem análise. O objetivo da revogação é tornar observável o limite de autoridade. Verifique também a autoridade paralela. Um agente pode perder uma sessão e continuar agindo por outro processo ativo, outra credencial, uma conexão SSH aberta ou uma conta de automação separada. A revisão não precisa provar que não existe nenhuma rota alternativa em toda a empresa. Ela deve determinar se a mesma tarefa poderia continuar por uma rota óbvia que ficou aberta. Escreva um registro de revogação em linguagem simples: ```text Data da revisão: 2025-03-07 Sessão: [referência da sessão] Motivo: o comando SSH ultrapassou a tarefa de manutenção aprovada Ação: sessão revogada Chamadas após a revogação: nenhuma observada Credencial relacionada: revisada, nenhuma rotação necessária Acompanhamento do responsável: atualizar as instruções da execução de manutenção ``` Use a data e as referências reais. O modelo importa porque força o revisor a declarar se verificou o que aconteceu depois da revogação. “Revogada”, por si só, descreve uma ação, não o resultado. Evite transformar toda revogação em um processo disciplinar. Se as pessoas esperarem punição por interromper uma execução, hesitarão até conseguirem provar a intenção. A revogação existe para interromper rapidamente uma ação incerta. A revisão posterior decide se a causa foi uma instrução inadequada, uma aprovação equivocada, um problema no projeto da credencial ou má conduta. ## A rotação começa pela responsabilidade e pelo escopo As credenciais com rotação pendente devem aparecer na revisão semanal como decisões à espera de um responsável, não como uma lista de pânico. Um token tem uma data de rotação, um responsável pelo sistema, uma finalidade declarada e um escopo. Se algum desses elementos faltar, a credencial já é mais difícil de gerenciar do que deveria. Crie uma pequena fila de rotação a partir das credenciais usadas durante a janela de revisão. Para cada uma, registre o responsável, o serviço, o uso pretendido, a próxima data de rotação e se a atividade da semana ainda corresponde a essa finalidade. Não é preciso começar com um banco de dados elaborado. Um registro durável com responsáveis identificados é melhor do que um inventário impressionante que ninguém atualiza. Priorize a rotação quando uma destas condições se aplicar: - A credencial passou da data de rotação exigida. - O responsável não consegue explicar um uso recente. - A credencial tem mais permissões do que a tarefa precisa. - A credencial foi usada depois de uma preocupação de acesso ou de um evento envolvendo um processo desconhecido. - A equipe não consegue identificar a conta de serviço ou a pessoa responsável por ela. A rotação sem um plano de transição causa interrupções evitáveis. Antes de substituir uma credencial, identifique as execuções de agentes, os scripts e as integrações que a usam. Emita a substituta com o escopo mínimo necessário para a tarefa atual. Teste a ação pretendida. Transfira os consumidores conhecidos. Depois, desative a credencial antiga e confirme que nenhuma atividade nova a utiliza. Não trate “não a vimos ultimamente” como prova de que uma credencial não é usada. Alguns trabalhos de manutenção são executados mensalmente ou apenas durante um incidente. Verifique o responsável e a finalidade documentada antes de removê-la. Se nenhum dos dois existir, desative-a em uma janela controlada e observe a falha resultante. Muitas vezes, essa é a resposta honesta mais rápida. Há outra distinção que vale preservar: a rotação reduz o período útil de um segredo, enquanto o escopo limita o que esse segredo pode fazer. As equipes costumam usar rotações frequentes para compensar permissões amplas. Isso não compensa. Uma credencial recém-emitida com acesso excessivo continua tendo acesso excessivo. ## Verifique as evidências antes de interpretá-las Uma conclusão semanal só é confiável quanto o registro em que se baseia. Capturas de tela exportadas e linhas copiadas manualmente são convenientes, mas são evidências fracas se alguém precisar determinar se foram editadas depois. O Sallyport registra execuções de agentes e chamadas individuais em um único log de auditoria criptografado e as exibe em diários separados de sessões e atividades. Essa separação é útil porque permite que o revisor passe de uma aprovação de processo para as chamadas concretas feitas durante a execução sem confundir os dois registros. Execute a verificação de integridade offline disponível antes de começar uma revisão formal ou ao preservar evidências depois de um evento preocupante: ```sh sp audit verify ``` O comando verifica a cadeia de auditoria sobre o texto cifrado e não precisa da chave do cofre. Uma verificação bem-sucedida informa que a cadeia está íntegra de acordo com os hashes registrados. Ela não prova que uma pessoa autorizada fez uma aprovação sensata, que o destino era adequado ou que o escopo da credencial era razoável. Integridade e julgamento são tarefas diferentes. Se a verificação informar um problema, pare de tratar a exportação afetada como evidência definitiva. Preserve os arquivos e registre o resultado exato do comando; depois, investigue o estado do armazenamento e da aplicação. Não “arrume” os registros para fazer o relatório parecer normal. É preciso descobrir se o problema veio de corrupção, de uma cópia incompleta ou de interferência antes de tirar conclusões com base no diário. Nas revisões semanais comuns, mantenha o resultado da verificação junto da nota de revisão quando sua equipe precisar de uma trilha defensável. Em experimentos locais de baixo risco, talvez você prefira uma prática mais simples. A decisão deve ser explícita. O padrão a evitar é pular a verificação silenciosamente justamente na semana que contém uma descoberta séria. ## A revisão precisa de um ritmo fixo de 35 minutos Uma revisão curta funciona quando você reserva tempo para decisões, não quando promete “dar uma olhada nos logs” depois do restante do trabalho. A rotina a seguir basta para uma equipe com um número administrável de execuções de agentes. Aumente o tempo apenas quando o volume ou o risco realmente exigir. 1. Passe cinco minutos verificando o registro de auditoria e definindo o intervalo de datas. Abra a nota da revisão anterior para deixar visíveis os itens pendentes. 2. Passe dez minutos nas novas sessões. Relacione cada processo desconhecido ou execução excepcionalmente longa a um responsável e a uma tarefa. 3. Passe dez minutos nas ações bem-sucedidas incomuns e nas chamadas malsucedidas. Busque o contexto ao redor antes de classificar qualquer evento. 4. Passe cinco minutos nas sessões revogadas. Verifique o motivo, a atividade após a revogação e a autoridade paralela óbvia. 5. Passe cinco minutos na rotação de credenciais. Atribua um responsável e um prazo para cada item que exigir ação. Limite o resultado a um registro de revisão com três títulos: descobertas, decisões e responsáveis pendentes. Uma descoberta é um fato observado. Uma decisão diz o que será feito. Um responsável pendente identifica a pessoa que precisa concluir algo. Misturar essas categorias cria notas cheias de verbos vagos como “monitorar” e “revisar”. Este é um formato conciso que costuma funcionar bem: ```text Período: [hora de início] a [hora de término] Revisor: [nome] Verificação da auditoria: aprovada ou requer acompanhamento Descobertas - [referência do registro] [evento observado e contexto] Decisões - [ação tomada e motivo] Responsáveis pendentes - [pessoa] fará [ação específica] até [data] ``` Uma revisão semanal sem descobertas ainda pode ser um bom trabalho, mas escreva o que foi verificado. “Nenhum problema” não informa se você examinou a origem das sessões, as revogações, as falhas ou a rotação. Algumas linhas concretas dão um ponto de comparação para o revisor da semana seguinte. Não deixe a revisão depender da presença perfeita de todos. Uma pessoa bem informada pode concluir a análise das evidências e encaminhar as perguntas aos responsáveis depois. Esperar uma sala cheia de pessoas é como uma rotina de sete dias vira um intervalo de seis semanas. ## O registro deve mudar as decisões de acesso A revisão falhou se apenas criar um relatório. Cada descoberta recorrente deve mudar uma destas quatro coisas: a instrução da tarefa, o limite de aprovação, o escopo da credencial ou a própria automação. Chamadas malsucedidas repetidas para um endpoint esperado podem exigir uma integração corrigida. Um agente que continua escolhendo trabalho de implantação durante uma revisão de código pode precisar de uma instrução de tarefa mais limitada e de nenhuma credencial de implantação. Uma sessão desconhecida recorrente pode exigir mudanças na forma como os desenvolvedores iniciam o agente. O uso repetido de uma credencial ampla pode justificar sua divisão por finalidade. O Sallyport pode exigir aprovação para um novo processo de agente e também exigir aprovação a cada uso de uma credencial selecionada. Use o segundo controle nas ações em que a pessoa deve examinar cada tentativa, em vez de tentar expressar esse julgamento por meio de um conjunto interminável de regras. Não reaja adicionando aprovações em todos os lugares. Se o revisor vê a mesma chamada inofensiva toda semana e não consegue distingui-la de uma chamada arriscada, o projeto de aprovação é ruim. Mova o trabalho recorrente de baixo risco para uma credencial limitada e preserve a aprovação por uso para ações cujas consequências exigem uma decisão humana. Mantenha uma lista curta das descobertas recorrentes e do status de correção de cada uma. Quando a mesma categoria aparecer em três revisões consecutivas, pare de tratá-la como uma observação isolada. Alguém precisa mudar o projeto operacional. O log já informou que o limite atual não corresponde ao trabalho. Uma primeira revisão bem feita pode causar certo desconforto porque expõe referências de tarefas ausentes, credenciais sem responsável e responsabilidades pouco claras. Esse desconforto é útil. Anote as perguntas sem resposta, atribua responsáveis e repita a mesma rotina na semana seguinte. O objetivo não é ter um diário impecável. É manter um ambiente de agentes em que uma pessoa ainda consiga explicar quem agiu, por que agiu, o que aconteceu e qual acesso permanece.