Como os pedidos de aprovação de agentes evitam aprovações na execução errada

Uma fila de aprovação para agentes autônomos não é uma pilha de botões de permissão. Ela é um sistema de atribuição em tempo real. Quando duas ou mais execuções de agentes podem solicitar a mesma credencial, chamar a mesma API ou abrir a mesma conexão SSH, o revisor precisa responder a uma pergunta antes de aprovar: qual processo em execução está me pedindo autorização para esta ação exata?

A maioria das interfaces de aprovação falha porque faz todos os cartões parecerem ter vindo de um único ator genérico chamado «o agente». Isso não causa problemas em uma demonstração com uma janela de terminal. Torna-se perigoso quando um agente de programação corrige um incidente em produção enquanto outro prepara uma versão, ambos usam o mesmo cliente e pedem acesso ao mesmo serviço. O revisor vê um destino familiar, reconhece a tarefa em linhas gerais e aprova a ação certa para a execução errada.

Aprovação é uma decisão de atribuição

Um revisor não aprova uma solicitação HTTP isoladamente. Ele aprova uma solicitação porque ela pertence a um trabalho específico que deveria estar acontecendo. Se a interface não preserva essa relação, o botão de aprovação vira um palpite apresentado como controle humano.

Trate cada aprovação como uma afirmação com cinco partes:

1. Um executável ou processo de agente específico a iniciou.
2. Uma sessão específica desse processo ainda está ativa.
3. Essa sessão está associada a uma tarefa ou item de trabalho nomeado.
4. Ela quer realizar uma ação externa concreta.
5. O revisor autoriza ou recusa essa combinação.

O quinto ponto é mais importante do que parece. «Aprovar acesso à API de implantação» não é uma afirmação completa. Um revisor pode aceitar que a execução de versão leia um registro de build, mas não que uma execução de depuração não relacionada altere uma configuração da versão. O destino, sozinho, não transmite esse significado.

Essa diferença se perde porque o mesmo cliente de agente costuma criar as duas execuções. A linha de comando pode ser idêntica. A autoridade de assinatura do código pode ser idêntica. O caminho do repositório pode ser idêntico. O agente pode até gerar solicitações quase iguais. Nada disso transforma duas invocações simultâneas no mesmo sujeito de segurança.

Já vi equipes acrescentarem palavras ao resumo da ação quando o problema real era a falta de atribuição. Elas mudam «POST /deployments» para «POST /deployments para iniciar a implantação de staging da versão 1.8.4». Isso explica melhor a operação, mas ainda deixa dois cartões que afirmam ser implantações de staging. Uma frase melhor não corrige a ausência de um limite de sessão.

A interface de aprovação precisa deixar visível a hierarquia de identidade. A ação é o objeto principal. O processo que a iniciou e a sessão ativa explicam por que ela apareceu. O rótulo da tarefa ajuda o revisor a reconhecer a intenção, mas não substitui nenhum dos identificadores técnicos.

Um processo assinado não é uma sessão em execução

Uma identidade de assinatura de código pode informar ao sistema quem assinou o código, mas não diz ao revisor qual invocação desse código produziu uma solicitação pendente. A documentação de assinatura de código da Apple estabelece um limite semelhante: os requisitos de código definem a identidade do código, enquanto um requisito designado descreve o que conta como o mesmo código entre versões. Isso é uma evidência útil sobre o chamador, mas não substitui um identificador de execução.

Isso importa quando o pedido de aprovação começa assim:

Request from: Acme Agent CLI
Signed by: Example Engineering, Team ABCD1234

É um bom começo. O revisor consegue saber se um cliente esperado pediu acesso. Mas ainda não sabe se é o assistente de versões iniciado há cinco minutos, o assistente de testes deixado aberto pela manhã ou um comando copiado executado em outro terminal.

A identidade do processo e a identidade da sessão respondem a perguntas diferentes:

Não esconda as duas primeiras linhas só porque adicionou a quarta. O revisor precisa da autoridade do processo para identificar um cliente inesperado. Precisa do ID da sessão para separar clientes esperados em paralelo. Precisa do rótulo da tarefa para relacionar um identificador técnico a uma visão mental do trabalho.

A regra prática é simples: mostre a identidade do processo como procedência e a identidade da sessão como a unidade autorizada.

