Abstract摘要

Artificial intelligence (AI) agents are moving from experiments into everyday engineering workflows. They can read code, call application programming interfaces (APIs), run tests, create merge requests, answer Slack messages, and keep long-running state. That makes them useful, but it also changes the risk model - especially as agents get more autonomous in their use of tools. An agent with network access, credentials, tools, and memory is no longer just a chat interface. It is a workload that can act.人工智能（AI）智能体正从实验阶段进入日常工程工作流程。它们可以读取代码、调用应用程序编程接口（API）、运行测试、创建合并请求、回复Slack消息，并保持长期运行状态。这使它们变得有用，但也改变了风险模型——尤其是当智能体在使用工具时变得更加自主。一个拥有网络访问权限、凭证、工具和记忆的智能体不再只是一个聊天界面。它是一个可以采取行动的工作负载。

The more capability we give to the agents, the more valuable they get - but they also get riskier, and maintaining controls and oversight gets more challenging. We need isolated environments, with clear intentional capabilities added rather than just inheriting “everything on your laptop”.我们赋予智能体的能力越多，它们就越有价值——但风险也越大，维护控制和监督也更具挑战性。我们需要隔离的环境，并明确添加有意图的能力，而不是仅仅继承“你笔记本电脑上的一切”。

Palana is Grab’s Kubernetes-native platform for running those workloads safely. It gives each agent an isolated namespace, persistent storage, controlled ingress, proxy-mediated egress, Vault-backed credential injection, large language model (LLM) routing, Git access controls, structured audit logs, and emergency kill switches. It is currently used to run hundreds of agents, including remote development environments, Slack automation, OpenClaw workers, Hermes agents, and other long-running internal systems.Palana是Grab基于Kubernetes的平台，用于安全运行这些工作负载。它为每个智能体提供独立的命名空间、持久化存储、受控的入站流量、代理中介的出站流量、基于Vault的凭证注入、大语言模型（LLM）路由、Git访问控制、结构化审计日志和紧急终止开关。目前，它用于运行数百个智能体，包括远程开发环境、Slack自动化、OpenClaw工作节点、Hermes智能体以及其他长期运行的内部系统。

In this post, we share why we built Palana, what it does, and how its architecture lets teams experiment with autonomous agents without giving up control over identity, secrets, network access, and operational visibility.在这篇文章中，我们将分享为什么构建Palana、它的功能，以及它的架构如何让团队在实验自主智能体时，不放弃对身份、密钥、网络访问和运营可见性的控制。

Introduction引言

The first wave of AI coding tools lived close to the user: an integrated development environment (IDE) plugin, a chat window, or a command-line assistant running on a developer’s laptop. That model is familiar and easy to adopt, but it has limits. Long-running agents need persistent state. Team workflows need shared access through Slack or web user interfaces (UIs). Security teams need to inspect what an agent is doing, and apply highly granular controls over what an agent can do. Platform teams need a way to stop, resume, update, and audit the workload.第一波AI编码工具贴近用户：集成开发环境（IDE）插件、聊天窗口或运行在开发者笔记本电脑上的命令行助手。这种模式熟悉且易于采用，但也有局限性。长期运行的智能体需要持久化状态。团队工作流需要通过Slack或Web用户界面（UI）共享访问。安全团队需要检查智能体的行为，并对智能体可以执行的操作应用高度精细的控制。平台团队需要一种方式来停止、恢复、更新和审计工作负载。

As usage grew, we started seeing the same question in different forms:随着使用量的增长，我们开始以不同形式看到同一个问题：

How do we let agents do useful work inside the company without treating every new agent as a bespoke infrastructure project?如何让智能体在公司内部执行有用的工作，而不必将每个新智能体视为一个定制的基础设施项目？

The answer was not simply to “run agents in containers”. Containers help package the runtime, but they do not answer the harder platform questions:答案不仅仅是“在容器中运行智能体”。容器有助于打包运行时，但它们无法回答更困难的平台问题：

  • Which user does this agent act on behalf of?这个智能体代表哪个用户？
  • What credentials can it use?它可以使用哪些凭证？
  • Can it see another user’s state?它能看到其他用户的状态吗？
  • Can it connect directly to the internet?它能直接连接到互联网吗？
  • How do we inspect LLM, Git, and Hypertext Transfer Protocol (HTTP) activity after something goes wrong?在出现问题后，我们如何检查LLM、Git和超文本传输协议（HTTP）活动？
  • How do we stop an agent quickly without trusting the agent to cooperate?如何在不信任智能体配合的情况下快速停止它？
  • How do we give teams a self-service experience without handing them cluster-admin access?如何在不授予集群管理员权限的情况下，为团队提供自助服务体验？

