Grab 的 Palana：把智能体安全边界下沉到基础设施层

导语

随着 AI 智能体从演示走向生产环境，企业面临的安全问题正在发生变化。传统应用通常按照开发者写好的路径执行，而智能体可能根据模型输出自主调用工具、请求 API、读取或修改代码，并在长时间任务中持续积累状态。Grab 的网络安全与平台工程团队为此构建了 Palana，试图把智能体运行时的安全边界从应用代码下沉到基础设施层。

核心要点

• 以隔离区作为信任单元：Palana 采用零信任思路，为每个智能体分配独立的 Kubernetes 命名空间，并配置严格的 RBAC、网络策略和隔离服务账户，降低相邻工作负载之间的横向影响。
• 避免密钥直接暴露给智能体：平台将“智能体可见的占位凭据”和“代理可用的真实密钥”分离。高敏感令牌存放在 HashiCorp Vault 中，智能体容器只持有抽象占位符。
• 通过代理集中管控出口流量：所有 HTTP/HTTPS 出站请求会经过 Envoy 代理和基于 Open Policy Agent 的外部授权服务。代理可验证目标、评估请求头、替换令牌，并生成结构化审计记录。
• 运行控制不依赖智能体自觉：Palana 将关停、断网、空闲回收等控制放在运行时之外。即使智能体被提示词注入或逻辑劫持影响，平台仍可从控制面执行网络级“断网开关”和外部回收流程。
• 用 Kubernetes 原生方式管理生命周期：每个智能体被建模为自定义资源，由 Kubernetes operator 调和命名空间、存储、网络策略和入口路径，使平台团队可以用基础设施即代码的方式扩展与审计。

意义与影响

Palana 的价值不在于发明某一种新的模型防护算法，而是承认智能体行为本身具有非确定性，并用确定性的基础设施边界去约束它。对于企业而言，这是一种更现实的安全路线：不假设模型永远遵守指令，也不把密钥和网络访问权完全交给运行中的智能体。

这种设计也说明，智能体平台的竞争点正在从“能否调用工具”转向“能否安全、可审计、可回收地调用工具”。随着更多企业部署代码助手、自动化运维代理和业务流程智能体，身份隔离、出口治理、密钥代理和审计追踪可能会成为生产级智能体平台的标配能力。

不过，Palana 仍主要解决基础设施层面的风险控制。提示词注入、工具误用、目标偏移等问题不会因此消失，而是被限制在更小的权限与网络范围内。对企业来说，下一步挑战是在平台护栏之外，继续结合评测、权限设计、人工审批和任务分级，形成完整的智能体治理体系。

来源：InfoQ 中文