Tem muita conversa sobre agente autônomo, copiloto de infraestrutura e deploy acelerado por IA. O problema é que a conta costuma chegar depois: não quando a demo funciona, mas quando o caminho mais rápido vira caminho crítico.
Dois casos de maio ajudam a enxergar isso sem romantização. A Railway sofreu um apagão amplo depois que o Google Cloud suspendeu sua conta de produção por engano. A Composio publicou um boletim de incidente dizendo que um atacante explorou um toolchain agentic interno, escalou privilégios e forçou uma rodada pesada de revogação de credenciais. São problemas diferentes. A lição operacional é parecida.
O risco não está só em “usar IA na infra”. O risco aparece quando uma automação, um agente ou uma dependência escondida ganha poder demais sem fallback decente.
Na Railway, o problema não era só cair na GCP
No relatório da própria Railway, a interrupção começou quando o Google Cloud colocou a conta de produção deles em estado de suspensão de forma incorreta. O impacto direto já foi ruim: API, dashboard, banco e parte da computação ficaram offline por horas.
Mas o detalhe que mais importa para quem cuida de produto e operação veio depois. Mesmo workloads que ainda estavam em Railway Metal e AWS acabaram ficando inacessíveis quando o cache de rotas expirou, porque o edge dependia de uma control plane API hospedada na GCP para repopular as tabelas de roteamento.
Esse trecho vale ouro porque vai além do “a nuvem caiu”. A própria Railway assumiu responsabilidade pelas escolhas de arquitetura que deixaram uma ação upstream virar outage de plataforma inteira. Em português claro: não basta ter multi-cloud no diagrama se a descoberta de workload, o controle de rota ou a coordenação central continuam presos a um lugar só.
É o tipo de detalhe que parece sofisticado e resiliente até o dia em que vira gargalo sistêmico.
Na Composio, o problema foi autonomia demais no lugar errado
No boletim da Composio, o quadro é outro e talvez até mais desconfortável para quem está empolgado com stack agentic. Segundo a empresa, o atacante testou combinações de exploração com padrões gerados por LLM, conseguiu apoio inicial em uma ferramenta agentic interna usada para monitorar infraestrutura e reportar falhas de conectores, e daí escalou acesso até executar código arbitrário dentro do sandbox de execução de ferramentas.
O boletim também diz que a empresa revogou conexões afetadas, apagou chaves antigas, recomendou rotação ampla de credenciais e publicou indicadores de comprometimento para clientes conferirem logs. GitHub apareceu como o maior bloco de conexões impactadas, mas não foi o único.
A parte mais importante aqui não é o sensacionalismo. É a combinação. Quando monitoramento, remediação, definição de ferramentas e acesso útil demais convivem sem contenção suficiente, o incidente deixa de ser pontual. Ele ganha pernas.
O ponto em comum é o blast radius
Os dois casos não são idênticos, e seria preguiçoso tratar tudo como “mais uma falha causada por IA”. Não é isso.
Na Railway, o coração do problema foi uma dependência operacional escondida no hot path. Na Composio, foi a cadeia de privilégios e automação em torno de sistemas internos. Mas os dois episódios apontam para a mesma pergunta que muita equipe ainda evita fazer:
o que acontece quando esse componente que acelera tudo também concentra poder demais?
Em infra, isso pesa mais do que no código do dia a dia. Código ruim vira bug, PR torto, retrabalho. Já autonomia mal cercada em operação pode virar:
- indisponibilidade longa,
- segredo exposto,
- deploy bloqueado,
- credencial revogada em massa,
- fallback improvisado no pior momento.
É por isso que a discussão madura sobre agentes na infra não deveria começar em “qual ferramenta escreve mais shell”. Ela deveria começar em poder, alcance e reversibilidade.
Antes de soltar mais autonomia em produção, eu olharia estas cinco coisas
- Hot path real: se um provider, control plane ou serviço auxiliar sumir, o que continua funcionando de verdade?
- Escopo do agente: quais sistemas, credenciais e ações ele consegue alcançar sem pedir ajuda?
- Trilha de revisão: o que passa por diff, PR, aprovação e histórico auditável antes de tocar produção?
- Capacidade de corte: se der ruim, você consegue revogar chave, parar automação e reduzir o raio rápido?
- Fallback humano: existe procedimento manual minimamente viável ou todo mundo depende da mesma engrenagem?
Se essas respostas estiverem vagas, a automação pode até parecer moderna. Operacionalmente, ela ainda está crua.
Velocidade boa não é a que some com o freio
IA ajuda muito quando resume logs, monta hipótese, escreve runbook inicial, prepara infra como código, sugere revisão e acelera tarefas repetitivas. Isso já é um baita ganho. O salto perigoso acontece quando a equipe confunde aceleração com delegação total.
O jeito mais saudável de usar esse tipo de ferramenta continua sendo meio menos glamouroso: escopo curto, credencial limitada, revisão humana onde o custo do erro explode, e arquitetura pensada para não cair inteira quando uma peça central falha.
No fim, ninguém compra o argumento de que “foi o provider”, “foi o agente” ou “foi a automação”. O usuário vê o produto parado. E o time fica com a conta.