Palana is our answer to those questions.Palana是我们对这些问题的答案。

What Palana isPalana是什么

Palana, an in-house proprietary system built by the CyberSecurity team at Grab, is a secure execution substrate for autonomous and semi-autonomous agents. The name comes from a Sanskrit root associated with protection, maintenance, and care. That maps well to the platform’s purpose: Palana is not trying to be the agent’s brain. It is the environment that contains, observes, and sustains the agent while it works.Palana是Grab网络安全团队构建的内部专有系统，是一个用于自主和半自主智能体的安全执行基础。其名称源自梵语词根，与保护、维护和关怀相关。这与平台的宗旨高度契合：Palana并非试图成为智能体的大脑，而是智能体工作时包含、观察和支持它的环境。

At a high level, Palana provides:从高层次来看，Palana提供：

  • A Kubernetes namespace per agent, with role-based access control (RBAC), resource quotas, network policy, and storage scoped to that agent.每个智能体一个Kubernetes命名空间，具有基于角色的访问控制（RBAC）、资源配额、网络策略和限定于该智能体的存储。
  • A command-line and portal experience for creating, running, stopping, configuring, and inspecting agents.用于创建、运行、停止、配置和检查智能体的命令行和门户体验。
  • Persistent /data storage so long-running agents can preserve memory, caches, repositories, and session state across restarts.持久化的/data存储，以便长期运行的智能体可以在重启后保留内存、缓存、仓库和会话状态。
  • Browser and shell access for interactive workloads such as Claude Code UI, OpenCode, IDEs, ttyd, or Secure Shell (SSH)-backed development flows.浏览器和Shell访问，用于交互式工作负载，如Claude Code UI、OpenCode、IDE、ttyd或基于安全外壳（SSH）的开发流程。
  • LLM access through a LiteLLM wrapper that injects per-agent GrabGPT credentials from Vault.通过LiteLLM包装器访问LLM，该包装器从Vault注入每个智能体的GrabGPT凭证。
  • HTTP and HTTPS egress through an Envoy and ext-authz proxy path, with Open Policy Agent (OPA) policy checks and structured request logs.通过Envoy和ext-authz代理路径的HTTP和HTTPS出站流量，具有开放策略代理（OPA）策略检查和结构化请求日志。
  • Proxy-only secrets, where agents can reference placeholder tokens but cannot read the underlying credentials directly.仅代理密钥，智能体可以引用占位符令牌，但不能直接读取底层凭证。
  • Git access through a bastion path so repository operations are attributable and policy-controlled.通过堡垒路径的Git访问，使仓库操作可归属且受策略控制。
  • Kill switches and idle shutdown so the control plane can isolate or stop workloads from outside the agent process.终止开关和空闲关闭，以便控制平面可以从智能体进程外部隔离或停止工作负载。

This combination lets Palana support several categories of work:这种组合使Palana能够支持几类工作：

  • Secure OpenClaw and agent-framework testing.安全的OpenClaw和智能体框架测试。
  • Cloud development environments accessible from a browser or SSH client.可通过浏览器或SSH客户端访问的云开发环境。
  • Fast prototyping and testing for agentic workloads in a secure environment.在安全环境中对智能体工作负载进行快速原型设计和测试。
  • Slack-connected agents such as cts-aergia and Claude-to-Slack workflows.Slack连接的智能体，如cts-aergia和Claude-to-Slack工作流。
  • Long-running task agents such as Hermes, Matlock, Butler, and custom team automations.长期运行的任务智能体，如Hermes、Matlock、Butler和自定义团队自动化。
  • Higher-order systems where agentic supervisors launch or route work to scoped agents.更高级的系统，其中智能体主管启动或将工作路由到限定范围的智能体。

Why we built it为什么构建它

The immediate need came from security research. We wanted a place to run and investigate OpenClaw and related agent frameworks without exposing the broader internal network or placing raw credentials inside the agent runtime. That use case forced us to design for containment from the beginning.直接需求来自安全研究。我们希望有一个地方来运行和调查OpenClaw及相关智能体框架，而不会暴露更广泛的内部网络或将原始凭证放入智能体运行时。这个用例迫使我们从一开始就设计隔离。

