Não Confie no Agente, Medeie-o: OpenShell, 1Password e GitHub Convergem

Entre 15 e 16 de julho de 2026, três fornecedores publicaram arquiteturas que resolvem o mesmo problema sem citar uns aos outros. A NVIDIA lançou o OpenShell, aplicação de política em nível de kernel sobre arquivos, processos e rede de um único agente. A 1Password lançou injeção de credencial em tempo de execução para o Claude, em que o segredo entra no caminho de execução mas nunca entra no contexto do modelo. O GitHub publicou resultados do Agentic Workflows: 82 PRs de documentação mesclados ao longo de uma migração real, com toda escrita passando por um pipeline que o agente não consegue contornar.

Nenhum desses times chama o próprio trabalho de “mediação”. Os três construíram exatamente isso. O movimento comum: parar de perguntar se o agente pode ser confiável e construir um plano pelo qual ele tem que passar, seja qual for a resposta.

A pergunta antiga estava errada

Por dois anos, o debate sobre governança de agentes girou em torno de confiança: quanta autonomia conceder, qual limiar de confiança justifica tirar um humano do loop, quais agentes “conquistaram” permissões mais amplas. Essa moldura assume que confiança é a variável que libera capacidade.

Os três lançamentos de julho rejeitam essa premissa. O OpenShell não pergunta se o plano do agente é confiável; ele avalia toda abertura de arquivo, todo processo iniciado e toda chamada de rede contra uma política em nível de kernel no momento da chamada, independentemente da intenção do agente. A 1Password não pergunta se o agente deveria ver a senha de um banco de dados; ela injeta a credencial no ambiente de execução no momento do uso, de modo que a janela de contexto do modelo nunca contém um valor que ele possa vazar, registrar em log ou repetir. O padrão safe-outputs do GitHub não pergunta se o commit proposto pelo agente é sólido; ele faz o agente emitir uma intenção estruturada em JSON, depois roteia essa intenção por um pipeline de tokens escopados, com bloqueios de arquivos protegidos e revisão obrigatória antes que qualquer coisa toque o repositório.

Mesma arquitetura em três domínios. O agente age; a camada de mediação decide no que a ação de fato se transforma.

O que cada camada medeia

O OpenShell medeia a chamada de sistema. Segundo o texto da Tigera, o kernel aplica política sobre arquivos, processos e acesso de rede para um único agente em execução, independentemente do que o agente acredita estar autorizado a fazer. É a contenção movida de “o prompt do agente diz para não fazer isso” para “o kernel não vai deixar”, que é a única versão dessa frase que vale a pena sustentar em produção.

A 1Password medeia a credencial. Nancy Wang, CTO da 1Password, descreveu o design como permitir que “um usuário dê a um agente permissão para usar uma credencial sem deixar o agente vê-la”. A distinção importa mais do que parece. Um modelo de permissão que entrega um token ao agente ainda deixa esse token sentado no contexto, a um prompt injetado de distância da exfiltração. Injeção em tempo de execução com consentimento biométrico remove o token da visibilidade do modelo por completo; o agente aciona o uso de uma credencial, nunca a possui.

O GitHub medeia a escrita. Os números mais concretos do trio vêm da própria implantação medida pelo GitHub: 82 PRs de documentação mesclados durante a migração de Aspire 13.3 para 13.4, intervalo mediano de 44,8 horas entre uma funcionalidade entrar no repositório e o PR de documentação correspondente aparecer, 38% desses PRs mesclados em menos de 24 horas, e taxa de mesclagem de 100% nos PRs gerados que chegaram à revisão. Tokens de App escopados limitaram o agente a dois repositórios. Regras de arquivos protegidos bloquearam categorias inteiras de mudança. A saída do agente nunca foi um commit; foi uma intenção estruturada que um pipeline separado e auditável transformou em um. O GitHub também relatou ter reduzido uma taxa inicial de 13% de falsos positivos por meio de prompts mais restritos, evidência de que o problema dos falsos positivos se resolve na camada de mediação, não no modelo.

