> ## Content Index > Fetch the complete content index at: https://orlandoferreira.com.br/llms.txt > Use this file to discover other available public pages before exploring further. # O Risco de Dar Acesso Real ao Agente - URL: https://orlandoferreira.com.br/o-risco-de-dar-acesso-real-ao-agente/ - Published: 2026-09-08T20:26:00.000Z - Updated: 2026-09-08T20:26:00.000Z - Description: Você copia do chat pro documento, pro e-mail. Sabe que não é o método, mas o resto parece mágica. Eu dei o próximo passo, e quase quebrei tudo. - Author: Orlando Ferreira - Tags: construir-com-ia, agentes, #artigo ## O agente não avisa antes de errar. A rede de segurança é sua. Trinta e um de agosto de 2025\. Eu tinha acabado de importar o banco de dados do site 6 direto no servidor de produção, com a intenção de renomear as tabelas depois, já lá dentro. O banco corrompeu. Os três sites que eu tinha migrado naquela mesma semana sumiram da lista do WordPress. Não saíram do ar por um erro visível na tela. Sumiram do registro que diz que eles existem. **O agente não avisa antes de errar. A rede de segurança é sua.** ## O que a cena revela Isso começou por questões econômicas. Eu tinha cinco sites, de tráfego baixo, alguns quase esquecidos, mas nenhum eu podia simplesmente desligar. Cada um no próprio servidor, a vinte dólares mensais. Cem dólares por mês para sites que mal recebem visitas. Juntar os cinco num servidor só economizaria 960 dólares em um ano. Só que isso significa instalar WordPress Multisite, configurar do zero, e migrar cinco bancos de dados e cinco pastas de arquivo sem perder nada pelo caminho. Coisa que eu não sabia fazer. Já vinha usando chat de IA para esse tipo de tarefa, mas do jeito manual: pedia o comando, copiava, colava no terminal, rodava, copiava a saída, levava de volta para o chat, esperava a próxima instrução. Bem melhor do que pesquisar no Google e decifrar sozinho. Ainda chato. Ainda lento. Eu no meio de cada ida e volta. Dias antes, tinha feito um teste pequeno: será que o Cursor conseguia entrar no servidor direto, sem eu no meio, e resolver um erro sozinho? Deixei ele acessar por SSH um site que perdeu a conexão HTTPS. Ele identificou que a renovação do certificado falhou e propôs o conserto. Autorizei, e ele consertou. Foi aí que a ficha caiu: o agente podia operar meu ambiente. A ideia seguinte veio fácil demais para eu desconfiar dela. Se ele resolveu aquilo sozinho, resolve a migração inteira. ## Dois jeitos de quebrar o mesmo banco O teste pequeno tinha funcionado. O passo que dei depois foi maior do que devia: cinco sites em produção, de uma vez, sem escalonar o risco antes. Levou três dias para dar errado de dois jeitos diferentes. No site 2, pedi para trocar o prefixo das tabelas de `wp_` para `wp_2_`, para não colidir com o site principal. O comando rodou uma substituição de texto sobre o arquivo inteiro do banco. Trocou o nome das tabelas, como eu queria. Também trocou uma palavra que aparecia dentro do conteúdo de uma tabela de configuração, `inactive_widgets` virou `2_inactive_widgets`, e o site perdeu os widgets sem nenhum aviso. No site 6, o erro foi outro. Importei o banco inteiro primeiro, do jeito que veio do site antigo, com a intenção de renomear as tabelas depois de já estarem dentro do banco de produção. Rodou o comando de renomear. E foi exatamente essa ordem, importar primeiro e renomear depois, que corrompeu o banco de produção. Erros diferentes. Mesma raiz: mexer em algo que já existia sem entender a estrutura por dentro primeiro. ## O comando que eu não devia rodar Não foi o agente que decidiu importar sem preparar o arquivo antes. Fui eu. O Cursor tinha acesso para executar o que eu mandava, e eu mandei importar direto. Ele fez o que pedi. Um banco de WordPress Multisite guarda cada site nas próprias tabelas, `wp_2_posts`, `wp_2_options`, e assim por diante. Quando você importa um banco de site único direto, as tabelas chegam com o nome antigo, `wp_posts`, `wp_options`, e tentam ocupar o lugar das tabelas do site principal, que já existiam ali com o mesmo nome. Renomear depois de importar não separa nada. O WordPress já leu a estrutura, já criou referência entre tabela e conteúdo, e trocar o nome àquela altura quebra a referência sem avisar que quebrou. ## O backup não evitou o erro Tinha feito backup do banco de produção antes de começar, porque a lição do site 2 já tinha ensinado: sem backup, aborta. Restaurei o banco a partir do backup. Registrei de volta, na tabela que guarda a lista de sites, os três que tinham sumido. Corrigi o arquivo do site 6, dessa vez renomeando as tabelas dentro do próprio arquivo `.sql`, antes de importar, não depois, e rodei de novo. Na mesma tarde, o site 6 entrou no ar. Cento e sessenta e seis megabytes, dois mil setecentos e sessenta e um arquivos de imagem, setenta e oito tabelas novas, sem mais erro nenhum. O backup não evitou o erro. Não me impediu de rodar o comando errado. O que ele fez foi outra coisa: transformou um banco corrompido em perda de algumas horas, em vez de perda permanente. E pagou o preço dele ali mesmo, no meio da migração, não como seguro guardado numa gaveta que ninguém nunca abre. ## A regra nasceu do acidente Depois dos cinco sites migrados, sobrou um arquivo. Um roteiro de quase trezentas linhas que qualquer migração nova segue, com uma lista do que nunca mais posso fazer. Nunca importar tabelas primeiro e tentar renomear depois. Nunca fazer substituição de texto global no arquivo do banco, só nos nomes de tabela, nunca no conteúdo. Sempre fazer backup do banco de produção antes de qualquer migração. Sem backup, abortar. Não é checklist genérico copiado de algum lugar. Cada linha nomeia o incidente específico que a criou. A regra do banco importado antes da hora existe porque o site 6 corrompeu daquele jeito. A regra da substituição seletiva existe porque o site 2 corrompeu do outro. ## O que você deixaria o agente tocar No fim, os cinco sites ficaram no ar, no mesmo servidor, a vinte dólares por mês, contra cem que eu pagava antes. Funcionou. Se fosse fazer de novo, começaria diferente. Testaria o risco pequeno outra vez antes de ir direto para cinco sites em produção ao mesmo tempo. O teste que fiz antes, deixar o agente resolver um erro sozinho, num site só, já tinha me mostrado que o acesso funcionava. Não precisava confirmar isso migrando cinco de uma vez. Você não vai mexer em banco de dados de produção. Mas algum dia vai decidir dar a um agente acesso de verdade a alguma coisa que importa no seu trabalho: uma planilha que sustenta decisão, um contrato, a própria caixa de entrada. Antes de autorizar, vale uma pergunta só. **O agente não avisa antes de errar. A rede de segurança é sua.** O que você deixaria um agente tocar hoje, sem ter pensado nessa pergunta antes? Escrevo sobre isso toda semana. [Assine a newsletter Construir com IA](#/portal/signup/free) e receba a próxima direto no e-mail.