Servidor gerido por IA: ligar agentes de IA como o Claude Code e o ChatGPT ao seu próprio servidor em segurança

Até há pouco tempo, «administrar um servidor» significava abrir o SSH, ler registos, escrever comandos, procurar na documentação e voltar a escrever. Desde que o Claude Code, o OpenAI Codex e o Gemini CLI passaram a estar disponíveis como ferramentas de linha de comandos, um agente de IA pode assumir exatamente este trabalho: lê a mensagem de erro, procura a causa, altera a configuração, reinicia o serviço e explica o que fez. A isto chama-se agora servidor gerido por IA (AI Managed Server). Este artigo explica o que está por trás, que arquiteturas provaram o seu valor, que regras de segurança são inegociáveis e porque qualquer servidor root da KernelHost está pronto para isso sem qualquer adaptação.

O que é um servidor gerido por IA (e o que não é)

Um servidor gerido por IA não é um produto novo nem hardware especial. É um servidor root comum no qual um agente de IA pode executar comandos com a sua própria conta de utilizador. A pessoa descreve a tarefa em linguagem corrente («Porque é que o nginx responde com 502 desde esta manhã?») e o agente examina o sistema, propõe alterações, executa-as após aprovação e documenta o resultado.

A diferença em relação a um chatbot cujos comandos se copiam à mão: o agente tem uma shell. Pode invocar o journalctl sozinho, ler ficheiros de configuração, experimentar um comando, interpretar a saída e deduzir daí o passo seguinte. Meia hora de idas e voltas com copiar e colar transforma-se em dois minutos.

O que um servidor gerido por IA não é: um servidor que se administra a si próprio. Os agentes trabalham a pedido, num contexto de sessão, com aprovações. Quem lhes dá carta branca não obtém um administrador autónomo, mas sim uma ferramenta muito rápida sem travão. As regras mais abaixo garantem que o travão se mantém.

Servidor gerido por IA comparado com o servidor gerido clássico

No servidor gerido clássico, é o fornecedor de alojamento ou um prestador de serviços que assume a manutenção, mediante um valor fixo mensal. No servidor gerido por IA, mantém o controlo e deixa que um agente lhe poupe o trabalho manual.

As ferramentas: Claude Code, ChatGPT Codex, Gemini CLI e MCP

Os três grandes fornecedores têm agora uma ferramenta de linha de comandos que corre em servidores Linux, lê e escreve ficheiros e executa comandos de shell. Diferem em pormenores, mas o princípio básico é idêntico.

As três correm com Node.js, não precisam de GPU e enviam o verdadeiro trabalho de raciocínio para o modelo do fornecedor. No servidor fica apenas a ferramenta em si, com poucos megabytes. Por isso, basta até o mais pequeno servidor root KVM.

O que o MCP acrescenta

A isto junta-se o Model Context Protocol (MCP): uma interface aberta através da qual um agente obtém ferramentas adicionais, por exemplo acesso a uma base de dados, a um sistema de monitorização, a um sistema de tickets ou a um ambiente Docker, sem ter de usar a shell para isso. Para começar, o MCP não é necessário. Torna-se interessante assim que quiser restringir acessos de forma seletiva: um servidor MCP que só permite consultas de leitura à base de dados é mais seguro do que um agente com a palavra-passe da base de dados na shell.

Que ferramenta é a indicada para si?

Para a administração de servidores, as três ferramentas equivalem-se: todas leem ficheiros de regras, perguntam antes de executar comandos intrusivos e podem ser iniciadas sem supervisão. Por isso, a decisão depende normalmente da conta que já tem. Quem usa o ChatGPT começa com o Codex CLI, quem tem uma subscrição do Claude começa com o Claude Code e quem trabalha no ecossistema da Google começa com o Gemini CLI. Usar várias ferramentas lado a lado não levanta qualquer problema, porque cada uma lê o seu próprio ficheiro de regras.

Três formas de ligar o agente ao servidor

1. O agente corre no seu computador e trabalha por SSH

