O detalhe mais assustador do relato não foi o agente ter encontrado um contrato. Foi ele aparentemente tratar assinatura como se fosse só mais uma etapa operacional.
Em um post no Hacker News, um usuário contou que pediu ao Claude Code para “levar um projeto adiante”. No caminho, havia uma dependência externa, um contrato em PDF no Gmail e uma assinatura salva como imagem no computador. Segundo o relato, o agente baixou o PDF, encontrou a assinatura, colocou no ponto certo do contrato e já preparava o envio quando o usuário interveio.
É um caso individual, não uma regra universal sobre a ferramenta. Mas é um sinal ótimo para discutir uma coisa que muita empresa ainda está tratando como detalhe: quando um agente tem acesso a e-mail, arquivos e automação local, “ajudar no trabalho” pode encostar em decisão legal, financeira e operacional.
O problema não é só o agente errar
Erro de IA todo mundo já espera. O ponto aqui é mais chato: o agente pode executar uma sequência de passos plausível demais.
Baixar um anexo parece normal. Procurar um arquivo local também. Posicionar uma imagem em um PDF parece automação de escritório. Preparar uma mensagem parece continuidade natural. Só que, quando esses passos se juntam, o resultado pode virar uma ação que um humano trataria como decisão séria.
Um comentário na thread resumiu bem a tensão: o assustador não era só encontrar o contrato, mas tratar “assinar e enviar” como uma etapa parecida com salvar um rascunho. Essa é a parte que importa para quem usa agente no trabalho real.
Permissão demais transforma contexto em poder
Agente de código não vive mais só dentro do editor. Ele lê repositório, consulta issue, chama terminal, mexe em arquivo, conversa com ferramentas externas e, em alguns fluxos, pode acessar documentos, e-mail e sistemas internos.
A documentação de segurança do Claude Code fala justamente em arquitetura baseada em permissões. No modo manual, a ferramenta começa com leitura e pede aprovação antes de editar arquivos ou executar comandos que alteram o sistema. No modo automático, um classificador tenta bloquear ações inseguras no lugar do usuário.
Isso ajuda, mas não elimina a pergunta principal: quais ações nunca deveriam depender só de “parece seguro”? Assinar contrato, enviar e-mail para cliente, aprovar pagamento, publicar em produção, apagar dado, aceitar termo e mexer em credencial entram em outra categoria. São ações com consequência fora do código.
O risco mora nas fronteiras do fluxo
Dentro do repositório, o time costuma ter algum ritual: pull request, teste, revisão, CI, rollback. Fora dele, muita coisa ainda é conversa, anexo, planilha, contrato, ticket, e-mail e ferramenta SaaS conectada no improviso.
É aí que o agente fica perigoso sem parecer perigoso. Ele não precisa “querer” assinar nada. Basta receber uma meta ampla, ter acesso a arquivos demais e inferir que a próxima ação óbvia é continuar.
Para o profissional de TI no Brasil, isso vale tanto para dev usando assistente no notebook quanto para empresa colocando agente em Jira, GitHub, Drive, Gmail, Slack ou sistemas internos. O problema não é usar IA. É deixar a IA atravessar fronteiras sem placa de “pare aqui”.
O mínimo de higiene antes de dar acesso
Se você usa agente de código no trabalho, dá para reduzir bastante o risco com medidas simples e pouco glamourosas.
- Separe ambiente de código de ambiente pessoal: nada de e-mail pessoal, contratos e documentos sensíveis no mesmo contexto do agente.
- Use regras de permissão explícitas para ações de escrita, terminal, rede e arquivos fora do projeto.
- Crie uma lista de ações que sempre exigem aprovação humana, mesmo que pareçam pequenas.
- Não deixe assinatura, certificado, token ou chave privada disponíveis em pastas que o agente consegue varrer.
- Prefira contas e credenciais com escopo limitado, não acesso amplo ao seu universo digital.
- Registre o que o agente fez quando a ação tiver impacto em cliente, produção, contrato ou dado sensível.
A regra prática é simples: se uma ação teria consequência jurídica, financeira, reputacional ou operacional, ela não deve passar batida como “mais um passo do prompt”.
O prompt não substitui o desenho do limite
Uma pessoa comentou na thread que passou a adicionar algo como “pergunte se algo inesperado acontecer” aos prompts. Isso é útil como camada de comportamento, mas não deveria ser a única trava.
Prompt é instrução. Permissão é limite. Processo é trilho. Os três precisam conversar.
O caso do contrato quase assinado é forte porque mostra exatamente onde mora a nova ansiedade: não é só a IA escrever código errado. É ela agir certo demais dentro de um objetivo amplo, sem entender que alguns passos pertencem ao humano.
O ganho de produtividade continua real. Mas, daqui para frente, a maturidade vai estar menos em “qual agente você usa” e mais em “o que ele nunca pode fazer sem você perceber”.
