O agente de DevOps que nunca vê as suas credenciais

Todo mundo já entendeu que dá para pedir Terraform para um LLM. O problema é o acesso: para fazer algo útil, o agente precisa da cloud, do cluster, do state, dos segredos. E aí a conversa morre na mesa da segurança, com razão.

O Stakpak ataca exatamente esse ponto. Agente autônomo de DevOps, Apache 2.0, escrito em Rust, binário único. 1.7 mil estrelas no GitHub, 184 forks, mais de 3 mil commits.

O que ele faz de diferente

A proposta inverte a ordem de prioridade das ferramentas concorrentes. Segurança antes de capacidade:

• Secret Substitution: o modelo lê, escreve e compara segredos sem receber o valor real.
• Warden Guardrails: políticas em nível de rede bloqueiam operação destrutiva antes de rodar.
• Rulebooks: playbooks e SOPs em markdown que definem como o agente trabalha na sua casa.

Some mTLS na camada MCP, modo privacidade que redige IP e account ID da AWS, e backup automático de toda alteração de arquivo.

Onde o IaC entra

O Stakpak indexa localmente e faz busca semântica no seu código: Terraform, Kubernetes, Dockerfile e GitHub Actions. Ele lê o que você tem em vez de chutar com base no treino.

O stakpak init gera um INFRA.md com contas e regiões de cloud, clusters com versão e ferramenta de GitOps, backends e módulos de IaC, e os serviços rodando. Usa [?] para item não confirmado e [!] para informação inferida ou desatualizada.

Um agente que admite o que não sabe. Isso é raro o bastante para merecer aplauso, e em consultoria esse arquivo sozinho economiza uma semana de descoberta.

Autopilot

O runtime fica de pé 24/7 com schedules em cron, cada um com prompt e profile próprios, notificando Slack, Telegram ou Discord.

stakpak up

stakpak autopilot schedule add health \

  –cron ‘*/5 * * * *’ \

  –prompt ‘Check health’ \

  –profile monitoring

A separação de configuração é o detalhe bem resolvido: config.toml define comportamento (modelo, ferramentas permitidas, auto-aprovação, limite de turnos) e autopilot.toml define wiring (schedules, canais, rotas). Autonomia vira parâmetro versionado no Git, não efeito colateral.

Roda com LLM local

[profiles.offline]

provider = “local”

model = “offline/qwen/qwen3-coder-30b”

[profiles.offline.providers.offline]

type = “custom”

api_endpoint = “http://localhost:11434/v1”

Qualquer endpoint compatível com a API da OpenAI serve, Ollama ou LM Studio. Nenhum trecho do seu Terraform ou do seu log precisa sair do perímetro. Para banco, saúde e governo, é a diferença entre o projeto existir e não existir.

Antes de colocar em produção

• Open source não é tudo local. O modo –tool-mode local dispensa API key; as ferramentas de geração no modo remoto exigem chave da Stakpak. Mapeie o que você perde offline antes de prometer ao cliente.
• Versão 0.3.x. API instável e mudança de comportamento entre releases. Pin de versão e changelog lido.
• Guardrail não é garantia. Não há auditoria independente pública do Warden nem do sandbox. Defesa em profundidade, não contrato.
• Autopilot pede infra. Docker acessível ao usuário, 2 GB de RAM, swap em host pequeno, linger para sobreviver ao logout. Rode o stakpak autopilot doctor antes do primeiro boot.
• Comece por leitura. Indexação e diagnóstico têm risco quase zero. Apply automático em produção é outra decisão.

Vale o teste?

Rode stakpak init num ambiente de homologação e leia o INFRA.md. Vinte minutos. Depois repita com um profile offline apontando para Ollama. Se o resultado local for aceitável, você tem um caso que passa no jurídico.

A pergunta mais importante não é se o agente acerta o Terraform. É se você consegue dar acesso a ele sem perder o sono.

Fontes

• stakpak/agent (Apache 2.0)
• Documentação oficial
• Terraform MCP Server (MPL 2.0), alternativa oficial da HashiCorp