The broader need quickly became developer productivity. Once the basic primitives existed, Palana became useful for remote coding, Slack automation, internal assistants, long-lived experiments, and agentic operational workflows. Grabbers wanted agents that could keep context over days or weeks, run from corporate infrastructure, access approved internal services, and survive laptop sleep, local dependency drift, or network changes.更广泛的需求很快变成了开发者生产力。一旦基本原语存在，Palana就变得对远程编码、Slack自动化、内部助手、长期实验和智能体操作工作流有用。Grab员工希望智能体能够保持数天或数周的上下文，从企业基础设施运行，访问经批准的内部服务，并在笔记本电脑休眠、本地依赖漂移或网络变化时存活。

The security and productivity goals reinforce each other. If the safe path is self-service and ergonomic, teams are more likely to use it. If the productive path is observable and policy-controlled by default, and the appropriate security is baked into the system automatically, platform teams do not have to retrofit controls after adoption.安全和生产力目标相辅相成。如果安全路径是自助服务且符合人体工程学，团队更有可能使用它。如果生产力路径默认是可观察且受策略控制的，并且适当的安全性自动融入系统，那么平台团队就不必在采用后改造控制。

Design principles设计原则

Palana’s architecture follows a few principles that shaped most of the implementation.Palana的架构遵循几个原则，这些原则塑造了大部分实现。

Isolation is the unit of trust隔离是信任的单位

Each agent gets its own namespace, service account, storage, network policy, and Vault scope. Agents should not see each other’s pods, secrets, or filesystem state by default. Inter-agent communication is possible, but it goes through explicit peering rules rather than ambient pod-to-pod reachability.每个智能体获得自己的命名空间、服务账户、存储、网络策略和Vault范围。默认情况下，智能体不应看到彼此的Pod、密钥或文件系统状态。智能体间通信是可能的，但通过明确的对等规则进行，而不是通过环境中的Pod到Pod可达性。

This means the platform does not have to assume every agent framework has perfect multi-tenant isolation internally. A framework designed as a single-user assistant can still be hosted safely by giving each user or worker its own Palana boundary.这意味着平台不必假设每个智能体框架内部具有完美的多租户隔离。一个设计为单用户助手的框架仍然可以通过为每个用户或工作节点提供自己的Palana边界来安全托管。

Credentials are never given to the agent凭证从不交给智能体

Traditional application hosting often gives credentials to the workload as environment variables or mounted files. That is risky for agent workloads because the agent may execute tools, run untrusted code, summarize files, install packages, or expose a web UI.传统的应用程序托管通常将凭证作为环境变量或挂载文件交给工作负载。这对智能体工作负载来说是有风险的，因为智能体可能执行工具、运行不受信任的代码、总结文件、安装包或暴露Web UI。

Palana separates two kinds of secrets:Palana区分两种密钥：

  • Agent-readable secrets live under the agent’s own Vault path and are available only to that agent’s service account.智能体可读密钥位于智能体自己的Vault路径下，仅对该智能体的服务账户可用。
  • Proxy-only secrets are stored under a separate Vault path and are read by the proxy layer, not by the agent.仅代理密钥存储在单独的Vault路径下，由代理层读取，而非智能体。

For proxy-only secrets, the agent sees a placeholder such as TOKEN_GITHUB_PAT or TOKEN_GRABGPT_API_KEY. When an outbound request travels through the proxy path, the proxy replaces the placeholder header with the real credential from Vault. The remote service receives a valid token, but the agent process never stores the token in its own environment or config.对于仅代理密钥，智能体看到的是占位符，如TOKEN_GITHUB_PAT或TOKEN_GRABGPT_API_KEY。当出站请求通过代理路径时，代理用Vault中的真实凭证替换占位符头。远程服务收到有效令牌，但智能体进程从未在其自身环境或配置中存储该令牌。

This pattern is especially important for LLMs, source control, API integrations, and browser-like tools where prompt injection or dependency compromise could otherwise expose long-lived credentials.这种模式对于LLM、源代码控制、API集成和类似浏览器的工具尤其重要，因为提示注入或依赖项妥协可能暴露长期凭证。

Egress is a control point出站流量是控制点

Agents can be useful only if they can call tools and services. Instead of forbidding network access, Palana makes network access observable and policy-mediated.智能体只有能够调用工具和服务才有用。Palana不是禁止网络访问，而是使网络访问可观察且受策略中介。

