Human in the Loop para MCP: TrueFoundry vs Kong

Human in the Loop para MCP: TrueFoundry vs Kong

O Human in the Loop (HITL) para MCP é uma política de gateway que pausa chamadas de ferramentas selecionadas até que um humano designado as aprove ou negue. Isso permite que empresas confiram autonomia real aos agentes de IA sem transformar cada ação irreversível em um risco sem controle.

A autenticação prova quem é o agente. A autorização prova o que ele pode chamar. O HITL responde à pergunta final que nenhuma das duas consegue: esta ação específica deve acontecer agora? Sem o HITL, um erro autorizado pode se tornar um incidente crítico (P1), desencadear a remoção total do acesso de escrita do agente e paralisar todo o programa de agentes.

Resumo

A diferença entre TrueFoundry e Kong reside em onde a aprovação humana ocorre. O Kong opera como um gateway de API sem estado: ele avalia cada chamada de ferramenta MCP e a autoriza ou nega de forma síncrona, sem manter o estado do fluxo de trabalho necessário para pausar e retomar uma solicitação. A TrueFoundry consegue reter uma chamada de ferramenta no gateway, notificar os aprovadores responsáveis e emitir uma permissão com escopo e tempo limitados. Empresas que utilizam o Kong precisam construir e operar esse fluxo de trabalho de aprovação humana por conta própria.

Por que o Human in the Loop é importante

Quando a permissão não é suficiente

Imagine uma equipe de plataforma de serviços financeiros. Seus agentes acessam sistemas internos apenas por meio de um gateway MCP. Identidade, RBAC e logs de auditoria já estão implementados. Um agente de limpeza pode acessar o Kubernetes, contas de nuvem e o Slack, incluindo uma ferramenta destrutiva de banco de dados.

Agora, dê a esse agente uma instrução razoável de fim de trimestre: "Limpe a infraestrutura não utilizada". O risco torna-se visível quando você acompanha a solicitação desde a permissão até a consequência.

‍Fig. 01 · Uma identidade e um gateway autorizam ambos os caminhos. A diferença não é o acesso; é a consequência.

O agente começa com um trabalho inofensivo: listar pods, escalar implantações ociosas e inventariar bancos de dados. Então, ele encontra o db-fin-rpt-01, sem uso há 34 dias. A heurística indica que está obsoleto, então ele chama o delete_database.

A chamada é válida, autenticada, autorizada e registrada. Esse é precisamente o problema: todos os controles convencionais respondem se a chamada é permitida, enquanto nenhum pergunta se essa ação irreversível faz sentido neste momento.

O que acontece quando o HITL está ausente

Uma vez que a chamada é executada, a falha técnica é recuperável. A perda de confiança na autonomia do agente, não.

Fig. 02 · Uma exclusão válida passa de invisível a urgente e termina com o congelamento do acesso de escrita do agente.

Do ponto de vista do VP de Engenharia, a lição não é que o agente não tinha controles; ele tinha todos eles. A falha foi a ausência da decisão entre permitir e negar. Uma breve aprovação antes do delete_database poderia ter evitado tanto o incidente P1 de fim de trimestre quanto o retrocesso posterior para agentes somente de leitura.

O HITL cria esse terceiro caminho. Leituras de rotina e alterações reversíveis continuam na velocidade da máquina; excluir, pagar, enviar e implantar aguardam um humano designado. O exemplo agora se torna um problema de política de gateway, e não uma lógica de recuperação que cada equipe de agentes precisa reinventar.

Como a TrueFoundry implementa o HITL

A TrueFoundry transforma esse terceiro caminho em uma política de gateway MCP de primeira classe. As equipes de plataforma definem uma única vez quais ferramentas exigem aprovação, e a regra é aplicada a todos os agentes, clientes e frameworks.

Reter, notificar, decidir

Aplique isso ao db-fin-rpt-01: quando o agente chama delete_database, o gateway retém a solicitação antes da execução, notifica um aprovador autorizado e retorna uma resposta de "aprovação pendente" que o agente pode tentar novamente com segurança. Uma aprovação cria uma concessão com limite de tempo, restrita ao solicitante, ao servidor e à ferramenta.

‍ 03 · A chamada pausa no gateway e só é retomada mediante uma aprovação restrita, ou permanece bloqueada com um motivo registrado.

Como o estado de aprovação reside no gateway, as equipes de aplicação não precisam reimplementar a lógica de pausa, retomada, notificações, tratamento de negação e auditoria para cada agente. Apenas administradores de tenant e Aprovadores de Servidor MCP designados podem decidir.

Para a equipe de plataforma, a configuração permanece como uma definição de política: selecione o servidor e as ferramentas, defina a janela de validade, escolha um canal de notificação e salve. Quando as regras se sobrepõem, a política mais restritiva prevalece. É nesse limite de fluxo de trabalho que a comparação com o Kong começa.

O que falta no Kong

Os controles MCP do Kong autenticam agentes, aplicam ACLs de ferramentas e permitem ou negam chamadas. Eles não suportam um fluxo de trabalho de aprovação nativo que possa reter uma chamada de ferramenta, de outra forma permitida, enquanto um humano decide.

Essa é a camada que falta. O HITL (Human-in-the-loop) é stateful: o gateway precisa persistir uma solicitação pendente, notificar aprovadores autorizados, registrar a decisão e emitir uma concessão restrita e com prazo de validade. Uma decisão binária de permitir/negar por solicitação não consegue fornecer esse fluxo de trabalho por si só.

Por que isso se torna um problema de plataforma

• Engenharia duplicada: cada equipe de agente precisa implementar o estado de pausa e retomada, roteamento de aprovadores, novas tentativas, timeouts, tratamento de negação e eventos de auditoria.
• Desvio de política: cada implementação faz escolhas diferentes sobre quais ferramentas são controladas, quem pode aprovar e quanto tempo dura a aprovação. As equipes de plataforma perdem um padrão único e aplicável.
• Carga operacional: centralizar isso em um serviço separado ainda significa ser responsável por um novo produto interno, disponibilidade, tenancy, RBAC, idempotência, falhas de notificação, atualizações e plantões.
• Evidências fragmentadas: aprovações e negações ficam espalhadas entre serviços de agentes e canais de chat, tornando a análise de incidentes e a coleta de evidências de conformidade mais lentas e menos confiáveis.
• Resultado para a empresa: as equipes atrasam o uso de agentes com permissão de escrita ou recorrem a um acesso de leitura apenas. Ambos reduzem a velocidade de desenvolvimento e o retorno sobre os investimentos em agentes.

TrueFoundry vs Kong: comparação de HITL

Todos esses custos decorrem do mesmo limite arquitetural: o Kong governa a solicitação, enquanto a empresa precisa construir o ciclo de vida de aprovação em torno dela. A comparação abaixo torna esse limite explícito.

O teste de avaliação de 10 minutos

A tabela de recursos se resume a um teste prático de aquisição. Pergunte a cada fornecedor: “Um agente autorizado solicita uma ação irreversível em um MCP. Mostre-me a aprovação humana, a política que a acionou e a trilha de auditoria resultante.”

Se a demonstração depender de código de fluxo de trabalho personalizado em cada agente, a aprovação não é uma capacidade de plataforma; é dívida técnica de aplicação.

Agende uma demonstração e proteja sua chamada de ferramenta mais arriscada em uma tarde, ou explore a Gateway de AgenteseMCP Gateway documentação.