O Claude Code ou o Codex correm no portátil e cada comando para o servidor é enviado por ssh. Vantagem: não é preciso instalar nada no servidor, o agente pode tratar de vários servidores ao mesmo tempo e o início de sessão no fornecedor de IA fica no seu dispositivo. Desvantagem: o agente só vê o servidor pelo buraco da fechadura de comandos isolados, e as sessões longas dependem da sua ligação. Para manutenção ocasional e vários servidores pequenos, é a variante mais simples. O relato prático Ligar a IA ao servidor mostra como nós próprios trabalhamos desta forma, com uma chave própria, um alias de host e um processo fixo para os deploys.

2. O agente corre diretamente no servidor

A ferramenta é instalada no servidor e iniciada por SSH. O agente trabalha então com acesso direto aos ficheiros, pode acompanhar os registos em tempo real e concluir tarefas mais longas sem depender da sua ligação, por exemplo no âmbito de um cron job que resume os registos todas as manhãs. Na prática, é esta a variante que se tem em mente na maioria dos casos quando se fala de um servidor gerido por IA. O passo a passo está descrito no guia de instalação do Claude Code e do Codex no servidor.

3. O agente corre numa VM bastião

Para vários sistemas de produção, compensa ter um pequeno servidor separado onde os agentes vivem e a partir do qual acedem por SSH aos sistemas de destino. Os sistemas de destino recebem apenas uma chave SSH com direitos restritos; o servidor bastião guarda os inícios de sessão nos fornecedores de IA, os registos de sessão e as regras. Quem conhece o princípio da operação de centros de dados reconhece-o: um servidor de salto, só que com um agente em vez de uma pessoa ao comando. Para isso, basta um servidor root KVM com 2 vCPU.

Comparação das três formas

Regras de segurança inegociáveis

Um agente com acesso à shell é tão perigoso como um colega novo com a palavra-passe de root e sem formação. Estas regras vêm da operação de servidores que são atacados todos os dias e aplicam-se independentemente do fornecedor:

• Utilizador dedicado, nunca root. O agente recebe a sua própria conta. Os comandos de root passam por uma lista branca sudo que contém exatamente os comandos de que ele precisa: atualizações de pacotes, reinícios de serviços, acesso aos registos. Tudo o resto fica bloqueado.
• Manter o modo de aprovação ligado. As três ferramentas perguntam antes de ações intrusivas. Opções como --dangerously-skip-permissions ou danger-full-access pertencem a uma VM descartável, nunca a um sistema de produção.
• Cópia de segurança ou snapshot antes de cada sessão. Um agente que «repara» uma configuração também a pode destruir. Com um snapshot ou uma cópia de segurança testada, isso é um aborrecimento; sem eles, é uma emergência.
• Nenhum segredo no prompt. Palavras-passe, chaves API e dados de clientes não se escrevem na tarefa. O que o agente lê nos ficheiros vai para o fornecedor; por isso, os ficheiros com segredos ficam fora do seu alcance ou são mascarados antes.
• Primeiro staging, depois produção. Os novos padrões de tarefa são experimentados numa VM de teste. Só quando o processo tiver corrido bem várias vezes pode passar para o sistema de produção.
• Manter as alterações rastreáveis. /etc em Git (etckeeper), guardar os registos de sessão, pedir ao agente que resuma cada alteração. O que não é rastreável também não se pode reverter.
• Definir limites de custo. As chaves API recebem um orçamento mensal no fornecedor. Caso contrário, um agente num ciclo infinito fica mais caro do que qualquer servidor.
• Manter a rede no mínimo. O agente só precisa de HTTPS de saída para o fornecedor. À entrada nada muda: o servidor continua atrás da firewall e da proteção DDoS.

Porque é que um utilizador dedicado é tão importante

Os modelos de linguagem cometem erros, e cometem-nos com grande convicção. Um agente que confunda um caminho apaga o diretório errado se tiver direitos de root; com um utilizador dedicado, o mesmo comando falha por falta de permissões. Por isso, a verdadeira barreira de segurança é a lista branca sudo, e não a prudência do modelo. Há ainda uma vantagem prática: nos registos, percebe-se a qualquer momento que ações vieram do agente e quais vieram de uma pessoa. O artigo Criar um utilizador sudo em Linux mostra como se cria um utilizador deste tipo.

O que o fornecedor de IA chega a ver