Agent pods receive proxy configuration automatically. External HTTP and HTTPS traffic flows through Envoy. Envoy asks ext-authz-proxy to identify the calling pod, evaluate policy with OPA, log the request, and optionally inject credentials. HTTPS traffic can be terminated by the proxy’s man-in-the-middle (MITM) listener for header inspection and replacement, with the generated certificate authority (CA) distributed to agent pods.智能体Pod自动接收代理配置。外部HTTP和HTTPS流量通过Envoy。Envoy询问ext-authz-proxy以识别调用Pod、使用OPA评估策略、记录请求，并可选地注入凭证。HTTPS流量可以由代理的中间人（MITM）监听器终止，用于头检查和替换，生成的证书颁发机构（CA）分发给智能体Pod。

This gives the platform a place to answer questions that normal Kubernetes networking cannot answer alone:这为平台提供了一个回答普通Kubernetes网络无法单独回答的问题的地方：

  • Which agent made this request?哪个智能体发出了这个请求？
  • Which user owns that agent?哪个用户拥有那个智能体？
  • Which host and method were requested?请求了哪个主机和方法？
  • Was the request allowed or denied?请求是被允许还是拒绝？
  • Which placeholder credentials were replaced?哪些占位符凭证被替换了？
  • Did the request go to an internal service, an LLM gateway, GitLab, or the public internet?请求是发往内部服务、LLM网关、GitLab还是公共互联网？

The control plane must stay outside the agent控制平面必须保持在智能体外部

Palana assumes an agent might become confused, compromised, or uncooperative. Operational controls therefore live outside the agent process. The operator reconciles namespaces and policies. The proxy controls egress. The portal and pcli (Palana command-line interface) manage lifecycle. The kill switch is enforced with network policy. Idle shutdown is handled by a separate reaper CronJob.Palana假设智能体可能变得混乱、受损或不合作。因此，操作控制位于智能体进程之外。操作器协调命名空间和策略。代理控制出站流量。门户和pcli（Palana命令行界面）管理生命周期。终止开关通过网络策略强制执行。空闲关闭由单独的收割者CronJob处理。

That separation matters. A kill switch that asks the agent to stop is a feature. A kill switch that removes the agent’s network path is a safety control.这种分离很重要。要求智能体停止的终止开关是一个功能。移除智能体网络路径的终止开关是一个安全控制。

Use Kubernetes primitives where they fit在合适的地方使用Kubernetes原语

Palana is intentionally Kubernetes-native. Agents are represented by custom resources. The operator reconciles namespaces, RBAC, storage, services, ingress, and network policies. Users can interact through pcli or the portal, while platform engineers can still inspect the underlying Kubernetes objects when debugging.Palana有意采用Kubernetes原生方式。智能体由自定义资源表示。操作器协调命名空间、RBAC、存储、服务、入站流量和网络策略。用户可以通过pcli或门户交互，而平台工程师在调试时仍可以检查底层的Kubernetes对象。

This gives us a layered experience: simple workflows for users, direct primitives for advanced operators, and infrastructure-as-code for the deployed platform.这为我们提供了分层体验：面向用户的简单工作流、面向高级操作员的直接原语，以及面向部署平台的基础设施即代码。

Conclusion结论

By centering the design around isolation, controlled egress, and proxy-mediated secrets, Palana provides a secure foundation for AI agents to operate within Grab. In Part 2, we will dive deeper into the under-the-hood architecture of Palana, exploring how it orchestrates agent lifecycles, handles LLM routing, and maintains operational visibility.通过围绕隔离、受控出站流量和代理中介密钥进行设计，Palana为AI智能体在Grab内部运行提供了安全基础。在第二部分中，我们将深入探讨Palana的底层架构，探索它如何编排智能体生命周期、处理LLM路由以及保持运营可见性。

Join us加入我们

Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.Grab是东南亚领先的超级应用，服务覆盖八个国家（柬埔寨、印度尼西亚、马来西亚、缅甸、菲律宾、新加坡、泰国和越南）的900多个城市。通过单一平台，数百万用户使用出行、配送和数字金融服务，包括网约车、送餐、支付、贷款以及通过GXS Bank和GXBank提供的数字银行。Grab成立于2012年，其使命是通过为每个人创造经济赋权来推动东南亚前进，同时实现可持续的财务绩效和积极的社会影响。

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!以技术为动力，以热情为驱动，我们的使命是通过为每个人创造经济赋权来推动东南亚前进。如果这个使命与你共鸣，今天就加入我们的团队吧！