Building a Secure Kubernetes Platform for Autonomous AI Agents

grab · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Secure execution platform for autonomous AI agents

Grab needed a reusable way to run increasingly autonomous AI agents inside the company without giving every agent ambient laptop privileges, raw credentials, unrestricted network access, or bespoke infrastructure.

Constraints:

• Agents can read code, call APIs, run tests, create merge requests, answer Slack messages, and keep long-running state
• Network access, credentials, tools, and memory make agents act like workloads rather than chat interfaces
• Security teams needed granular controls and auditability
• Long-running agents needed persistent state and shared team access
• Operational controls had to work even if an agent became confused or compromised
• Teams needed self-service without cluster-admin access

Architecture

Grab built Palana as a Kubernetes-native substrate for autonomous and semi-autonomous agents. Each agent gets its own namespace, service account, RBAC, resource quotas, network policy, storage, and Vault scope. Agents access LLMs through a LiteLLM wrapper, external HTTP through Envoy/ext-authz/OPA, credentials through proxy-only placeholder replacement, Git through a bastion path, and lifecycle controls through pcli, a portal, operator reconciliation, kill switches, and idle shutdown.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user[User] --> palana-cli[Palana CLI]
  user[User] --> palana-portal[Palana Portal]
  palana-cli[Palana CLI] --> palana-operator[Palana Operator]
  palana-portal[Palana Portal] --> palana-operator[Palana Operator]
  palana-operator[Palana Operator] --> agent-namespace[Agent Namespace]
  palana-operator[Palana Operator] --> idle-reaper[Idle Reaper]
  agent-namespace[Agent Namespace] --> agent-pod[Agent Pod]
  agent-namespace[Agent Namespace] --> vault[Vault]
  agent-pod[Agent Pod] --> litellm-wrapper[LiteLLM Wrapper]
  agent-pod[Agent Pod] --> envoy-proxy[Envoy Proxy]
  agent-pod[Agent Pod] --> git-bastion[Git Bastion]
  litellm-wrapper[LiteLLM Wrapper] --> vault[Vault]
  envoy-proxy[Envoy Proxy] --> ext-authz-proxy[Ext Authz Proxy]
  ext-authz-proxy[Ext Authz Proxy] --> opa[OPA]
  ext-authz-proxy[Ext Authz Proxy] --> vault[Vault]

Components

Data flow

A user creates or manages an agent through pcli or the portal. The Palana operator reconciles the agent's namespace, RBAC, storage, service, ingress, and network policies. The running pod receives persistent /data storage and proxy configuration. LLM, Git, and HTTP egress are mediated through LiteLLM, bastion, or Envoy/ext-authz paths, where OPA evaluates policy, Vault-backed proxy-only secrets are injected, and structured logs capture who did what.

Why this architecture

Grab made Palana Kubernetes-native because agents needed workload-grade isolation, lifecycle management, and observability while still being ergonomic enough for teams to adopt. Namespaces and Kubernetes primitives create isolation boundaries; proxy-mediated secrets and egress avoid raw credential exposure; and external control-plane mechanisms such as kill switches keep safety controls outside the agent process.

Models used: LLMs routed through GrabGPT · LiteLLM wrapper

Scale

• Palana is used to run hundreds of agents.
  “It is currently used to run hundreds of agents, including remote development environments, Slack automation, OpenClaw workers, Hermes agents”article, stated
• Grab serves over 900 cities across eight countries.
  “Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam).”article, stated
• Long-running agents are expected to preserve context over days or weeks.
  “Grabbers wanted agents that could keep context over days or weeks, run from corporate infrastructure, access approved internal services”article, stated

Alternatives considered (roads not taken)

Run agents in containers only

Rejected because: Containers package runtimes but do not answer identity, credential, network, inspection, and self-service platform questions.

Let agents inherit broad laptop-like access

Rejected because: Autonomous agents with tools and credentials become workloads that can act, so capabilities must be intentionally added.

Give credentials directly to the workload

Rejected because: Agent workloads may execute tools, run untrusted code, install packages, expose web UIs, or be prompt-injected.

Ask the agent process to stop itself during emergencies

Rejected because: Palana assumes agents may become confused, compromised, or uncooperative, so safety controls must sit outside the agent.

Patterns

privacy-preserving-processing (security)

Palana isolates each agent in its own namespace, storage, service account, network policy, and Vault scope.

safety-policy-enforcement (security)

Egress is mediated through Envoy, ext-authz, and OPA so outbound requests can be allowed, denied, logged, and credential-injected by policy.

observability-tracing (operations)

Palana captures structured logs for LLM, Git, and HTTP activity so teams can inspect agent behavior after incidents.

agent-memory (agent architecture)

Persistent /data storage lets long-running agents retain memory, caches, repositories, and session state across restarts.

fallback-degradation (operations)

External kill switches and idle shutdown stop or isolate agents even if the agent process does not cooperate.

Tradeoffs

Use Kubernetes namespaces as the isolation unit

Chose Per-agent namespace, service account, RBAC, storage, network policy, and Vault scope over Trusting agent frameworks to provide their own multi-tenant isolation.

Rationale: Infrastructure-level isolation lets single-user assistant frameworks run safely inside explicit Palana boundaries.

Mediate egress instead of forbidding networking

Chose Observable, policy-mediated HTTP/HTTPS egress through Envoy, ext-authz, and OPA over Blocking network access entirely.

Rationale: Agents need tools and services to be useful, but the platform needs an inspectable control point for outbound activity.

Keep operational control outside the agent

Chose Operator, proxy, portal, CLI, kill switch, and reaper controls over Relying on agent cooperation for lifecycle and safety.

Rationale: External controls still work when the agent is compromised or confused.

Gotchas (what bit them)

Agent workloads amplify credential risk.

Root cause: Agents may execute tools, run untrusted code, install packages, summarize files, or expose a web UI.

Resolution: Palana separates agent-readable secrets from proxy-only secrets and injects real credentials only in the proxy path.

Containers alone did not solve enterprise agent governance.

Root cause: Packaging an agent runtime did not answer identity, credential, network, inspection, stop, and self-service questions.

Resolution: Palana wraps containers in Kubernetes namespaces, policy controls, lifecycle tooling, and audit paths.

A cooperative stop signal is not a safety control.

Root cause: Agents can become confused, compromised, or uncooperative.

Resolution: Kill switches remove network paths and control-plane mechanisms operate outside the agent process.

Evaluation

The source evaluates Palana by describing adopted workload categories, hundreds of running agents, and security questions the platform can answer through policy and structured logs.

Metrics: hundreds of agents · per-agent namespaces · over 900 cities across eight countries in Grab's operating context · structured logs for host, method, allow/deny, and credential replacement

Outcomes

• Palana runs hundreds of internal Grab agents
• Teams use it for remote development environments, Slack automation, OpenClaw workers, Hermes agents, and other long-running systems
• The platform gives agents isolated namespaces, controlled egress, proxy-mediated secrets, audit logs, and kill switches
• Grab can experiment with autonomous agents while controlling identity, secrets, network access, and operational visibility

Palana is described as operating in Grab's broader environment of over 900 cities and eight countries, with hundreds of agents already running.