Como conectar o ChatGPT a uma VPS via MCP com controle e auditoria

Trabalhar com uma VPS usando inteligência artificial ainda costuma exigir um ritual pouco eficiente: eu peço uma análise ao ChatGPT, recebo comandos, abro o terminal, executo, copio logs, volto à conversa e reconstruo o contexto. Esse ciclo funciona, mas cria atrito justamente onde a IA deveria ajudar mais: na execução.

Foi a partir desse problema que eu desenvolvi o MCP VPS Agent Gateway, um projeto open source e auto-hospedado para conectar o ChatGPT a uma VPS Linux via MCP com escopo definido pelo proprietário do servidor, autenticação OAuth, autorização aplicada no próprio host e trilha de auditoria.

Resposta curta: o MCP VPS Agent Gateway cria uma ponte entre o ChatGPT Web e uma VPS Linux. O ChatGPT acessa ferramentas MCP por HTTPS, o Gateway opera sem root e um Broker privilegiado reautoriza cada ação conforme a política definida pelo usuário. A autoridade efetiva fica no servidor.

O que é o MCP VPS Agent Gateway?

O MCP VPS Agent Gateway é uma implementação em Go que usa o Model Context Protocol (MCP) para permitir que clientes de IA, como o ChatGPT Web, inspecionem e operem recursos de uma VPS Linux de forma controlada.

O projeto foi desenhado para um cenário específico: eu quero que a IA consiga trabalhar de verdade no servidor, mas quero decidir exatamente quais arquivos, serviços, containers, comandos e capacidades ela poderá usar. Essa decisão fica expressa em política no lado do servidor.

O GitHub hospeda código, documentação, releases e atualização. Depois da instalação, ele não participa do caminho operacional entre o ChatGPT e a VPS.

Que problema esse projeto resolve?

O primeiro gargalo é o mais óbvio: o “copiar e colar operacional” entre uma conversa com IA e o terminal da VPS. O ChatGPT sugere comandos, eu abro o terminal, executo, copio a saída, volto à conversa e reconstruo o contexto. Em tarefas pequenas isso é tolerável. Em investigação de logs, configuração, deploy, Docker, systemd ou manutenção contínua, o atrito se acumula rapidamente.

Existe ainda um segundo limite prático para quem usa agentes de programação como o Codex de forma intensiva. Dependendo do plano, o serviço trabalha com cotas de uso em janelas temporais, inclusive uma janela semanal. Projetos longos ou sessões de alta intensidade podem consumir essa franquia e transformar a disponibilidade do agente em gargalo. O MCP VPS Agent Gateway reduz essa dependência de um único ambiente de execução: o ChatGPT Web passa a poder operar diretamente as ferramentas autorizadas na VPS, sem exigir que toda intervenção no servidor seja feita por uma sessão do Codex.

Uma terceira alternativa comum é usar GitHub Actions como ponte para executar tarefas no servidor. Para CI/CD isso é excelente, mas como interface operacional conversacional introduz o GitHub no meio do caminho. Muitas mudanças passam a exigir editar arquivos, criar commit, fazer push, disparar workflow, aguardar o runner e eventualmente executar novo deploy apenas para verificar ou ajustar algo no host.

Com uma conexão MCP válida, o ChatGPT pode consultar informações do sistema, ler e modificar arquivos autorizados, analisar logs, trabalhar com Docker e Compose, interagir com serviços systemd e executar outras ações permitidas pela política. O GitHub continua cumprindo seu papel de código-fonte, versionamento, releases e CI/CD, mas deixa de ser necessário como relay de runtime para cada operação administrativa.

Isso transforma a conversa em uma interface operacional. Para mim, esse é um exemplo direto de tecnologia aplicada: o valor aparece quando a IA atravessa a última milha entre recomendar uma ação e conseguir executá-la dentro de limites verificáveis.

Como funciona a arquitetura?

A arquitetura separa a superfície MCP da fronteira privilegiada. O Gateway recebe a conexão do cliente, valida autenticação e schemas e encaminha operações para um Broker local. O Broker é quem possui autoridade para revalidar política e executar ações no host.

ChatGPT Web / cliente MCP
        |
        | HTTPS + MCP Streamable HTTP
        v
Gateway container
sem root, sem /host
        |
        | Unix socket protegido
        v
Broker container
fronteira privilegiada
        |
        | host montado em /host
        v
Linux / systemd / Docker / arquivos

O ponto de projeto que considero mais importante é simples: o modelo de IA não decide a própria autoridade. O Gateway também não é a autoridade final. Cada operação privilegiada é reavaliada pelo Broker contra o sujeito autenticado, a ferramenta solicitada, o recurso, a ação e a política vigente.

Como o acesso à VPS é limitado?

O mesmo pacote pode operar com diferentes perímetros. No perfil Project, recomendado como padrão, o usuário delega uma raiz específica, por exemplo /opt/meu-app. No perfil Custom, pode combinar vários recursos e capacidades. O perfil Whole Host amplia o teto físico do filesystem para /, mas outras capacidades administrativas continuam separadas na política.

Essa separação importa porque “acesso ao filesystem” é apenas uma dimensão. Shell, units do systemd, Docker, rede, pacotes, usuários, grupos, firewall e ações administrativas têm regras próprias. Uma capability existir no software não significa que esteja habilitada naquela instalação.

Quais controles de segurança estão implementados?

