Quatro Fornecedores Puseram o Controle no Gargalo. Um Engenheiro Chama Isso de Teatro.

TV
Thiago Victorino
8 min de leitura
Quatro Fornecedores Puseram o Controle no Gargalo. Um Engenheiro Chama Isso de Teatro.

A Docker nomeia três superfícies onde um agente pode ser restringido: “acesso de rede, o sistema de arquivos e as ferramentas que um agente consegue alcançar.” A NVIDIA relata uma “redução de 55%” em eventos repetidos de login depois de rotear o acesso às plataformas internas de desenvolvimento por um único registro de sessão federado. A Cloudflare descreve um pipeline de remediação em que “se uma dessas verificações falha, o fluxo para antes que a proposta chegue à revisão do cliente.” Um ensaio de design no UX Collective argumenta que a superfície de aprovação é “a camada de política do produto.”

Quatro publicações no mesmo mês, de um fornecedor de containers, um fabricante de chips, uma plataforma de borda e um ensaio de design, chegando ao mesmo instinto arquitetural: parar de pedir bom comportamento ao agente e colocar a restrição em um lugar onde ele não tem como discutir.

Jake Gold, que constrói infraestrutura de IA na clor.com, publicou no mesmo mês uma frase que desmonta a versão confortável desse instinto: “Um agente que nunca vê minha chave privada SSH mas ganha um shell root ainda consegue dar rm -rf no sistema de produção.”

Os dois lados estão certos. O trabalho interessante é descobrir quando.

O que a convergência de fato diz

Vale citar o texto da Docker sobre o modo YOLO porque é a formulação mais clara dessa posição, e vale atribuí-lo porque a Docker vende o produto que a implementa. Eric Jia e Srini Sekaran escrevem: “Para um desenvolvedor sozinho em um laptop com sandbox, o modo YOLO é uma escolha pessoal. Em um time, vira uma questão de política… O quadro que funciona em escala é aquele em que o caminho seguro é o padrão.”

Esse é o argumento de um fornecedor, e também é um argumento correto. A passagem de escolha pessoal para questão de política é a transição para a qual o texto foi escrito, e é a que eu venho encontrando nas organizações de engenharia. A Docker cita a Stack Overflow Developer Survey de 2025 para o número de adoção por trás disso: “84% dos desenvolvedores disseram que usam ou pretendem usar ferramentas de IA em seu fluxo de trabalho, contra 76% um ano antes.” O dado é de segunda mão, reportado pela Docker e não medido por ela, dentro de um texto que vende ferramenta de governança. Trate como direcional.

As três superfícies que a Docker nomeia são a parte útil. Rede, sistema de arquivos, ferramentas. Cada uma é um lugar onde a restrição pode ser expressa uma vez, pelo time de plataforma, e valer para todo agente que rodar. Nenhuma delas depende da cooperação do agente. Já discutimos a versão em camadas disso no stack de contenção e na revisão das quatro camadas, então as camadas não são a novidade aqui.

A contribuição da Cloudflare é o formato de um fluxo que para. Blake Darché descreve um pipeline de descoberta e remediação de vulnerabilidades em que verificações automáticas filtram o que chega a um humano e em que, sobre correções propostas, “você decide se elas são implementadas.” Isso é um gargalo com uma propriedade específica: o agente produz, o pipeline avalia e o pipeline pode recusar. O agente não tem rota alternativa porque a recusa mora no pipeline, não nas instruções do agente.

A dissidência

O texto de Gold não traz nenhuma estatística, e é mais útil por isso. A posição dele é que escopo de credencial costuma resolver um problema vizinho ao que você tem. Dá para remover todo segredo do ambiente do agente, comemorar o raio de dano reduzido e mesmo assim ter entregado alcance operacional suficiente para acabar com a empresa.

O raciocínio dele para conceder acesso a produção merece leitura literal: “Dou acesso de produção a agentes pelo mesmo motivo que dou acesso a colegas inexperientes.” Isso é uma afirmação sobre proporcionalidade. Um colega inexperiente também consegue derrubar uma tabela. Você lida com isso via reversibilidade, revisão e observabilidade, e não fingindo que o acesso não existe.

A versão do argumento do gargalo que falha no teste dele se parece com isto. Um time restringe bem as credenciais do agente, remove as chaves SSH, injeta tokens de curta duração, e então roda o agente como root dentro de um container que tem o banco de produção montado. Todo controle de credencial ali é real. Todos eles ficam ao lado da capacidade efetiva do agente, em vez de embaixo dela.

O teste: embaixo ou ao lado

Um gargalo vale quando fica embaixo do alcance operacional do agente. Não vale quando fica ao lado.