Por que mediação supera modelos de permissão

Um modelo de permissão é um portão pelo qual o agente passa uma vez, no início da sessão, depois do qual suas ações são suas próprias. Uma camada de mediação é um portão pelo qual o agente passa a cada ação, durante toda a sessão. A diferença aparece exatamente no momento em que um agente é comprometido, confundido ou simplesmente errado: um modelo de permissão já entregou tudo o que ia entregar, enquanto uma camada de mediação continua avaliando.

É também por isso que nenhum dos três fornecedores descreve seu trabalho como pontuação de confiança. A política do OpenShell não afrouxa conforme um agente prova confiabilidade ao longo do tempo; toda chamada de sistema é avaliada da mesma forma na sessão mil e na sessão um. A injeção da 1Password não relaxa porque um agente rodou limpo por um mês; a credencial é invisível todas as vezes. O pipeline do GitHub não pula a revisão porque os últimos vinte PRs foram limpos; toda intenção passa pelo mesmo caminho escopado. Mediação é sem memória por design, e é essa propriedade que a torna auditável: a regra aplicada à ação dez mil é comprovadamente a mesma aplicada à ação um.

Onde os três param

Nenhum desses sistemas trata o agente como identidade durável ao longo de sessões, times ou organizações. O escopo do OpenShell é explicitamente um único agente dentro de um único sandbox; o próprio texto da Tigera nomeia a fronteira que ele não cruza: identidade de agente e governança agente a agente. A 1Password medeia o uso de uma credencial por um agente de cada vez; nada na arquitetura descreve como uma frota de agentes negocia recursos compartilhados ou como a ação mediada de um agente é atribuível quando três agentes em um pipeline tocaram o mesmo arquivo. O pipeline safe-outputs do GitHub governa escritas de um único workflow automatizado para dois repositórios nomeados; ele não diz nada sobre o que acontece quando a saída desse workflow vira entrada de um segundo workflow, nem se a disciplina de token escopado sobrevive à passagem de bastão.

Juntando as três peças, o padrão está completo no nível da ação individual e incompleto no nível da frota. Uma chamada de sistema é policiada. Uma credencial permanece selada. Um commit é revisado. Nenhum dos três responde quem é o agente ao longo de uma semana de sessões, como dois agentes estabelecem confiança compartilhada em um recurso que nenhum dos dois controla, ou como um auditor rastreia um resultado por uma cadeia de passagens de bastão entre agentes, em vez de uma única chamada mediada.

Faça isto agora

Audite um pipeline de agente em produção contra as três camadas, não contra a pergunta de confiança. Onde o código é executado, e uma fronteira de kernel ou sandbox aplica política por ação, ou é apenas uma instrução de prompt que o agente poderia ignorar? Onde as credenciais entram no contexto de trabalho do agente, e você poderia substituir exposição direta por injeção em tempo de execução ainda neste trimestre? Onde a saída do agente vira uma escrita, e existe um pipeline escopado e revisável entre a intenção do agente e o sistema de registro, ou o próprio token do agente executa a escrita diretamente?

Se qualquer uma dessas três respostas for “o prompt do agente diz para não fazer”, essa superfície está sem governança, não importa quão confiável o agente tenha se mostrado até aqui. Corrija a camada de mediação antes que o próximo incidente force a correção.

Fontes

Tigera. “NVIDIA OpenShell Secures the Agent. Who Governs the Fleet?.” Julho de 2026.
1Password. “1Password for Claude.” Julho de 2026.
GitHub / Microsoft. “Automating cross-repo documentation with GitHub Agentic Workflows.” Julho de 2026.

A Victorino ajuda times a desenhar a camada de mediação que deixa agentes agirem sem serem confiáveis: contato@victorino.com.br | www.victorino.com.br