No macOS, usar apenas um identificador de assinatura como rótulo de aprovação é especialmente fraco. A Apple observa explicitamente que vários signatários podem reivindicar identificadores de assinatura e recomenda combinar a verificação do identificador com a categoria de validação e, para código que não é da Apple, com um identificador de equipe. Um cartão que mostra apenas um nome amigável de pacote ou apenas um identificador reivindicado oferece menos evidências do que a plataforma pode fornecer.

Não use a linguagem bruta dos requisitos como rótulo principal. Ela é precisa, mas a maioria dos revisores não consegue lê-la rapidamente para tomar uma decisão. Apresente a autoridade de assinatura em linguagem simples, deixe o requisito técnico disponível nos detalhes e associe-o a um nome de executável reconhecível. Depois, coloque o identificador da sessão onde o olhar possa encontrá-lo sem expandir nada.

Dê a cada execução uma identidade de sessão que sobreviva à fila

O ID da sessão deve existir antes da primeira chamada protegida, permanecer estável durante toda a execução e sair do conjunto de autorizações quando a execução terminar. Qualquer coisa mais fraca cria ambiguidade sob carga.

Gere um ID opaco de alta entropia no momento da conexão ou do registro do processo. Armazene o valor completo no registro de auditoria, mas mostre no pedido um prefixo curto e inequívoco. A forma exibida deve ser longa o bastante para que duas sessões ativas dificilmente compartilhem o mesmo prefixo, e a interface deve tornar qualquer colisão impossível de ignorar. Não derive o ID apenas do horário atual, da posição na fila, do nome do repositório ou do ID do processo.

Um registro interno útil se parece com isto:

{
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "display_id": "7TQ4N8M2",
  "process": {
    "pid": 84172,
    "executable": "/usr/local/bin/agent-cli",
    "signing_authority": "Example Engineering (Team ABCD1234)"
  },
  "task": {
    "label": "Prepare the staging release notes",
    "workspace": "/Users/maya/work/app"
  },
  "started_at": "2026-07-22T16:42:11Z"
}

O rótulo da tarefa deve vir de uma instrução visível para uma pessoa ou de um título de sessão definido conscientemente, não de uma frase gerada pelo modelo que muda a cada chamada de ferramenta. O modelo pode sugerir o rótulo, mas o sistema deve congelá-lo quando a sessão começar. Se uma sessão passar de «preparar as notas da versão» para «alternar a credencial do webhook de produção», o revisor merece uma alteração explícita da tarefa ou uma nova sessão. Reescrever o rótulo silenciosamente torna o histórico mais difícil de ler e permite que a execução tome emprestada a legitimidade de uma tarefa anterior e mais segura.

Use um ciclo de vida com limites claros:

• Crie a sessão antes de qualquer ação que use credenciais.
• Associe todas as solicitações, aprovações, recusas, cancelamentos e resultados à sessão.
• Feche a sessão quando o processo que a iniciou terminar ou perder a conexão válida.
• Revogue a sessão imediatamente quando o revisor escolher revogar.
• Recuse aprovações pendentes depois do fechamento ou da revogação, mesmo que o cartão continue visível por alguns instantes.

O último ponto evita uma corrida sutil, mas comum. O revisor vê um cartão da execução A. A execução A termina. Uma nova execução B começa, solicita uma ação parecida e o cartão antigo ainda aceita entradas. Se o serviço de aprovação associar esse clique à «solicitação mais recente desta credencial», o revisor terá aprovado B enquanto olhava para A. Vincule o cartão a um único ID imutável de solicitação e a um único ID de sessão. Quando qualquer um deles deixar de ser válido, o único botão seguro deve ser dispensar.

Evite rótulos como «Sessão 1», «Execução do agente» ou «Tarefa atual». Eles funcionam até a segunda execução começar. O rótulo pode ser amigável, mas a interface precisa de um identificador que continue fazendo sentido depois que um processo reiniciar, um laptop entrar em repouso ou uma análise de incidente ocorrer dias mais tarde.

Coloque os fatos certos nas duas primeiras linhas

As duas primeiras linhas de um pedido de aprovação devem permitir que o revisor diferencie essa solicitação de todas as outras pendentes sem abrir os detalhes. Coloque primeiro a ação solicitada e, logo abaixo, informe diretamente o processo e a sessão que a iniciaram.

