Por que reavaliar cada execução se o agente já tem acesso às ferramentas? Do GitHub MCP a uma cadeia de evidências de tarefa

O acesso às ferramentas responde ao que um agente pode fazer em princípio. A autorização de execução pergunta se essa ação, contra esse alvo, com essas evidências, pode acontecer agora. Entre os dois, há uma fronteira que precisa ser reavaliada.

Resumo

Recentemente, corrigimos o que parecia ser um pequeno problema no CodeFlowMu: uma tarefa que deveria ter sido permitida a continuar foi interrompida por um portão de segurança.

CodeFlowMu é um sistema de colaboração multi-agente executado localmente que utiliza tarefas, papéis, portões, relatórios e aprovações para organizar o trabalho do agente em uma cadeia de execução que pode ser rastreada, recuperada e verificada.

A falha não foi que um agente não tinha acesso às ferramentas, e a tarefa não havia realmente ultrapassado seu escopo autorizado. O que aconteceu foi mais sutil: uma informação que deveria apenas ter alertado a pessoa responsável foi promovida pelo Runtime a uma razão para negar a execução.

Esse incidente nos forçou a revisitar uma questão mais básica:

Se um agente já tem Git, Shell ou outra ferramenta, por que o sistema deve reavaliar cada execução concreta?

Ao mesmo tempo, o servidor MCP oficial do GitHub está lidando com um problema estruturalmente semelhante em um nível de autorização diferente. O GitHub MCP se preocupa com permissões OAuth; o CodeFlowMu se preocupa com a qualificação da execução da tarefa. Eles não são o mesmo sistema e não usam o mesmo modelo de autorização, mas ambos estão se movendo em direção à mesma fronteira:

Capacidade estática → chamada atual → contexto atual → autorização para esta execução

Em outras palavras: ser capaz de usar uma ferramenta não significa automaticamente que essa invocação específica é autorizada.

Este artigo não afirma que o CodeFlowMu já possui uma arquitetura de autorização de agente completa. A observação mais interessante é uma convergência de engenharia: dois sistemas independentes estão movendo a autorização para longe de “que capacidade este principal possui?” e em direção a “a execução atual ainda satisfaz as condições sob as quais pode acontecer?” O CodeFlowMu também tem algo mais concreto do que um argumento: uma falha registrada, correções sucessivas, dados de regressão e verificações ao vivo controladas.

1. Como uma verificação de segurança bloqueou uma tarefa legítima?

Uma cadeia de trabalho típica do CodeFlowMu pode ser reduzida a:

Requisito → PM → Tarefa → DEV / OPS / QA → Relatório → Revisão / Aprovação → Concluído

Tal sistema precisa de portões. Uma tarefa raiz fechada, um alvo fora do escopo da tarefa, uma aprovação obrigatória ausente ou uma dependência necessária não atendida podem ser razões válidas para negar uma ação.

O problema é que nem toda condição imperfeita tem esse significado. “Seria melhor adicionar uma nota de aceitação” ou “o plano poderia ser mais completo” podem ser informações úteis, mas essas declarações são consultivas, não automaticamente vetos.

Essa distinção é onde essa falha do CodeFlowMu ocorreu. Uma condição que deveria ter produzido “avise a pessoa responsável e deixe um tomador de decisão autorizado julgá-la” foi interpretada como “condição não satisfeita, portanto a execução é negada.” O agente não havia ultrapassado os limites e a tarefa não havia saído do escopo. O próprio guardrail cruzou a fronteira da decisão.

É por isso que a verdadeira questão não é simplesmente passar ou falhar. É quais fatos têm a autoridade para produzir uma negação.

Um sistema pode ter a capacidade técnica de bloquear uma ação sem ter a autoridade para bloquear cada estado indesejável. A regra de engenharia que mantivemos a partir deste incidente é, portanto, simples:

Aconselhamento não é um veto. Apenas fatos com autoridade de negação devem ser suficientes para negar a execução.

Um guardrail confiável deve saber não apenas quando fechar o portão, mas quando não tem autoridade para fechá-lo.

2. Por que 87/87 ainda não foi suficiente

A primeira verificação focada passou rapidamente: 87 / 87. Se o objetivo tivesse sido um número limpo, o trabalho poderia ter parado por aí. Mas um portão não existe isoladamente; seu significado se propaga através de uma cadeia:

Regra → Runtime → API / Shell → processo ao vivo → UI

Qualquer camada que ainda carregue a antiga semântica pode deixar o sistema real errado. Isso é exatamente o que aconteceu:

O número importante não é 1702. O fato importante é que o sistema ao vivo ainda tinha um problema após 1702 / 1702 ter passado.

O Runtime tinha o estado canônico correto, mas a API não emitia mais um campo de compatibilidade que a página ainda esperava. A UI poderia, portanto, renderizar um campo ausente como um conflito. Isso nos dá uma segunda regra: testes passando não significam que o sistema está correto.

É também por isso que as evidências retêm as rodadas falhadas e a primeira falha ao vivo em vez de preservar apenas o resultado final positivo. Remover essas falhas removeria grande parte da informação de engenharia.

3. Isso não foi um bug; foi uma fronteira recorrente

Se este fosse o único incidente, seria fácil chamá-lo de uma condição ruim. O recente registro de engenharia do CodeFlowMu é mais amplo do que isso.

Através da governança de tarefas, tivemos que lidar com o planejamento consultivo se tornando um veto, novas semânticas de governança quebrando mecanicamente a reprodução histórica, o histórico de aprovações entrando na visão de governança, a identidade e o conteúdo da aprovação permanecendo alinhados, decidindo quais fatos sobrevivem à recuperação de sessão, mantendo as interpretações do estado da tarefa do Runtime e da UI consistentes, e decidindo se o estado obsoleto pode ser reutilizado após Retry ou Recovery.

Esses problemas parecem diferentes na superfície, mas continuam apontando para a mesma estrutura mais profunda: se uma ação pode acontecer não pode ser decidida apenas pela lista de papéis e ferramentas do agente. Também depende da tarefa atual, alvo, revisão, va