Um agente de IA fica muito mais útil quando pode mexer no servidor de verdade:
instalar pacote, configurar serviço, emitir certificado, olhar log. E fica
muito mais perigoso também.
A pergunta não é se você deve dar esse acesso. É como dar de um jeito que você
consiga ver, conferir e tirar a qualquer momento. Mostrei isso num vídeo em
que deixei meu agente configurar o próprio servidor e emitir o certificado SSL.
Este artigo explica o raciocínio por trás, que vale para qualquer agente e
qualquer servidor.
O problema: o agente está dentro de uma caixa
No meu caso o agente roda no OpenClaw, numa VPS. O OpenClaw fica dentro de um
container Docker, isolado. Por padrão, ele não enxerga o servidor onde está
rodando.
Isso é bom. É justamente o isolamento que protege o servidor de um agente que
erra. Mas também significa que, se você quer que ele administre a máquina,
precisa abrir uma porta. E a forma como você abre essa porta decide se você
continua no controle.
Chave, não senha
A porta certa é SSH com um par de chaves criptográficas, e não com senha.
Funciona assim:
- O agente gera um par de chaves: uma privada e uma pública.
- Ele guarda a privada. É com ela que se identifica.
- Você coloca a pública no servidor. É isso que autoriza a entrada.
Senha pode vazar, pode ser descoberta por tentativa, pode ser reaproveitada
de outro lugar. Uma chave ed25519 não se adivinha. E o mais importante para
agente de IA: ela é revogável na hora, sem trocar senha de ninguém.
Os três testes de qualquer acesso que você dá a uma IA
Toda vez que você der autonomia a um agente sobre algo real, um servidor, uma
API, uma caixa de e-mail, faça três perguntas. Se alguma resposta for não,
pare e redesenhe.
É gerenciável? Você consegue ver exatamente quem tem acesso? Com chave
SSH, sim: está tudo listado num arquivo só, o authorized_keys.
É auditável? Você consegue saber quando e como o acesso foi usado? Com
SSH, sim: cada conexão fica registrada nos logs do servidor.
É revogável? Você consegue tirar o acesso agora, em segundos? Com chave,
sim: apaga uma linha do authorized_keys e acabou.
Esses três testes são o princípio que eu uso em tudo no projeto do agente
que escreve as notícias deste site. Guarde eles. Valem para muito além de
servidor.
O caminho, resumido
Primeiro, o domínio. No painel de DNS do seu domínio, crie um registro do
tipo A apontando para o IP da VPS. Pode ser o domínio raiz ou um subdomínio.
A propagação leva de minutos a poucas horas.
Depois, a chave. Peça ao agente para gerar o par de chaves e mostrar a
pública. Peça também que ele espere sua confirmação antes de tentar conectar.
Esse "espere" importa: é você quem autoriza, não ele.
Depois, a autorização. No terminal do servidor, acrescente a chave pública
ao authorized_keys e ajuste as permissões da pasta. Um cuidado prático: no
terminal que abre pelo navegador, o colar costuma trazer sujeira junto. Se a
conexão der permissão negada, quase sempre é isso.
Por fim, o trabalho. Com o acesso funcionando, um único pedido basta para
o agente instalar o servidor web, abrir as portas 80 e 443 no firewall,
emitir o certificado SSL automático e apontar o domínio.
Um detalhe que me custou tempo: o OpenClaw da Hostinger já vem com o Traefik
fazendo o papel de proxy. Se o agente tentar instalar outro servidor web por
cima, os dois brigam pela porta 443. A saída é pedir que ele configure o
Traefik que já existe, usando os arquivos de configuração dinâmica em vez de
mexer nos containers.
Se quiser ir um passo além
O jeito mais simples, que é o do vídeo, dá ao agente acesso como root. É o
que funciona sem atrito, e com os três testes acima você continua no
controle.
Mas se o agente só precisa de algumas tarefas, o mais seguro é criar um
usuário dedicado para ele, com permissão só para o que ele precisa fazer.
Assim, um erro do agente tem um estrago limitado, em vez do servidor inteiro.
Menos cômodo, mais seguro, e vale a pena quando o agente passa a rodar
sozinho de madrugada.
Continue daqui
O vídeo completo, com o agente fazendo tudo ao vivo, está no canal:
Deixei meu agente de IA configurar o próprio servidor e emitir o
certificado SSL.
O guia com todos os prompts e comandos prontos para copiar está na
Biblioteca, dentro do Loop.
E se o seu agente travar em algum passo, abre um loop com a mensagem de erro
completa. Erro de SSH e de certificado costuma ter a mesma meia dúzia de
causas, e eu já bati em quase todas.
Continue no loop
