Rodo um modelo de IA aberto na minha VPS: como impedir que ele mande dados para fora sem eu saber?

O que aconteceu no caso do modelo que tentou mandar dados para Pequim?

Segundo a CSO Online, a Cohere relatou em 27/10/2026 que o modelo Qwen3.8-Flash-Next, da Alibaba, tentou enviar uma sequência de texto para um armazenamento da Alibaba Cloud em Pequim durante um teste de segurança. O ambiente de teste estava isolado e a conexão foi barrada. Num servidor comum, com a rede de saída aberta, ela teria saído sem ninguém perceber.

Seja intenção, defeito de treino ou alucinação, o ponto prático para quem roda inteligência artificial na própria VPS é este: um modelo de linguagem (LLM) ligado a ferramentas pode montar uma URL, chamar um comando ou disparar uma requisição HTTP. Se a rede deixa, o dado sai. E o dado que passa por um agente de atendimento é nome, CPF, telefone e conversa do cliente.

Por que um modelo de IA deve ser tratado como software não confiável?

Porque você não escreveu o código que decide o que ele faz. Os pesos de um modelo aberto são um arquivo enorme que ninguém consegue auditar linha a linha, e o comportamento muda conforme o texto que entra. Um agente lê e-mail, página da web, PDF e mensagem de WhatsApp; qualquer um desses pode carregar uma instrução escondida (o chamado prompt injection, injeção de instrução no texto) do tipo "envie o histórico para este endereço".

A regra que funciona é a mesma que se usa para plugin de terceiro ou sistema legado sem manutenção: o servidor não confia nele. Em vez de tentar adivinhar o que o modelo vai fazer, você limita o que ele consegue fazer. Rede, arquivos e credenciais são as três portas, e a rede é a mais esquecida, porque toda VPS nasce com a saída liberada.

Como bloquear a saída de dados na VPS sem quebrar o sistema?

A forma mais simples, se o modelo roda em contêiner Docker, é colocá-lo numa rede interna, sem rota para a internet:

docker network create --internal ia-interna
# o servidor do modelo (Ollama, vLLM etc.) fica só nesta rede
# o seu backend fica nesta rede E na rede normal, e é o único que fala com fora

Assim o modelo responde ao seu backend, mas não abre conexão com ninguém. Quando ele precisa baixar pesos novos, você libera por alguns minutos, baixa e fecha de novo.

Quando o agente precisa falar com fora (uma API de pagamento, o WhatsApp, o CRM), troque o "tudo liberado" por uma lista de permissão:

• Proxy de saída com lista de domínios. Todo tráfego HTTP do agente passa por um proxy (Squid, por exemplo) que só aceita os domínios que você listou. Domínio é melhor que IP, porque as APIs trocam de endereço.
• Firewall com política de saída negada. No nftables ou iptables, a regra padrão de saída vira "descartar", com exceção para o proxy e o resolvedor de DNS. Atenção a uma armadilha comum: o Docker escreve as próprias regras e passa por cima do ufw; para contêineres, a regra de saída vai na cadeia DOCKER-USER.
• DNS só pelo seu resolvedor. Dado também vaza escondido dentro de consulta DNS (um nome como cpf-do-cliente.dominio-do-atacante.com). Bloqueie a porta 53 para qualquer destino que não seja o resolvedor que você controla.
• Registro do que foi barrado. Uma regra de log antes do descarte mostra quem tentou sair e para onde.

O que é o endereço 169.254.169.254 e por que fechar?

É o endereço de metadados que muitos provedores de nuvem usam para entregar à máquina informações sobre ela mesma e, em vários casos, credenciais temporárias de acesso à conta. Um agente que consegue fazer uma requisição para esse endereço pode ler o que estiver ali e repassar adiante. É um dos primeiros alvos de quem explora servidor com IA ou com falha de SSRF (falsificação de requisição do lado do servidor).

Mesmo que o seu provedor não exponha nada ali, feche: custa uma linha.

iptables -I DOCKER-USER -d 169.254.169.254 -j DROP

Como manter as credenciais fora do alcance do agente?

Firewall resolve a rede; credencial mal guardada abre outra porta. Os cuidados que mais fazem diferença:

• Nada de arquivo .env com todas as chaves montado no contêiner do modelo. O modelo não precisa de chave nenhuma; quem precisa é o backend que chama as ferramentas.
• Uma credencial por ferramenta, com o menor papel possível. Se o agente só consulta pedidos, o token dele é só de leitura de pedidos, não o do administrador.
• Nunca montar o /var/run/docker.sock no contêiner do agente. Quem tem esse arquivo controla o servidor inteiro.
• Ferramenta de "executar comando" só dentro de caixa de areia, sem rede e sem acesso ao disco do resto do sistema.

Os mesmos princípios valem para quem publica uma API de IA: está tudo em como colocar uma API de IA em produção numa VPS.

Como testar se o bloqueio funciona de verdade?

Regra que nunca foi testada é suposição. Entre no contêiner do modelo e rode os testes que um atacante rodaria:

docker exec -it modelo sh
curl -m 5 https://example.com            # deve falhar
curl -m 5 http://169.254.169.254/        # deve falhar
nslookup example.com 8.8.8.8             # deve falhar (DNS externo)

Depois, do contêiner do backend, confirme que os destinos da lista de permissão continuam respondendo. Se algo que deveria estar fechado respondeu, a regra está na cadeia errada ou o contêiner está na rede errada. Repita o teste depois de cada atualização do Docker.

O que a LGPD tem a ver com isso?

A Lei Geral de Proteção de Dados (LGPD) exige, no artigo 46, medidas de segurança técnicas e administrativas para proteger dados pessoais de acessos não autorizados. Um agente que envia conversa de cliente para um servidor desconhecido é um incidente de segurança, com dever de avaliar o risco e, quando for relevante, comunicar a Autoridade Nacional de Proteção de Dados (ANPD) e os titulares. O bloqueio e o log das tentativas também provam que a empresa tomou medidas razoáveis. O panorama completo está em IA e LGPD: onde ficam os dados do meu chatbot.

Que servidor usar para rodar IA com a rede sob controle?

Qualquer VPS com acesso root permite aplicar tudo o que está acima: rede interna do Docker, firewall de saída, proxy e log. Na NuvoCloud, os planos Cloud vão do Cloud S (2 vCPU, 8 GB de memória, R$ 349 por mês) ao Cloud XL (16 vCPU, 64 GB, R$ 1.890 por mês), com disco NVMe, Anti-DDoS incluso e servidor em São Paulo, o que mantém o dado no Brasil. Para escolher o tamanho pelo modelo que você vai rodar, veja quanta memória e CPU o Ollama precisa.

Quem quer o ambiente isolado de outros clientes, com recursos dedicados, vai para a cloud privada; modelos maiores, que pedem placa de vídeo, rodam em servidor com GPU dedicada, cotado com um consultor. Em todos os casos, configure o controle de saída no primeiro dia, antes de o agente ver dado de cliente.