Um agente de programação pode seguir as instruções de um repositório na maioria das vezes e ainda possuir mais autoridade que o necessário. A Mozilla AI destaca essa lacuna: intenção escrita e permissão imposta tecnicamente são diferentes. Um modelo mais capaz pode decidir melhor, mas não cria o limite que permanece quando decide errado.
O argumento de infraestrutura trata de agentes que inspecionam repositórios, alteram arquivos, executam comandos e testes e preparam pull requests. A delegação comprime verificações individuais num ciclo de observar, agir e revisar. Importa não só a quantidade entregue, mas o que o sistema evita, registra e recupera.
Instruções têm uma função, mas não são o limite de execução
Três responsabilidades devem ficar separadas: instruções descrevem comportamento, o modelo interpreta, a infraestrutura decide quais ações são possíveis. Dar acesso amplo primeiro e pedir moderação depois inverte a hierarquia, tornando o executor seu principal controlador.
AGENTS.md resolve coordenação mantendo comandos de build, testes, convenções e segurança junto ao código. No relato, o site informava adoção em mais de 60 mil projetos abertos. Instruções compartilhadas e versionadas transitam entre produtos; arquivos aninhados descrevem exigências de serviços em repositórios grandes.
Mesmo assim, o agente deve encontrar o arquivo, resolver sobreposições, aplicar regras e lembrá-las durante execuções longas. Conteúdo incompleto, contexto truncado, regras aninhadas conflitantes ou exceções amplas enfraquecem a cadeia. Markdown não limita por si shell, rede, conta cloud, registro de pacotes ou banco de produção.
“Não publicar pela branch de recurso”, “aprovar mudanças de autenticação” ou “ler só este diretório” comunicam intenção. Fronteiras de arquivos, rede e serviços de aprovação aplicam as restrições. Isso não diminui instruções: decisões de software precisam de contexto além de regras simples de arquivos. As camadas cumprem funções distintas.
Autonomia útil aumenta consequências de erros comuns
Consertar um teste de integração pode envolver arquivos de ambiente, serviços, dependências e snapshots. Uma tarefa vaga cresce além do objetivo. Não exige malícia: limpeza destrutiva pode parecer manutenção, credenciais parecerem descartáveis e textos de issues ou dependências serem tratados como orientação confiável.
Injeção de prompt agrava o problema ao esconder ordens hostis nos dados. Alertas ajudam, mas o mesmo modelo julga a confiança de outra linguagem. Um limite externo reduz o efeito quando esse julgamento falha.
A arquitetura de sandbox citada na fonte separa o harness confiável do ambiente dos comandos dirigidos pelo modelo. Aprovações, rastros, recuperação e estado podem ficar fora do contêiner. O executor não herda automaticamente todas as credenciais e recursos organizacionais.
Documentação não exige chaves de publicação, reparar um serviço não exige outros repositórios e criar testes não exige autoridade no banco de produção. São capacidades de execução e recursos alcançáveis, não apenas prompts. Um laptop local também pode conter código, sessões do navegador, credenciais cloud, documentos pessoais e chaves de assinatura. Uma credencial excessiva importa mesmo sem acesso administrativo.
A qualidade dos controles torna-se parte do produto. Equipes de plataforma e segurança precisam permitir delegação sem autoridade ilimitada. Fornecedores e desenvolvedores individuais enfrentam identidade, credenciais, aprovação, registros e recuperação que benchmarks não explicam.
Políticas e autorização fora da narrativa do modelo
Um plano confiável de controle administra acesso, roteamento, orçamento, políticas e estado. O modelo propõe; outra camada decide se e como executar. Identidades por execução distinguem agentes de pessoas e outras automações. Acesso a arquivos, comandos, serviços e destinos nomeados deve expirar com a tarefa, não acumular.
As orientações de sandbox da fonte descrevem isolamento, saída restrita, credenciais separadas e intermediação. Um proxy confiável fornece credenciais apenas ao destino permitido, sem mostrar ao executor um segredo reutilizável. Imprimir o ambiente não precisa revelar chaves duradouras de produção; revogação ocorre no intermediário, não em cada workspace.
A mediação valida argumentos, rejeita caminhos perigosos, limita solicitações e exige aprovação. Os plugins de políticas mcpd colocam autenticação, validação, limites e logs entre agente e servidor. Como Model Context Protocol expõe arquivos, bancos e aplicações externas, um intermediário aplica regras consistentes sem confiar que cada agente as reproduza.
A aprovação também exige identidade autorizada e estado externo que o modelo não invente. Uma mensagem no contexto pode ser imitada por material não confiável. “Economize tokens” é conselho; orçamento imposto continua sendo teto numa execução prolongada. Subagentes gastam mais depressa que uma pessoa observa um chat, tornando úteis limites por tarefa, equipe, fornecedor ou resultado.
Nem toda etapa precisa de autorização. Ler e escrever numa branch temporária pode ser rotina; publicar, implantar, alterar permissões ou contatar clientes pode exigir consentimento explícito. Um comando aceitável num teste isolado pode ser proibido em produção; documentação pode ter acesso de rede, destinos desconhecidos não. Interromper sempre o baixo risco enfraquece a delegação; nenhuma barreira entrega decisões relevantes ao modelo.
Auditoria e recuperação precisam sobreviver ao trabalho incompleto
A explicação do agente não registra automaticamente entradas, permissões, mudanças, novas tentativas e rejeições. A auditoria deve vincular cada ação à execução, versões de política e ferramenta, aprovação, identidade, entradas e resultado. Três tentativas proibidas antes do caminho permitido são diferentes de acertar imediatamente.
Após um incidente, regras e credenciais podem ter mudado. Registros antigos permitem reconstrução e revelam intervenções recorrentes, falsos positivos e tarefas fora do escopo para melhorar controles. Transcrição ou saída final não recompõem sozinhas a autoridade existente.
Estado também importa. Uma ação externa pode terminar antes de falhar o registro de sucesso. Repetir o trabalho inteiro duplica potencialmente pull requests, pagamentos ou mensagens. A infraestrutura precisa separar etapas concluídas, tentativas seguras e reconciliação. Efeito externo não equivale à leitura local repetível.
O Otari conecta governança a roteamento, orçamento, acesso, implantação e failover entre provedores. Roteamento também expressa privacidade, latência e capacidade, não só custo. Tirar decisões do código disperso ajuda a manter políticas, rastros e estado ao mudar modelo ou ambiente.
Conhecimento informa, política restringe, auditoria registra, recuperação trata o restante. O agente vira componente substituível de um sistema controlado pela organização, não o único lugar de suas regras institucionais.
Propriedade aberta traz deveres operacionais
Uma pilha inspecionável reduz dependência, permite integrações próprias e componentes sensíveis no ambiente controlado. Hospitais, bancos, órgãos públicos e equipes precisam de aprovações e retenções distintas; um padrão hospedado não atende todas. Abertura é propriedade, porém, não segurança automática.
Hospedagem própria exige atualizações, revisões, backups, monitoramento e recuperação testada. Componentes antigos, padrões permissivos, credenciais compartilhadas, logs falhos e rede irrestrita continuam vulneráveis com código público. Rastros podem expor código proprietário, dados pessoais, prompts e resultados. Retenção deve permitir responsabilização sem copiar permanentemente cada entrada sensível.
Mais regras não significa melhor proteção. Exceções sobrepostas criam brechas, rigor exagerado empurra para ferramentas não aprovadas e política central opaca cria governança problemática. Controles pequenos e testáveis precisam de responsáveis, razões e verificação. Mudanças exigem revisão, testes e versão; exceções emergenciais devem expirar, ficar visíveis e ter processos de rejeição e exceção compreensíveis.
A infraestrutura não garante código útil. O agente pode respeitar permissões e errar implementação ou omitir requisito. Testes e pessoas continuam necessários, incluindo casos privados ou independentes contra otimização apenas de verificações visíveis e revisão dos responsáveis por código sensível. Um registro detalhado prova a sequência do incidente, não prevenção bem-sucedida.
A tese será testada por permissões temporárias de tarefa, evidências duráveis de ação e autoridade e portabilidade que as preserve ao trocar modelos. A fricção cotidiana também conta. Raciocínio melhor é valioso; delegação confiável precisa de limites que não desapareçam quando ele falha.
Leitura relacionada: bases técnicas e preservação de contexto de engenharia.