Tudo o que o agente lê é enviado para processamento ao modelo de linguagem do fornecedor: linhas de registo, ficheiros de configuração, saídas de comandos. A ferramenta no servidor é apenas o mensageiro. Daqui decorrem duas regras. Primeiro, os ficheiros com credenciais não devem estar à vista do agente; os scripts podem usá-los na mesma, sem que ele os mostre. Segundo, os dados pessoais de clientes não devem ir parar às tarefas. Quem precisar de análises sobre dados de clientes pede ao agente que escreva uma consulta que devolva apenas números ou resultados anonimizados e executa-a por si próprio.

O que um agente faz bem e quando é melhor escrever os comandos por si próprio

A experiência mostra que os agentes brilham em tarefas que envolvem muita leitura e pouco risco: resumir os registos das últimas 24 horas, encontrar a causa de uma mensagem de erro, verificar se uma configuração do nginx tem erros, escrever um ficheiro de unidade do systemd, ajustar ficheiros do Docker Compose, criar um script de cópia de segurança com rotação de registos, explicar uma regra de firewall. A manutenção de rotina com um processo claro também funciona bem, por exemplo instalar atualizações, verificar depois os serviços e escrever um relatório.

Boas tarefas para começar

• «Resume os erros e avisos das últimas 24 horas, agrupados por serviço.»
• «Que serviços falharam e o que diz, em cada caso, a última mensagem de erro?»
• «Que pacotes têm atualizações de segurança pendentes?»
• «Verifica a configuração do nginx e explica cada aviso do nginx -t.»
• «Que diretórios ocupam mais espaço e o que se pode apagar deles sem risco?»

Tarefas que ficam nas mãos de uma pessoa

Menos adequadas são as tarefas com consequências irreversíveis e especificações pouco claras: migrar bases de dados, alterar partições, eliminar utilizadores, limpar dados de produção. Aqui, o agente é um bom conselheiro que escreve o plano, mas quem executa é a pessoa. E mais: um agente que não entende uma saída adivinha. Quem não consegue avaliar a saída por si próprio não a deve aprovar.

Processos típicos no dia a dia

O relatório diário de registos

O clássico entre as tarefas sem supervisão: um cron job inicia o agente todas as manhãs com uma instrução fixa, por exemplo «Resume os erros e avisos das últimas 24 horas», e envia o resultado por e-mail. O agente só pode ler, e as ferramentas estão limitadas ao journalctl. O aspeto exato do cron job está descrito no guia de instalação.

Atualizações com relatório

Nas atualizações de segurança, o agente verifica primeiro que pacotes são afetados e que serviços têm de ser reiniciados a seguir. Após a sua aprovação, instala as atualizações, reinicia os serviços, verifica o estado deles e escreve um breve relatório. Quem quiser automatizar as atualizações de forma sistemática combina isto com o unattended-upgrades e deixa ao agente apenas a verificação.

Diagnóstico em caso de falha

Em caso de falha, descreve o sintoma, por exemplo «O site responde com 502». O agente lê os registos do servidor web e da aplicação, verifica se o serviço de backend está a correr, formula uma hipótese e fundamenta-a com linhas de registo. A solução é proposta pelo agente, mas só é aplicada depois de a aprovar. As causas típicas e a forma de as resolver estão descritas no artigo Resolver o nginx 502 Bad Gateway.

Totalmente compatível com os servidores da KernelHost

Qualquer servidor da KernelHost cumpre de origem todos os requisitos das ferramentas de IA, sem configuração especial:

• Acesso root completo em servidores root KVM e servidores dedicados, para que possa configurar por si próprio os utilizadores, as regras sudo e o Node.js.
• Livre escolha do sistema operativo: Debian, Ubuntu, AlmaLinux, Rocky Linux e outras distribuições nas quais o Claude Code, o Codex CLI e o Gemini CLI correm oficialmente. Em servidores Windows, as ferramentas funcionam de forma nativa ou através do WSL.
• Ligações de saída livres: os agentes comunicam por HTTPS com api.anthropic.com, api.openai.com e as API da Google. A proteção DDoS filtra exclusivamente o tráfego de ataque de entrada e não trava os agentes.
• Tráfego ilimitado: os pedidos à API são pequenos, mas um agente que analisa registos gera, ainda assim, tráfego ao longo do mês. Na KernelHost, isso não tem qualquer importância.
• Node.js a partir dos repositórios ou do NodeSource, instalável como descrito no guia do Node.js no Debian.
• Localização em Frankfurt: caminhos curtos até aos endpoints europeus das API dos fornecedores e dados guardados num centro de dados na Alemanha.

Em suma: não há nada que tenha de encomendar ou ativar à parte na KernelHost. Um servidor root, um utilizador, uma ferramenta, e já está.

A KernelHost API: disponibilizar servidores automaticamente para o agente

Um agente não só pode trabalhar num servidor, como também pode, através da KernelHost API, disponibilizar e controlar servidores: consultar produtos, encomendar servidores, ler o estado, iniciar, parar e reiniciar servidores, bem como pedir e anular cancelamentos. Assim, «Prepara-me um servidor de teste para a atualização» passa a ser uma única tarefa, que o agente resolve desde a encomenda até à instalação concluída. As chaves API podem ser limitadas às permissões necessárias, uma Idempotency-Key evita encomendas duplicadas quando o agente repete um pedido, e cada consulta de credenciais gera uma notificação por e-mail. A faturação é PrePaid, sem período mínimo, pelo que um servidor de teste durante alguns dias não implica qualquer compromisso.

Custos: subscrição ou API

A operação implica dois tipos de custo: o servidor e o modelo de linguagem. O servidor é um servidor root comum, que já está a correr de qualquer forma. Para o modelo, há dois caminhos. Uma subscrição (Claude Pro ou Max, ChatGPT Plus ou Pro) inclui a utilização da respetiva ferramenta de linha de comandos dentro de uma quota e, com uso diário, costuma ser mais barata. Uma chave API fatura por tokens, não precisa de subscrição e pode ser limitada com um orçamento; para manutenção ocasional, fica-se muitas vezes por poucos euros por mês. Para tarefas automatizadas sem ninguém à frente, como o relatório diário de registos, a chave API é o caminho limpo, porque o início de sessão da subscrição está associado a um dispositivo e a uma pessoa.

Erros frequentes ao começar

• O agente corre como root. Cómodo no primeiro dia, perigoso a partir do segundo. Solução: utilizador dedicado com lista branca sudo.
• Todas as perguntas de confirmação estão desligadas. Solução: permitir sem confirmação apenas os comandos de leitura e confirmar tudo o que seja intrusivo.
• Nenhum ficheiro de regras. Sem CLAUDE.md, AGENTS.md ou GEMINI.md, o agente não conhece os seus serviços nem os limites que definiu. Solução: escrever as regras e completá-las a cada correção.
• Nenhuma cópia de segurança antes da sessão. Solução: um snapshot ou uma cópia de segurança testada antes de o agente alterar alguma coisa, como descrito na estratégia de backup.
• Segredos na tarefa. Solução: credenciais apenas em ficheiros que o agente não precise de mostrar e, em caso de descuido, gerá-las de novo de imediato.
• Resultados aceites sem verificação. Solução: exigir provas, por exemplo a linha de registo que sustenta uma suposição, e mandar verificar o resultado em produção.

O passo seguinte

Se quiser experimentar: um servidor root KVM com Debian ou Ubuntu, a lista de verificação para novos servidores root para a proteção básica e depois o guia passo a passo para o Claude Code e o Codex CLI. Uma hora depois, o seu servidor responde a perguntas sobre os seus próprios registos.

O nosso relato prático Ligar a IA ao servidor: como um agente de IA faz deploy e administra o seu servidor mostra como isto funciona no dia a dia, desde a ligação por SSH até ao deploy no sistema de produção.

Em resumo

• Um servidor gerido por IA é um servidor root comum no qual um agente de IA como o Claude Code, o Codex CLI ou o Gemini CLI trabalha com um utilizador próprio.
• O agente lê, analisa e propõe; as ações intrusivas só as executa após aprovação.
• Há três formas comprovadas: o agente no posto de trabalho por SSH, diretamente no servidor ou numa VM bastião.
• São inegociáveis: utilizador dedicado, modo de aprovação, cópia de segurança antes de cada sessão e nenhum segredo no prompt.
• Não é necessária uma GPU, porque o modelo de linguagem corre no fornecedor.
• Qualquer servidor da KernelHost cumpre os requisitos de origem, e através da KernelHost API o agente pode até disponibilizar servidores sozinho.