• Gateway executado sem root e sem acesso direto ao host ou ao Docker socket.
• Broker acessível localmente por Unix socket, sem API TCP privilegiada exposta.
• Política server-side com negação por padrão e reautorização de operações privilegiadas.
• Proteções contra path traversal e fuga por symlink no filesystem.
• Journal de operações, semântica de idempotência e locks com fencing para mutações.
• OAuth/OIDC integrado para o caminho público suportado.
• Auditoria das operações, incluindo o fluxo de validação ponta a ponta com o ChatGPT.
• Segredos fora das ferramentas genéricas apresentadas ao modelo.

O Broker continua sendo um componente privilegiado. Portanto, ele precisa ser tratado como parte sensível da infraestrutura. A proposta do projeto é tornar essa autoridade explícita, limitada por política e auditável.

Como instalar o MCP VPS Agent Gateway?

Durante a fase de release candidate, o fluxo documentado parte do repositório e usa Docker Compose e scripts transparentes:

git clone https://github.com/josemirmoura/mcp-vps-agent-gateway.git
cd mcp-vps-agent-gateway
bash scripts/install.sh

O instalador conduz a escolha de escopo, mostra a autoridade efetiva, sobe os containers, executa verificações locais, configura o acesso público seguro com OAuth integrado, orienta a conexão do ChatGPT e exige uma chamada MCP real e auditada antes de considerar a instalação concluída.

Essa regra foi intencional. Containers “healthy” mostram que serviços subiram. Para este projeto, a validação precisa chegar até o cliente real. O fluxo só fecha quando uma ferramenta inofensiva, como system.info, parte do ChatGPT, atravessa autenticação e política, executa no servidor e aparece na auditoria.

O que o projeto já consegue fazer?

A implementação atual inclui operações de filesystem em escopo, shell e jobs duráveis com sandbox, systemd, Docker e Compose, diagnósticos, pacotes, usuários e grupos, UFW, elevação fora do canal MCP, SQLite controlado pelo Broker, journal de operações, locks e auditoria.

O conjunto de ferramentas é deliberadamente mais amplo do que o que costuma ficar ativo por padrão. A política em config/policy.yaml define o perímetro real de cada instalação.

Qual é o status atual do projeto?

Na data desta publicação, o repositório está em v0.1.0-rc.3. O projeto permanece em pré-release enquanto passa pelo gate final de aceitação do operador antes do congelamento da primeira versão estável.

O fluxo foi validado em Ubuntu 24.04 LTS, com aceitação de runtime em linux/amd64. Imagens para linux/arm64 são construídas, mas a documentação ainda não declara equivalência de aceitação completa em hardware ARM64 nativo. O próprio repositório também deixa claro que confiabilidade prolongada em produção continua sendo uma etapa posterior de maturidade.

Essa distinção é importante. Estou publicando o projeto agora porque a arquitetura, o instalador, os controles e o caminho ChatGPT Web até a VPS já têm evidências de validação. A promessa de estabilidade de produção só deve vir quando houver evidência suficiente para sustentá-la.

Para quem esse projeto pode ser útil?

Vejo aplicação principalmente para desenvolvedores, profissionais de DevOps, pesquisadores, makers, equipes pequenas e usuários que administram serviços próprios em VPS e querem experimentar agentes de IA com capacidade operacional real. Também é um laboratório interessante para estudar desenho de autoridade, segurança de agentes, MCP, automação de infraestrutura e interação entre LLMs e sistemas Linux.

Quem procura apenas uma interface gráfica para SSH provavelmente está resolvendo outro problema. O foco aqui é oferecer ferramentas estruturadas para agentes, com política verificável e trilha operacional.

Perguntas frequentes sobre ChatGPT, VPS e MCP

O que significa MCP?

MCP é a sigla para Model Context Protocol, um protocolo usado para conectar modelos e clientes de IA a ferramentas e fontes de dados externas por uma interface padronizada.

O MCP VPS Agent Gateway substitui SSH?

O projeto não pretende substituir SSH. SSH continua sendo uma ferramenta administrativa fundamental. O Gateway cria uma superfície de ferramentas MCP voltada para clientes de IA, com escopo e autorização próprios.

Preciso fornecer minha senha da VPS ou chave SSH ao ChatGPT?

O fluxo suportado foi projetado para funcionar sem entregar ao ChatGPT a senha da VPS, uma chave SSH privada ou o Docker socket. O acesso ocorre pelo endpoint MCP configurado no servidor e pela política aplicada pelo Broker.

O ChatGPT recebe acesso root?

O Gateway roda sem root. O Broker é o componente privilegiado e aplica a política. A autoridade apresentada ao cliente depende das capacidades e recursos explicitamente delegados pelo operador.

O GitHub precisa ficar online entre o ChatGPT e a VPS?

Não. O GitHub distribui código, documentação e releases. O caminho de runtime ocorre diretamente entre o cliente MCP, o endpoint da instalação e a VPS.

O projeto já está estável para produção?

A versão publicada neste momento é release candidate. Já existem validações automatizadas e testes ponta a ponta, inclusive com chamada real do ChatGPT Web, mas a versão estável e a evidência de confiabilidade prolongada em produção ainda fazem parte das próximas etapas.

Quer testar ou acompanhar o projeto?

O código está aberto sob licença Apache 2.0. Se você trabalha com Linux, DevOps, agentes de IA ou MCP, vale examinar a arquitetura e testar primeiro em um ambiente controlado.

Se o projeto for útil para você, deixe uma star, acompanhe as releases e use as issues para relatar problemas, sugerir melhorias ou compartilhar casos de uso. Essa fase de productização ganha qualidade quando a validação sai do ambiente do autor e encontra outros servidores, workloads e formas reais de uso.