Tigera Introduces Lynx, a Unified Control Plane for Kubernetes‑Native AI Agents
The first Kubernetes AI agent control plane is here.
Tigera, best known for backing the open-source Calico networking and security stack for Kubernetes, is pushing beyond traditional container security with the launch of Lynx. This is a unified control plane designed to manage Kubernetes‑native AI agents at scale.
While there are other programs that attempt to oversee Kubernetes AI agents, such as ClawManager, Agent Substrate, and Agent Control Plane (ACP), Lynx appears to be the most mature of them. To be exact, Lynx is a Kubernetes‑native, horizontally scalable control plane. It sits in the path of every agent→tool/agent→LLM call. For identity and access management (IAM), it ties into Entra ID/Okta/SPIFFE. It enforces identity, posture and policy, and detects anomalies using eBPF/LSM across Kubernetes clusters. Finally, for policy management, it uses the open-source policy language and evaluation engine, Cedar.
What that means in practice is Lynx is designed to, drum-roll please:
- Discover and inventory AI agents running across Kubernetes clusters.
- Attach fine‑grained policies that govern what each agent can access and under what conditions.
- Provide real‑time visibility into agent behavior, interactions, and data flows.
- Enforce security controls consistently across multi‑cluster and multi‑cloud environments.
Because Lynx is built for Kubernetes‑native agents, Tigera is aiming for a deployment model that aligns with existing platform practices rather than forcing a new silo. Lynx is meant to integrate with your existing Kubernetes clusters on major cloud providers and on‑premises. It’s also built, as you’d expect, to work with Calico-secured environments for consistent network policy and microsegmentation. The platform is designed to operate with popular AI runtimes, frameworks, and model gateways that developers are already using.
This approach is likely to appeal to platform engineering and security teams that want to integrate AI into their existing Kubernetes and cloud-native application protection platform (CNAPP) strategies, rather than managing a parallel AI infrastructure stack.
Why would you need it? Tigera CEO, Ratan Tipirneni, explained in a blog post, “AI agents broke the assumptions security stacks were built on. The enterprise security tooling most organizations run was designed for workloads that are deterministic. A service does roughly the same thing today that it did yesterday. … AI agents don’t work that way. They’re autonomous and non-deterministic. An agent acts on behalf of a user, reaches for whatever tool, LLM, or other agent it needs, carries a delegation chain, and reads untrusted input as it goes. The same agent can take a different path every time it runs.”
That’s really scary when you think about it. To address these concerns, Tipirneni wrote, Lynx deploys a central registry that catalogs every agent. Shadow agents are flagged and quarantined, and any agent’s actions can be reconstructed end-to-end through OpenTelemetry traces.
Lynx also continuously evaluates every agent against a baseline and surfaces drift and over-permissions the moment they appear, with per-agent sandboxing and pre-built compliance packs mapping to GDPR, HIPAA, SOC 2, and financial services requirements.
The control plane also gives every agent a verifiable cryptographic identity by integrating with your identity provider (Entra ID, Okta) or via SPIFFE/SPIRE, with no shared secrets. Instead, long-lived API keys give way to short-lived, tightly scoped, auto-rotated tokens. A JSON Web Token (JWT) is minted for each hop of a multi-agent workflow. This way, credentials are scoped to a single hop rather than passed around.
Lynx authorizes every transaction and enforces policy at the gateway. A single default-deny policy governs LLM, MCP, and agent access using the Cedar policy language, evaluated before any call executes. A misbehaving agent can be quarantined instantly, and a high-stakes call can be routed to a human—again, with no agent code changes. Lynx also provides the other controls needed to secure and manage agents, including prompt-injection defenses, rate limiting, guardrails, budgets, spend limits, custom webhooks, MCP multiplexing, aggregation and session management.
Finally, Lynx monitors abnormal behavior. It uses eBPF and LSM to watch every syscall, network call, and file access in the kernel. That way, it can catch credential theft and lateral movement even when an action technically passes policy.
By building Lynx as a Kubernetes‑native control plane, Tigera is betting that enterprises want AI agents to follow the same operational patterns as other cloud‑native applications: declarative configuration, GitOps workflows, and policy‑as‑code. That seems like a very safe bet to me.