Embaixo significa que a ação do agente atravessa o controle no caminho para ter qualquer efeito. A fronteira do sistema de arquivos fica embaixo: o agente escreve, o kernel decide. O portão da Cloudflare fica embaixo: a proposta é produzida, depois o fluxo para, e parar não é algo que a proposta consiga vetar. O registro de sessão da NVIDIA fica embaixo em uma dimensão específica, à qual eu volto adiante.

Ao lado significa que o controle governa uma rota até o efeito enquanto outra rota segue aberta. Escopo de credencial fica ao lado sempre que o shell que o agente já tem alcança o alvo sem essas credenciais. Uma lista de ferramentas permitidas fica ao lado se a lista inclui um shell de uso geral. Um prompt de aprovação fica ao lado se o agente consegue a mesma coisa por uma ação que não dispara o prompt.

Rode o teste no seu próprio ambiente nomeando primeiro o pior desfecho, e depois perguntando qual controle intervém fisicamente no caminho até ele. Se a resposta for um controle que governa outro caminho, você decorou a porta errada.

Identidade é a parte que os ensaios de contenção deixam em aberto

O texto da NVIDIA, de Bhagat Khemchandani e Rohan Somvanshi, trata de um problema mais estreito que contenção, e preenche um buraco que os ensaios sobre contenção deixam aberto. O tema deles é carregar a identidade humana por trás da requisição de um agente através de Kubernetes federado e plataformas de IA distribuídas entre clusters AWS e OCI. Um registro de sessão, propagado, revogável em todo lugar de uma vez.

O detalhe operacional que vale copiar: “Remova cabeçalhos de identidade que chegam de fora antes de injetar os confiáveis.” Uma afirmação de identidade vinda de fora da sua fronteira de confiança tem o status de alegação, e o sistema precisa tratá-la assim. Se você injeta cabeçalhos confiáveis sem remover os de entrada, construiu um sistema em que qualquer um a montante pode se autonomear.

O resultado reportado é uma “redução de 55%” em eventos repetidos de login nas plataformas internas de desenvolvimento deles. É um número de experiência do desenvolvedor, não de segurança, e é a NVIDIA reportando sobre a NVIDIA. O que ele demonstra é que centralizar o registro de sessão não custou o atrito que as pessoas esperam disso.

Esse é um problema diferente de ancorar a identidade do próprio agente, que cobrimos em identidade durável de agentes. Aqui a pergunta é de quem é a autoridade que o agente está tomando emprestada, e se você consegue retirá-la em um único lugar.

Contar aprovações é o instrumento errado

O ensaio de Aurélie Radom no UX Collective (a bio dela lista Metalab e Frog como passagens anteriores) faz um ponto que se perde assim que aprovação vira métrica: “O envolvimento humano não deveria ser medido por quantas vezes uma pessoa precisa clicar em aprovar. O que importa é se as pessoas seguem no controle das decisões que dependem de julgamento, contexto ou preferência.”

Times que medem contagem de aprovação otimizam a coisa errada nas duas direções. Ou acrescentam prompts até o humano clicar sem ler, ou removem prompts para bater uma meta de velocidade e perdem justamente as decisões que importavam. A formulação dela, “esta é a camada de política do produto”, coloca o desenho dessa superfície onde ele pertence, ao lado de quem responde pelo produto, em vez de restrito à revisão de segurança.

O checklist de quatro perguntas que ela propõe para delegar trabalho a um agente é o artefato mais portátil das cinco publicações:

“O que o agente pode fazer sem perguntar? / Quando ele deveria pedir confirmação? / Quais ações deveriam ser reversíveis? / Quais decisões deveriam sempre permanecer com uma pessoa?”

A terceira pergunta é a que resolve a objeção de Gold. Reversibilidade é uma propriedade do efeito e sobrevive a um shell root.

Faça isto agora

Pegue um agente que roda contra um sistema de produção. Escreva a pior coisa que ele conseguiria fazer. Depois responda duas perguntas por escrito.

Primeira: qual controle fica fisicamente no caminho entre o agente e esse desfecho? Nomeie o mecanismo, não a política. “O agente não deveria” não é mecanismo. Se a única resposta que você tem é escopo de credencial, e o agente tem um shell em um host que alcança o alvo, seu controle está ao lado, não embaixo.

Segunda: se esse desfecho acontecesse às três da manhã, em quanto tempo ele seria revertido, e por quem? A pergunta de reversibilidade da Radom é mais barata de responder do que reconstruir contenção, e é o controle que se sustenta quando o gargalo não se sustenta.

Faça as duas para um agente esta semana. A resposta vai dizer se o próximo passo é continuar construindo o gargalo ou começar a construir o desfazer.


Fontes

A Victorino ajuda times de engenharia a distinguir quais controles de agentes ficam embaixo do alcance operacional e quais apenas parecem ficar: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa