Grab’s Palana Moves Agentic AI Security into the Infrastructure Layer

Introduction

As AI agents move from prototypes into production environments, their security profile starts to diverge sharply from that of traditional software. A conventional service usually follows a predictable execution path. An agent, however, may decide to invoke tools, call external APIs, inspect repositories, change files, and keep working across long-running tasks. Grab’s cybersecurity and platform engineering teams built Palana to address this shift by moving safety controls out of ad hoc application code and into the infrastructure layer.

Key points

• Isolation as the main trust boundary: Palana uses a zero-trust model in which each agent receives its own Kubernetes namespace, strict role-based access control, custom network policies, and an isolated service account. This limits the chance that a compromised agent framework can affect neighboring workloads or the underlying cluster.
• Secrets are not handed directly to agents: Instead of injecting high-value credentials through environment variables or mounted files, Palana separates agent-visible placeholder tokens from real secrets. Sensitive credentials such as version-control tokens and model gateway keys are stored in HashiCorp Vault.
• Outbound traffic becomes a control point: HTTP and HTTPS traffic is routed through Envoy and an external authorization service running Open Policy Agent rules. This layer can validate destinations, inspect headers, replace placeholder tokens with real credentials, and produce structured audit logs.
• Runtime control sits outside the agent: Palana does not rely on a potentially compromised agent to shut itself down. Network-level kill switches can be triggered from the control plane, and external reaper mechanisms can stop idle workloads without changing the core agent code.
• Kubernetes-native operations: Agents are represented as custom resources reconciled by a Kubernetes operator. The operator provisions namespaces, storage, network policies, and ingress paths, allowing platform teams to manage agent lifecycles with familiar infrastructure-as-code practices.

Why it matters

Palana is notable because it does not assume that a model-driven agent will always behave predictably or follow instructions. Instead, it accepts non-determinism as a property of the workload and surrounds it with deterministic infrastructure boundaries. For enterprises, that is a pragmatic security stance: do not expose raw secrets to the agent, do not grant broad network access by default, and make every sensitive external call observable and governable.

The design also points to a broader trend in agent platforms. The question is no longer only whether an agent can use tools, but whether it can use them safely, with identity isolation, auditable network paths, controlled credentials, and lifecycle management. As companies deploy coding agents, operations assistants, and business workflow automations, these platform capabilities may become baseline requirements.

At the same time, Palana should be viewed as infrastructure risk containment rather than a complete solution to every agent failure mode. Prompt injection, hallucinated actions, tool misuse, and goal drift still require evaluation, permission design, human review, and task-level governance. Palana’s contribution is to make those failures less likely to spread beyond the boundaries assigned to a given workload.

Source: InfoQ 中文