Um cartão funcional tem este formato:

Allow POST to api.example.internal/v1/releases?
agent-cli, signed by Example Engineering, session 7TQ4N8M2
Task: Prepare the staging release notes

Creates a release record named "2026.07.22-rc3"
Credential: release-service-write
[Review request]                         [Deny] [Allow]

A linha da ação diz o que acontecerá e onde. A linha de atribuição diz quem pediu. A linha da tarefa mostra a qual trabalho o revisor deve associar a solicitação. A prévia oferece contexto suficiente para uma avaliação inicial. Essa ordem é intencional.

Não comece com «Aprovação solicitada» ou «O agente quer usar um segredo». Nenhuma dessas frases ajuda a organizar uma fila movimentada. Também não comece pelo nome da credencial. Credenciais são detalhes de implementação. Em geral, o revisor sabe se a solicitação pertence à execução correta da versão antes de saber se release-service-write é a chave armazenada adequada.

Para SSH, o pedido equivalente deve nomear o host remoto e a classe do comando, não apenas «acesso SSH». Por exemplo:

Allow SSH command on build-staging-03.example.internal?
agent-cli, signed by Example Engineering, session 7TQ4N8M2
Task: Verify the staging migration

Runs: /usr/local/bin/check-migration --database app_staging
Credential: deploy-ssh
[Review command]                         [Deny] [Allow]

Se o sistema não conseguir produzir uma prévia segura e legível, deve dizer isso. «Argumentos do comando indisponíveis» é melhor do que inventar uma frase simpática que esconda expansão do shell, um script indireto ou uma entrada não inspecionada. O revisor poderá então abrir o comando exato ou recusar a solicitação.

Um bom pedido não obriga o revisor a deduzir a execução iniciadora a partir de um horário. O horário pertence aos detalhes e ao registro de atividades. Dois agentes podem fazer solicitações no mesmo segundo, e as pessoas não usam horários com segurança para relacionar um cartão a um terminal. Use o horário como evidência complementar, nunca como o rótulo responsável pela atribuição.

Também evite colocar o ID da sessão em um rodapé quase invisível. O identificador não é um resíduo de diagnóstico. Em uma fila paralela, é o campo que impede o revisor de tratar dois cartões quase idênticos como intercambiáveis.

Uma fila precisa de agrupamento sem falsas fusões

O trabalho paralelo cria um problema de organização visual. Agrupar cartões por sessão pode ajudar, mas o agrupamento se torna perigoso quando a interface oculta diferenças importantes entre solicitações.

A fila deve permitir que o revisor veja juntas todas as ações pendentes de uma sessão, preservando uma decisão de aprovação por ação quando os efeitos forem diferentes. Um assistente de versões que precisa de três chamadas de API somente para leitura pode aparecer em um grupo compacto. Uma sessão que quer ler uma issue, gravar um registro de implantação e executar uma migração remota deve mostrar três decisões separadas, porque as consequências não são iguais.

O padrão errado é um banner global que diz:

agent-cli requests access to 5 services
[Allow all]

Esse botão pede que o revisor aprove um conjunto antes de atribuir cada item a uma execução ou examinar seus efeitos. Ele também incentiva o cansaço da fila. Quanto mais um revisor vê esse banner, maior a chance de criar o hábito de limpá-lo para voltar ao trabalho.

Uma fila melhor usa cabeçalhos de sessão como contexto, não como autorização ampla:

Session 7TQ4N8M2 · agent-cli · Prepare the staging release notes
2 pending requests

  GET api.example.internal/v1/builds/rc3             [Allow]
  POST api.example.internal/v1/releases              [Review]

Session C5J1W6PA · agent-cli · Investigate test failure #1842
1 pending request

  SSH build-staging-03.example.internal              [Review]

O revisor pode examinar a fila por execução, mas cada linha ainda faz uma afirmação separada. Se o sistema oferecer um estado de autorização por sessão, mostre-o no cabeçalho com um escopo claro: «Esta sessão está autorizada até terminar». Não faça esse estado parecer uma aprovação de todas as ações individuais. A autorização por sessão permite que a execução solicite ações; não transforma ações inesperadas em ações esperadas.

