Tigera 推出 Lynx，一款用于 Kubernetes 原生 AI 代理的统一控制平面

# Tigera 推出 Lynx，面向 Kubernetes 原生 AI Agent 的统一控制平面 来源：https://cloudnativenow.com/features/tigera-introduces-lynx-a-unified-control-plane-for-kubernetes%E2%80%91native-ai-agents/ ***首个 Kubernetes AI Agent 控制平面来了。*** Tigera（https://www.tigera.io/）以支持 Kubernetes 的开源 Calico（https://www.tigera.io/project-calico/）网络与安全栈而闻名，如今正通过推出 Lynx（https://www.tigera.io/tigera-products/lynx/）突破传统容器安全的边界。这是一个统一控制平面，旨在大规模管理 Kubernetes 原生 AI Agent。 虽然有其他项目也在尝试监管 Kubernetes AI Agent，例如 ClawManager（https://clawmanager.ai/）、Agent Substrate（https://www.solo.io/blog/agent-substrate-powers-kubernetes-agents-with-kagent）以及 Agent Control Plane (ACP)（https://github.com/humanlayer/agentcontrolplane），但 Lynx 似乎是其中最为成熟的一个。确切地说，Lynx 是一个 Kubernetes 原生、可水平扩展的控制平面。它位于每一次 agent→tool/agent→LLM 调用的路径中。对于身份与访问管理（IAM），它接入 Entra ID/Okta/SPIFFE。它强制执行身份、态势和策略，并使用 eBPF/LSM 跨 Kubernetes 集群检测异常。最后，在策略管理方面，它使用了开源策略语言和评估引擎 Cedar（https://www.cncf.io/blog/2025/03/28/cedar-a-new-approach-to-policy-management-for-kubernetes/）。 这在实际中意味着 Lynx 旨在——请注意听—— - 发现并盘点跨 Kubernetes 集群运行的 AI Agent。 - 附加细粒度策略，规定每个 Agent 可以访问什么以及在什么条件下访问。 - 提供 Agent 行为、交互和数据流的实时可见性。 - 在跨集群、跨云环境中一致地强制执行安全控制。 由于 Lynx 是为 Kubernetes 原生 Agent 构建的，Tigera 旨在采用一种与现有平台实践相一致的部署模式，而不是强制引入新的孤岛。Lynx 可集成到你在主流云提供商以及本地环境中的现有 Kubernetes 集群中。此外，不出所料，它还可以与 Calico 保护的环境配合使用，以实现一致的网络策略和微分段。该平台设计为与开发者已经在使用的流行 AI 运行时、框架和模型网关协同工作。 这种方法很可能吸引平台工程和安全团队，他们希望将 AI 集成到现有的 Kubernetes 和云原生应用保护平台（CNAPP）（https://www.fortinet.com/resources/cyberglossary/cnapp）策略中，而不是管理一套并行的 AI 基础设施栈。 为什么需要它？Tigera 首席执行官 Ratan Tipirneni 在一篇博文中解释道：“AI Agent 打破了安全栈所依赖的假设。（https://www.tigera.io/blog/why-we-built-lynx-bringing-control-to-the-age-of-ai-agents/）大多数企业运行的安全工具是为确定性的工作负载设计的。一个服务今天做的事情与昨天大致相同……AI Agent 不是这样工作的。它们是自主且非确定性的。一个 Agent 代表用户行动，获取它需要的任何工具、LLM 或其他 Agent，携带委托链，并在过程中读取不受信任的输入。同一个 Agent 每次运行时可能走不同的路径。” 这确实让人细思极恐。为了解决这些问题，Tipirneni 写道，Lynx 部署了一个中央注册表，对所有 Agent 进行编目。影子 Agent 会被标记并隔离，任何 Agent 的行为都可以通过 OpenTelemetry（https://opentelemetry.io/）追踪进行端到端重建。 Lynx 还会持续根据基线评估每个 Agent，一旦出现漂移和过度授权就立即显现，并提供每个 Agent 的沙箱隔离以及预构建的合规包，映射到 GDPR、HIPAA、SOC 2 和金融服务要求。 该控制平面还为每个 Agent 提供可验证的加密身份，通过与你的身份提供商（Entra ID、Okta）集成，或通过 SPIFFE/SPIRE 实现，无共享密钥。取而代之的是，长期存在的 API 密钥被短期、严格限定范围、自动轮换的令牌所取代。每个多 Agent 工作流的跳点都会生成一个 JSON Web Token（JWT）。这样，凭证被限定在单个跳点，而不是到处传递。 Lynx 对每一笔交易进行授权，并在网关上执行策略。一个默认拒绝的策略使用 Cedar 策略语言管理 LLM、MCP 和 Agent 的访问，在任何调用执行前进行评估。行为异常的 Agent 可以立即被隔离，高风险调用可以路由到人工处理——同样无需更改 Agent 代码。Lynx 还提供了保护和管理 Agent 所需的其他控制功能，包括提示注入防御、速率限制、护栏、预算、消费限额、自定义 webhook、MCP 多路复用、聚合和会话管理。 最后，Lynx 监控异常行为。它使用 eBPF 和 LSM 在内核中监视每一次系统调用、网络调用和文件访问。这样，即使某个操作在技术上通过了策略，它也能捕捉到凭据窃取和横向移动。 通过将 Lynx 构建为 Kubernetes 原生控制平面，Tigera 押注于企业希望 AI Agent 遵循与其他云原生应用相同的运维模式：声明式配置、GitOps 工作流和策略即代码。在我看来，这似乎是一个相当稳妥的赌注。