Grab Builds Secure Agentic AI Workload Platform

Grab's cybersecurity and platform engineering teams built Palana, a Kubernetes-native secure execution platform, to safely run autonomous AI workloads by implementing deterministic guardrails and zero-trust isolation. The platform addresses security risks like prompt injection and credential exposure by decoupling secrets management and routing all outbound traffic through a centralized proxy with real-time validation. Palana enables scalable, auditable agent operations without bespoke environments.

To safely run autonomous artificial intelligence workloads, the cybersecurity and platform engineering teams at Grab have built Palana https://engineering.grab.com/palana-part-1-secure-platform-for-ai-agents , a proprietary, Kubernetes-native secure execution platform. Palana acts as a secure, isolated runtime environment that implements deterministic guardrails around the inherently non-deterministic behaviors of model-driven applications. Grab developed this platform after building prototype environments to test Claw and other agent frameworks, realizing that a systematic, infrastructure-level approach was required to contain the security risks of highly autonomous agents. While traditional applications operate predictably, model-driven agents execute arbitrary tools, call application programming interfaces, and read or write source code to solve problems independently. This operational freedom introduces severe security challenges, making agents highly vulnerable to prompt injection, logic hijacking, dependency compromises, excessive goal seeking, and hallucinations. For examples see AI Agents Gone Rogue https://www.osohq.com/developers/ai-agents-gone-rogue . By introducing Palana, Grab addresses critical infrastructure-level questions regarding agent identity, network access, and operational auditability without needing to build bespoke, manual environments for every individual workload. The platform establishes isolation as its primary unit of trust through a zero-trust model, ensuring that a security compromise in one agent framework does not affect adjacent workloads or the underlying compute cluster. Palana achieves this by assigning each agent to its own dedicated Kubernetes namespace configured with restrictive Role-Based Access Control, custom network policies, and isolated service accounts. Additionally, agents receive persistent, localized storage to preserve state and memory across container restarts during long-running asynchronous workflows. Traditional methods of passing credentials through environment variables or mounted files are unacceptably risky for autonomous agents because a compromised runtime could expose high-value API keys to untrusted scripts. To eliminate this vulnerability, Palana decouples secrets management into agent-readable credentials and proxy-only secrets. Highly sensitive credentials, such as version control personal access tokens and model gateway API keys, remain secured within HashiCorp Vault. The agent container is only provisioned with abstract, dummy placeholder tokens. When the agent initiates an outbound API call, a secure, intermediate proxy intercepts the request, validates the destination, and replaces the placeholder with the real secret dynamically. Consequently, the raw secret is never written to the agent container's environment, execution memory, or log files. Because agents must communicate with external tools and model endpoints to be productive, the egress pathway is designed as a centralized security control point. Palana automatically routes all outbound HTTP and HTTPS traffic through an Envoy proxy and an external authorization service running Open Policy Agent rules. Using Man-in-the-Middle certificate authority termination, the proxy decrypts traffic in real-time, allowing header evaluation, endpoint validation, and token substitution while generating detailed, structured audit trails. Furthermore, because a compromised agent cannot be trusted to self-terminate, operational controls exist entirely outside the execution runtime. Network-level kill switches disable network policies directly from the control plane, and an independent external reaper triggers idle shutdowns without modifying the core agent code. Integrating securely into a Kubernetes-native framework allows platform architects to scale and debug agent runtimes using standard infrastructure-as-code practices. Each agent is modeled as a custom resource reconciled by a custom Kubernetes operator that dynamically provisions namespaces, storage, network policies, and ingress paths. This design splits the operational experience into a simplified user interface and command-line tool for developers, and a robust, standard Kubernetes layer for systems engineers. Platform teams utilize these native definitions to programmatically audit, update, and manage the lifecycle of hundreds of concurrent agent workloads across the production cluster.