A ordenação também afeta os erros. Uma fila puramente cronológica pode misturar solicitações de cinco execuções a tal ponto que o revisor não consegue manter o contexto de nenhuma delas. Uma fila puramente agrupada por sessão pode esconder uma solicitação urgente atrás de uma sessão barulhenta. Ofereça as duas visões: uma visão agrupada por padrão, para atribuição, e uma visão ordenada por horário, para resposta a incidentes. Mantenha o indicador da sessão visível em ambas.

Não una cartões apenas porque compartilham um destino e uma credencial. Duas execuções diferentes gravando no mesmo endpoint criam exatamente a ambiguidade que a fila deve resolver. A semelhança é motivo para destacar mais a identidade da execução, não para combinar as aprovações.

A aprovação deve se vincular à solicitação exata que o revisor examinou

Um pedido pode identificar a execução correta e ainda autorizar a solicitação errada se a aprovação se aplicar a um modelo mutável, em vez de a uma ação imutável. O revisor deve aprovar uma representação específica da solicitação, não uma solicitação futura que por acaso reutilize a mesma rota, comando ou credencial.

Crie um registro canônico da ação antes que o cartão apareça. Para HTTP, inclua pelo menos o método, a origem e o caminho normalizados, os cabeçalhos selecionados por nome, o alias da credencial e um resumo do corpo. Para SSH, inclua a identidade normalizada do host, a conta solicitada, a porta, os bytes do comando e o alias da credencial. Mantenha o material protegido completo dentro do componente confiável; o agente não deve recebê-lo apenas porque o revisor precisa ver um pedido.

Depois, vincule a aprovação ao registro canônico:

{
  "approval_id": "apr_K9H2D7LQ",
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "action_digest": "sha256:2a13c4e0...",
  "expires_at": "2026-07-22T16:47:11Z",
  "decision": "allow_once"
}

No momento da execução, calcule novamente o resumo a partir da ação que realmente sairá da máquina. Se ele for diferente, recuse a aprovação e crie um novo cartão. Não trate silenciosamente uma solicitação alterada como «suficientemente parecida». Uma mudança em um parâmetro da URL pode redirecionar um pagamento, um cabeçalho alterado pode mudar o escopo da conta e um argumento de shell modificado pode transformar um comando de inspeção em uma gravação.

É aqui que muitos sistemas bem pensados falham. Eles mostram um resumo revisável, aprovam «usar a credencial X para o endpoint Y» e depois permitem que o agente faça uma segunda solicitação com essa autorização ampla. O revisor não examinou a segunda solicitação. O sistema transformou uma decisão explícita em uma regra de política invisível.

Use uma expiração curta para uma aprovação pendente. O objetivo não é punir um revisor que fez uma pausa para tomar café. É impedir que uma decisão antiga seja aplicada depois que o contexto ao redor mudou. Se o agente ainda precisar da ação mais tarde, poderá fazer uma nova solicitação com os mesmos detalhes de processo e sessão. O revisor verá se ela ainda pertence à execução.

Materiais do NIST sobre participação humana em decisões automatizadas alertam para o viés da automação e para ciclos de aprovação com pouco atrito que normalizam a fadiga de alertas. A consequência prática é direta: facilitar o clique não torna a aprovação significativa. A interface precisa tornar a decisão pequena o bastante para ser inspecionada e específica o bastante para permitir responsabilização.

A visualização de detalhes deve resolver disputas, não criá-las

Um cartão compacto não consegue conter todos os bytes de uma solicitação. Ele precisa, porém, de uma visualização de detalhes capaz de responder às perguntas de um revisor cuidadoso quando a ação for desconhecida, cara ou suspeita.

Para uma ação HTTP, mostre o método e a URL completos, os cabeçalhos ocultados por padrão, os campos do corpo com tratamento claro dos segredos, o alias da credencial, a identidade do processo iniciador, o ID da sessão, o rótulo da tarefa e o horário de criação. Se o corpo for binário ou grande demais para exibição, mostre seu tamanho, tipo de conteúdo e resumo. Não finja que um resumo em uma linha é substituto suficiente.

Para SSH, mostre o host, o usuário, a porta, o estado de verificação do host quando disponível, o comando exatamente como será executado, o diretório de trabalho quando relevante e os valores de ambiente que afetam o comportamento. A prévia deve preservar aspas e limites dos argumentos. Renderizar um array como uma string de shell vagamente concatenada pode fazer um comando seguro parecer perigoso ou, pior, fazer um comando perigoso parecer inofensivo.

