Dar mais autonomia a um agente envolve muito mais do que remover caixas de confirmação. A equipe precisa decidir o que acontece quando a pessoa não percebe um desvio, o modelo interpreta uma instrução de forma inesperada ou um arquivo externo injeta uma ação que ninguém pretendia autorizar.
A Anthropic resume o problema como blast radius: a dimensão do dano que uma falha pode causar. A probabilidade de um erro importa, mas não é a única variável. Um agente mais capaz pode errar menos e, ao mesmo tempo, encontrar caminhos mais eficientes para alcançar um objetivo dentro de um ambiente amplo demais.
Essa distinção muda a ordem da decisão. Antes de perguntar se o agente pode trabalhar sem supervisão a cada passo, a equipe precisa definir quais recursos ele consegue alcançar, quais credenciais entram no ambiente e por onde dados podem sair.
Aprovar cada ação não escala como controle
A supervisão humana parece uma barreira simples: o agente pede permissão e uma pessoa decide. Na prática, o volume de pedidos transforma a barreira em rotina. A Anthropic relata que usuários do Claude Code aprovaram cerca de 93% dos prompts de permissão observados. Quando quase tudo é aprovado, cada prompt perde parte do valor como sinal de risco.
Isso não torna a revisão humana inútil. Ela continua importante para decisões de escopo, mudanças de produto e ações de alto impacto. O problema é usar o mesmo mecanismo para cada comando, como se atenção humana fosse um recurso infinito e homogêneo.
Um controle mais durável limita a capacidade do agente mesmo quando a supervisão falha. Se um segredo nunca entra no ambiente, um caminho que tente copiá-lo não encontra o objeto. Se a rede só permite destinos e operações específicas, uma instrução maliciosa não recebe automaticamente o mesmo alcance da aplicação inteira.
O ambiente é uma fronteira de segurança
Containment não significa confiar que o modelo sempre escolherá a ação correta. Significa colocar uma fronteira determinística ao redor do que ele pode fazer. Sandboxes, máquinas virtuais, limites de sistema de arquivos e controles de egress cumprem esse papel.
A força da fronteira depende do trabalho que o produto precisa realizar. Um container efêmero para executar código pode oferecer pouco acesso persistente e, por isso, um raio de dano menor. Um agente de desenvolvimento precisa ler e alterar um workspace, executar comandos e talvez acessar serviços. Um sistema voltado a trabalho geral pode precisar de arquivos locais sem pressupor que a pessoa usuária saiba avaliar uma linha de shell.
Não existe uma configuração universal de autonomia. O desenho precisa combinar capacidade do agente, competência de quem supervisiona e sensibilidade dos recursos disponíveis.
Três superfícies precisam de defesa
A fonte da Anthropic separa três componentes que costumam ser tratados como um único problema:
- o ambiente em que o agente executa;
- o modelo que escolhe as ações;
- o conteúdo externo que entra no contexto.
Prompts de sistema, classificadores e treinamento influenciam o comportamento provável do modelo. Eles não transformam uma capacidade probabilística em uma garantia. Um agente pode seguir uma instrução inesperada, descobrir uma rota não prevista ou interpretar uma restrição de maneira estreita demais.
O conteúdo externo amplia o problema. Um servidor MCP, plugin ou repositório pode fornecer dados úteis e também instruções injetadas. Auditar o conector não é o mesmo que auditar cada arquivo que ele carrega. Por isso, limitar permissões da ferramenta e inspecionar retornos devem fazer parte da fronteira, não ficar apenas na documentação de uso.
A lista de destinos não é suficiente
Um detalhe importante aparece quando a rede permite acesso a um domínio confiável. Autorizar api.exemplo.com pode parecer diferente de autorizar upload de arquivos, mas toda função acessível naquele domínio passa a fazer parte da superfície de ataque.
O caso descrito pela Anthropic mostra por que destino e capacidade não são sinônimos. Uma chave inserida em um arquivo malicioso pode usar uma API permitida para enviar dados a uma conta controlada pelo atacante. O domínio era legítimo; a operação e a identidade não eram.
O controle precisa verificar mais do que para onde a conexão vai. Deve considerar qual credencial está sendo usada, que operação está sendo chamada, qual dado pode atravessar a fronteira e se a sessão tem autorização para aquela ação. Uma allowlist ampla reduz a fricção, mas também pode conceder capacidades que a equipe não pretendia delegar.
Persistência aumenta a responsabilidade
Um ambiente efêmero começa de novo a cada sessão. Um workspace persistente, um arquivo de instruções ou a memória de um agente carregam estado para o próximo trabalho. Se uma instrução maliciosa entra nesse estado, ela deixa de ser um evento isolado e passa a ser contexto recorrente.
Isso exige tratar arquivos de configuração, diretórios de estado e memórias como superfícies de entrada. O fato de um conteúdo estar no próprio repositório não prova que ele é confiável. Projetos clonados, dependências atualizadas e conectores remotos precisam atravessar o mesmo raciocínio de origem, permissão e persistência.
A decisão para a equipe
Antes de aumentar a autonomia, a equipe pode responder a cinco perguntas: qual é o workspace autorizado, quais credenciais ficam fora dele, quais ações exigem identidade própria, quais destinos são necessários e como a sessão é encerrada ou revogada.
As respostas não precisam produzir um sistema perfeito. Precisam estabelecer um limite que continue valendo quando um prompt for ambíguo, uma aprovação for automática ou o agente encontrar conteúdo hostil. A autonomia útil começa quando o pior resultado plausível já tem um tamanho deliberadamente limitado.
