Grab Trata Agentes Autônomos como Não Confiáveis por Design

O time de cibersegurança do Grab entregou Palana, uma plataforma segura de execução nativa do Kubernetes para agentes de IA autônomos executando centenas de cargas de trabalho concorrentes nas operações de ride-hailing, pagamentos e logística da empresa em 900 cidades em oito países. A plataforma surgiu após prototipação de ambientes para OpenClaw e outros frameworks de agentes. O time concluiu que a configuração ad-hoc de containers não conseguia responder perguntas difíceis: em nome de qual usuário um agente atua, quais credenciais pode usar e como você o para sem confiar que ele cooperará?

O modelo de ameaça é explícito: agentes executando ferramentas arbitrárias, chamando APIs e escrevendo código têm perfis de risco fundamentalmente diferentes de serviços stateless. Injeção de prompt, sequestro de lógica, comprometimento de dependências, busca excessiva de objetivos e exposição de credenciais estão todos no escopo. A defesa central do Palana é isolamento de namespace. Cada agente executa em seu próprio namespace Kubernetes provisionado com RBAC restritivo, quotas de recursos, políticas de rede customizadas e contas de serviço isoladas. Um operador Kubernetes reconcilia o ciclo de vida completo—namespaces, storage, ingress e políticas de rede—a partir de uma definição de recurso customizado. Desenvolvedores interagem através de uma CLI chamada pcli ou um portal de autoatendimento. Engenheiros de plataforma trabalham diretamente com objetos Kubernetes padrão.

O tratamento de segredos marca o desvio mais acentuado do Palana dos fluxos de trabalho típicos de containers. Passar credenciais através de variáveis de ambiente ou arquivos montados é inaceitável para agentes autônomos. Palana usa segredos somente de proxy em vez disso: credenciais sensíveis—tokens de controle de versão, chaves de API de gateway de modelo, tokens GrabGPT por agente—permanecem no HashiCorp Vault e nunca chegam ao container do agente. Agentes recebem apenas tokens de placeholder abstratos. Quando um agente inicia uma chamada de saída, um proxy seguro intercepta a requisição, valida o destino e substitui o placeholder pela credencial ativa. O segredo bruto nunca chega ao ambiente, memória de execução ou logs do container.

Egresso é um ponto de controle centralizado. Todo o tráfego HTTP e HTTPS de saída passa por Envoy, que chama um sidecar ext-authz executando regras Open Policy Agent para identificar o pod chamador, avaliar política e registrar a requisição. Para HTTPS, Palana executa encerramento MITM usando uma CA que distribui aos pods de agentes. Isso permite inspeção completa de headers e validação de endpoints em tráfego criptografado—algo que políticas de rede Kubernetes isoladamente não conseguem fornecer. Os logs de auditoria estruturados são a superfície primária de análise forense pós-incidente.

Botões de parada operam fora do limite de confiança do agente. Pedir para um agente parar é uma funcionalidade, não um controle de segurança. Um agente comprometido ou confuso não pode ser confiável para auto-terminar. Os botões de parada do Palana executam no plano de controle: políticas de rede são desabilitadas diretamente de fora do runtime, e um reaper externo gerencia desligamentos inativos sem tocar no processo do agente. Agentes também obtêm storage persistente /data, assim workflows de longa duração—Hermes, Matlock, Butler, automações cts-aergia Slack—sobrevivem a reinicializações de containers sem perder estado de sessão ou contexto de memória.

O footprint de produção cobre OpenClaw e cargas de trabalho de teste de agent-framework, Claude Code e ambientes de desenvolvimento em nuvem acessíveis por navegador OpenCode, agentes conectados a Slack incluindo cts-aergia e workflows Claude-to-Slack, e sistemas de ordem superior onde supervisores agentic roteiam trabalho para agentes filho com escopo definido. Grab está planejando um segundo post cobrindo internalidades de orquestração de ciclo de vida, roteamento LLM e tooling de visibilidade operacional.

O princípio de design chave: cada controle de segurança deve viver fora do limite de confiança do agente. Injeção de credenciais, encerramento de rede e botões de parada todos executam em infraestrutura que o agente não pode alcançar ou modificar. Esta restrição elimina uma grande classe de caminhos de comprometimento. Também significa que o operador Kubernetes deve possuir o ciclo de vida completo do agente, e cada nova capacidade de agente requer uma affordância explícita de plataforma em vez de um workaround único.