Existe uma diferença importante entre ocultar por segurança e omitir por conveniência. Oculte um token bearer, uma chave privada, uma senha ou um valor sensível do corpo no pedido. Não oculte o caminho, a conta de destino, o host remoto, o comando ou o campo alterado apenas porque os detalhes deixam o cartão mais longo. Esses são frequentemente os fatos que mostram se a solicitação pertence à execução atual.

Use uma impressão digital estável da solicitação na visualização de detalhes. Um revisor que enviar uma mensagem a um colega deve poder dizer «recusei a solicitação apr_K9H2D7LQ da sessão 7TQ4N8M2», e o colega deve encontrar exatamente um registro. Nunca obrigue as pessoas a descrever um evento como «o segundo pedido de implantação por volta das 4h40». Isso funciona até que um incidente exija precisão.

A superfície de revisão também deve declarar o que a aprovação autoriza e o que não autoriza. Por exemplo:

Allow once
This decision authorizes only this POST request with digest 2a13c4e0…
It does not authorize later calls from session 7TQ4N8M2.

Essa frase merece espaço. Ela impede que o revisor presuma uma autorização ampla e impede que alguém amplie o escopo depois mantendo o mesmo rótulo do botão.

Cancelamento e revogação precisam ter consequências visíveis

Mais cedo ou mais tarde, um revisor aprovará o cartão errado ou perceberá que uma execução saiu do rumo. A recuperação precisa ser rápida, visível e associada aos mesmos identificadores usados durante a aprovação.

A interface precisa de ações separadas para recusar uma solicitação e revogar uma sessão. Recusar significa «não execute esta ação». Revogar significa «este processo perdeu a autorização, cancele suas aprovações pendentes e recuse as ações posteriores». Como as consequências são diferentes, as ações não devem compartilhar um botão ambíguo de «Parar».

Quando o revisor revogar uma sessão, mostre uma confirmação com o processo, o ID da sessão e a tarefa:

Revoke session 7TQ4N8M2?
agent-cli is running “Prepare the staging release notes.”
Pending requests from this session will be cancelled. New protected actions
from this process will be denied until it starts a new session.
[Keep session] [Revoke session]

Se uma solicitação já estiver em execução, informe isso honestamente. A revogação pode impedir ações privilegiadas futuras, mas talvez não desfaça uma solicitação HTTP que um serviço remoto já aceitou nem interrompa um comando remoto que já começou. O registro de atividades deve indicar se a ação estava pendente, foi enviada, concluída, falhou ou foi cancelada. Não escreva «revogada» de modo a sugerir que o efeito externo desapareceu.

Essa é outra razão para exibir o ID da sessão em todos os cartões. Durante um incidente estressante, o revisor precisa de uma ligação direta entre uma solicitação suspeita e o controle que interrompe aquela execução. Se a fila disser apenas «agent-cli», a revogação pode encerrar a execução útil e deixar a problemática ativa.

O diário da sessão e o diário de atividades devem usar os mesmos identificadores. Um registro informa que a sessão 7TQ4N8M2 do processo começou, recebeu autorização e foi revogada. O outro mostra qual ação individual ela tentou antes e depois de cada mudança de estado. Se os registros usarem rótulos sem relação, a equipe perderá tempo reconstruindo associações que o produto deveria ter deixado explícitas.

Teste a aprovação da execução errada antes dos usuários

Você pode testar essa falha sem uma equipe de ataque ou uma interrupção em produção. Execute duas instâncias do mesmo cliente de agente no mesmo workspace e peça que façam chamadas protegidas semelhantes. O teste só será bem-sucedido se um revisor conseguir identificar cada solicitação corretamente em uma fila movimentada.

Faça este exercício:

1. Inicie a execução A com o rótulo «Inspecionar o build de staging com falha».
2. Inicie a execução B com o rótulo «Publicar o registro da versão de staging».
3. Faça as duas execuções solicitarem a mesma credencial em poucos segundos.
4. Torne semelhantes as primeiras solicitações, como duas chamadas para a mesma origem de API.
5. Altere uma ação para que aprová-la para a outra execução tenha um efeito visível e indesejado em um ambiente de teste.

Depois, peça a alguém que não criou a interface que aprove apenas a solicitação da execução B. Não diga qual cartão é B pela posição na fila. Observe o que essa pessoa usa. Se ela depender de horários, da ordem dos cartões ou da memória de qual terminal abriu primeiro, a interface falhou. Se conseguir apontar a autoridade do processo, o ID da sessão, a tarefa, o destino e a ação sem abrir outra tela, você tem um ponto de partida utilizável.

Teste também o comportamento de aprovações obsoletas. Crie um cartão para a execução A, encerre A, inicie B e clique no cartão antigo. O sistema deve recusar o clique e explicar que a solicitação não está mais ativa. Repita o teste depois de alterar o corpo de uma solicitação ou um argumento SSH após a revisão. O sistema deve exigir uma nova aprovação, em vez de aplicar a antiga à ação modificada.

Teste nomes que colidem. Duas tarefas podem se chamar «Corrigir CI». Dois repositórios podem ter o mesmo nome de diretório. Duas branches podem compartilhar o número de uma versão. O texto amigável ajuda as pessoas, mas o projeto completo ainda precisa funcionar quando esse texto for ambíguo.

A autorização por sessão do Sallyport oferece um lugar natural para estabelecer esse limite: a primeira chamada de um novo processo de agente identifica a execução para aprovação, enquanto chaves por chamada podem exigir uma aprovação separada para cada uso. Mantenha o rótulo da sessão e a autoridade do processo visíveis quando esses controles aparecerem, ou as execuções paralelas voltarão a se fundir em um único «agente» indistinto.

O registro de auditoria deve reproduzir a decisão de aprovação

Um registro de auditoria só é útil quando consegue responder, depois do fato, o que o revisor viu e o que o sistema executou. Registrar «usuário aprovou acesso à API» não basta. A questão central continua sem resposta: acesso para qual execução, para qual ação e com qual contexto exibido?

Para cada decisão, registre os identificadores imutáveis e os fatos da apresentação:

{
  "event": "approval_granted",
  "approval_id": "apr_K9H2D7LQ",
  "session_id": "ses_7TQ4N8M2KDXP6R9V",
  "process_identity": "agent-cli / Example Engineering (Team ABCD1234)",
  "task_label": "Prepare the staging release notes",
  "action_digest": "sha256:2a13c4e0...",
  "displayed_action": "POST api.example.internal/v1/releases",
  "decision_scope": "once",
  "recorded_at": "2026-07-22T16:44:03Z"
}

Armazene o registro canônico da ação separadamente ou junto dele, com criptografia e controles de acesso adequados. O evento de auditoria deve dizer ao investigador o que o cartão mostrava; o registro canônico deve provar quais bytes e qual destino o componente confiável usou. Se os dois forem diferentes, trate isso como uma falha de segurança, não como um detalhe de registro.

Um log encadeado por hashes ajuda a detectar alterações no histórico, mas não corrige um conteúdo de evento vago. Você pode provar criptograficamente que «aprovação concedida» não foi alterado e ainda assim não saber qual solicitação recebeu a aprovação. Integridade e atribuição resolvem problemas diferentes. Você precisa das duas.

Os projetos do Sallyport mantêm registros de sessão e de chamadas individuais em um único log de auditoria criptografado e encadeado por hashes. O comando sp audit verify verifica a cadeia offline sobre o texto cifrado. Isso é útil porque os revisores podem conservar evidências de que o log não foi reescrito sem expor os segredos armazenados durante a verificação.

O teste final do projeto é simples. Escolha uma ação concluída e volte no histórico: um investigador consegue identificar o processo, a sessão específica, o rótulo da tarefa mostrado na ocasião, a solicitação exata revisada, o escopo da decisão do revisor e o resultado? Depois, parta de uma sessão: consegue ver, em ordem, todas as ações pendentes, recusadas, aprovadas, canceladas e executadas? Se qualquer direção exigir suposições, a fila ainda permite o erro de aprovar a execução errada.

Agentes paralelos tornarão as filas de aprovação comuns. A solução não é soterrar os revisores em mais cartões nem oferecer um único controle amplo de «permitir tudo». Dê a cada processo em execução uma identidade de sessão durável, coloque-a ao lado da ação onde as pessoas realmente olham e vincule cada clique à solicitação examinada pelo revisor. É assim que uma aprovação continua tendo significado quando vários agentes estão ativos ao mesmo tempo.