DEV Community: Tigera Inc

Introducing Tigera Lynx

Alister Baroi — Fri, 19 Jun 2026 17:45:47 +0000

Today we're announcing the general availability of Tigera Lynx, a unified control plane for Kubernetes-native AI agents.

Lynx gives enterprises a single place to find every agent in their Kubernetes estate, tighten posture, assign a sandbox, give each agent a cryptographic identity, enforce policy on every action it takes, audit what agents actually do, and detect anomalous behavior — without changing a line of agent code.

It sits in the path of every agent call (agent-to-agent, agent-to-tool, and agent-to-LLM) to authenticate, authorize, mediate, and audit each one. It plugs into the tools you already run, including your identity provider (Entra ID, Okta) or SPIFFE/SPIRE and your existing observability systems, and is built on open standards rather than proprietary lock-in.

Built on a decade of deep Kubernetes network security experience, Lynx is generally available today 👉 https://www.tigera.io/tigera-products/lynx/

How Lynx Works: A Technical Walkthrough

Alister Baroi — Thu, 18 Jun 2026 17:19:30 +0000

We launched Lynx this week. Instead of restating the pitch, I want to explain how it’s built and why we made the architectural choices we did. If you run Kubernetes and you’re starting to put AI agents on it, this is roughly the system you’d end up designing yourself.

Lynx is a control and data plane for all agentic AI traffic, providing a registry, gateway, audit, authentication with token exchange, policy enforcement, agent sandboxing, shadow agent discovery, and advanced AI capabilities such as red team agent and a guardian supervising agent to keep your agents on track. Lynx is single control point in the path of every agent call – agent-to-agent, agent-to-MCP, agent-to-LLM. Every call is authenticated, authorized against policy, and recorded, with no changes to agent code.

The constraints we started from

Four principles shaped the design:

No agent code changes. Governance has to be applied by the platform, not adopted as a library. If it requires a code change, it won’t land uniformly – and uniformity is the entire point.
No new database in the control plane. The source of truth is the Kubernetes API server and the data model is custom resources – there’s no separate datastore to run, back up, and secure. (Telemetry is the one thing that needs a column store at scale; that’s kept separate and is bring-your-own.)
Don’t reinvent the data plane. Proxying agentic protocols – MCP, A2A, streaming LLM traffic – well is a full-time job. We wanted to own the policy, not the proxy.
Catch what doesn’t opt in. A governance layer that only sees traffic routed through it is blind exactly where the risk is. We needed an out-of-band way to find the agents nobody registered.

The data model

Lynx is Kubernetes-native to the core: its entire vocabulary is a small set of custom resources – Agent, MCPServer, LLMProvider, ServiceIdentity, and Policy – stored in the Kubernetes API itself. There’s no Lynx database; every record is something you can manage, GitOps, and RBAC like anything else in your cluster. The registry is a thin API in front of these resources. It records agents; it doesn’t run them.

Two ideas matter throughout. First, workload identity is the join key that ties a running pod to its registry record. Second, an agent becomes governed by two independent acts – it runs with an identity, and someone registers it – which means registration can happen in CI/CD at deploy time while the workload itself stays unaware of Lynx.

Identity: reuse what you already trust

A workload proves who it is with one of two mechanisms – it’s one or the other, and which one is recorded in the workload’s registration:

SPIFFE/SPIRE for mTLS workload identity, where private keys never leave the pod.
OIDC for tokens from your existing IdP (Entra ID, Okta, Keycloak). The binding is the issuer/subject pair you record at registration time. Because the in-cluster Kubernetes API server is itself an OIDC issuer, this path also covers plain Kubernetes ServiceAccount tokens – a pod’s projected token simply is its identity, with nothing to mount beyond what Kubernetes already gives every pod.

You can register more than one identity on an agent – which turns an IdP migration into a config change rather than a cutover – but any single call authenticates by exactly one. Human access to the dashboard uses the same IdP over OIDC, kept distinct so a person’s token is never mistaken for an agent’s. And not every caller is an agent: a ServiceIdentity lets a plain service or human-operated client be governed by the same machinery.

The validation pipeline behind all of this is deliberately strict and shared by every component: issuers are matched against a per-service allow-list (there is no “any issuer” mode), tokens are signature-verified and bound to an audience, and keys rotate automatically. The result is that agents reuse identity you already trust, rather than living in a parallel, ungoverned credential system.

One gateway for A2A, MCP, and LLM

The framing that matters most: Lynx is a single consolidated gateway for all three classes of agentic traffic. Today these tend to be governed by three different things – a service mesh for agent-to-agent, a bespoke proxy or SDK wrapper for MCP, an egress gateway or nothing at all for LLM calls. That fragmentation is how you end up with three identity models, three policy languages, and three audit trails nobody can correlate.

Lynx collapses them into one control point with one identity model, one policy language, and one audit trail. Agents, MCP servers, and LLM providers are all first-class objects with their own governed routes, and every call – whatever its kind – is authenticated, authorized, and recorded the same way.

The LLM path has a property teams feel immediately: the gateway holds the provider credential, the agent never does. Upstream API keys live in one governed place, rotate centrally, and never sit in agent pods – and when a provider needs no upstream auth, the gateway strips the caller’s credential so a Lynx-issued token can’t leak to a third party.

The data plane: drive the proxy, don’t fork it

The proxy in the request path is agentgateway, the open-source Rust proxy purpose-built for LLM/MCP/A2A traffic. We run it unmodified and drive it the way Envoy is driven – over xDS. Our control plane watches the custom resources and compiles them into the proxy’s native configuration; the proxy itself never sees a Lynx resource, has no Kubernetes access, and holds no cluster privileges.

That decoupling is deliberate, and it buys four things:

Blast radius – a malformed registration drops one route; it can’t corrupt the proxy.
Least privilege – the component on the wire has no API-server reach.
Schema freedom – we evolve our data model without touching the proxy.
Hot reconfiguration – register an agent and its route is programmed live, no restart.

The customer who already likes agentgateway gets it as-is, with Lynx’s governance layered on through the same open extension points they already trust – no proprietary lock-in at the data path.

The decision point: policy in the path, credentials minted per hop

Before the proxy forwards a request, it calls back into Lynx’s decision point, which runs the same sequence every time: authenticate the caller, validate the destination’s requirements, and evaluate policy in Cedar – a formally-grounded language, default-deny, with LLM, MCP, and agent access all expressed in one model. Only on an allow does the request proceed.

The property I care most about is what happens on allow: t he gateway mints a fresh, short-lived credential scoped to that one hop. When Agent A calls Agent B, A never holds a credential for B – it proves only its own identity, and the gateway issues a token good for exactly that destination, for a couple of minutes. A leaked token is useless beyond a single hop: no shared secrets, no standing keys, no blast radius.

For multi-step chains – A calls B, which calls a tool – this extends into proper on-behalf-of delegation built on RFC 8693 token exchange. An agent presents the token it already has and asks for a destination; Lynx validates it, checks policy at the moment of issuance (so an unauthorized hop never even produces a credential), and mints a destination-scoped token carrying the original subject. The payoff is threefold: agents stay IdP-agnostic (one endpoint, one credential), delegation is genuine and auditable end-to-end rather than just the last leg, and least privilege is enforced by construction. To the rest of your estate, Lynx looks like an ordinary OAuth2 provider – standards in, standards out.

Catching what routes around the gateway

A gateway only governs traffic that flows through it – and the agents that don’t route through it are exactly the ones worth finding. So Lynx watches at a layer the workload can’t bypass or tamper with: the kernel, via eBPF, deployed as a per-node agent that needs no instrumentation of the workloads it observes.

The first signal is LLM egress. Any workload calling a provider does a TLS handshake; Lynx observes that in the kernel, attributes it to a pod, and checks whether that pod is a registered agent – classifying each as registered, a shadow agent , or unattributable. This is the backstop for the LLM path specifically: even an agent that calls a provider directly, bypassing the gateway entirely, still does a handshake the kernel sees. The gateway governs what routes through it; this finds what goes around it.

Agent sandboxing

The same vantage point is also an enforcement point. Lynx can run each agent inside a tailored kernel-level sandbox – a per-workload syscall policy that constrains which operations the pod may perform – rather than letting it act with the full ambient authority of its pod. Notably, those policies are written in the same Cedar language as request authorization and compiled down to run in the kernel, so one policy model drives both the request path and the sandbox. Because enforcement lives in the kernel, a flagged or shadow agent is contained immediately and “unbypassably”, rather than merely alerted on.

This is also where the platform is heading next: a per-agent behavioral baseline over kernel-level activity, with anomaly detection for the cases a request-time policy can’t catch – credential theft, lateral movement, an agent doing something it never has – and agent-specific threats such as memory and context poisoning. Policy governs intent; this layer is about what actually happens.

Tracing, audit, and compliance

Everything emits OpenTelemetry, and the design choice that pays off here is that the gateway’s authorization decisions and the agents’ own reasoning – their LLM and tool calls – land in the same distributed trace. You don’t get one system for “what the agent did” and a separate one for “what the platform allowed”; you get a single, correlated timeline of each interaction.

That timeline is what turns governance into an audit story. Every call carries who the caller was, on whose behalf it acted, which policy permitted it, and what the decision was – and because each hop is independently authorized and freshly credentialed, the chain is attributable end-to-end , not just at the edge. Alongside the request traces, every change to the system itself – a registration, a policy edit – is recorded as an audit event capturing the actor, the operation, and the exact before-and-after. Together these are the reproducible, cryptographically attributable record that incident response and auditors ask for, and that frameworks such as SOC 2, HIPAA, GDPR, and financial-services regimes require you to produce on demand – without a separate logging project bolted on after the fact.

Traces and audit records flow into ClickHouse (bring-your-own), which powers the dashboard’s inventory, policy editor, audit search, agent-to-agent traffic graph, and shadow-agent views.

Driving Lynx: dashboard, CLI, and MCP

Everything in Lynx is an API over Kubernetes resources, so there are three ways to operate it – all thin clients over the same control plane:

The dashboard. A web UI for the people who live in this day to day – agent and MCP inventory, a Cedar policy editor, the agent-to-agent traffic graph, audit search, and trace exploration. It’s a Next.js and React app that renders agent execution traces with agent-prism, so a multi-hop, multi-agent interaction reads as a single timeline.
lyctl. A single Go CLI for everything scriptable – registering agents and MCP servers, authoring and testing policies, and standing up a complete demo environment in one command. It’s the natural fit for CI/CD, where registration belongs.
MCP. Lynx ships its own Model Context Protocol server that exposes the governance operations – list and register agents, write policies, inspect audit traces – as MCP tools. So you can drive Lynx straight from an AI assistant like Claude or Cursor : “register this agent,” “which agents can reach the payments MCP server?”, “what changed in policy yesterday?” The platform that governs agents is itself operable by one.

Built on open standards

We deliberately built Lynx on proven, open technology rather than inventing a parallel stack – it’s why it drops into an existing cluster and speaks the protocols your tooling already speaks:

Kubernetes-native – the entire data model is custom resources in the Kubernetes API; it installs as a single Helm chart and runs no database of its own.
Identity – SPIFFE/SPIRE for workload mTLS, and OIDC/OAuth2 with your existing IdP (including Kubernetes ServiceAccount tokens). Per-hop delegation uses RFC 8693 token exchange, and tokens are verified through standard JWKS.
Policy – authorization is expressed in Cedar, a formally-grounded, open policy language – the same language whether it’s evaluated in the request path or compiled into the kernel.
Data plane – the open-source agentgateway proxy, driven dynamically over xDS and integrated through the standard ext-authz contract, with native fluency in MCP and A2A.
Visibility and enforcement – eBPF for kernel-level discovery and sandboxing, with no instrumentation of the workloads themselves. Observability – OpenTelemetry end to end, stored in ClickHouse.

The throughline: Lynx contributes the governance layer – identity binding, Cedar policy, per-hop credentials, the agent registry – and bridges to everything else through open, standard contracts. No proprietary lock-in at the parts that matter most.

How it installs

Lynx is a single Helm chart on any conformant Kubernetes cluster. The minimal install is the registry and the gateway; the data plane, the policy decision point, the kernel-level detector, the telemetry pipeline, and the UI are each switched on as you need them. The most revealing first step is to turn on discovery and watch what’s already talking to LLM providers across your fleet – for most teams, that first scan surfaces agents nobody knew were running.

Explore our product page to see Lynx in action.

The post How Lynx Works: A Technical Walkthrough appeared first on Tigera – Creator of Calico.

Why We Built Lynx: Bringing Control to the Age of AI Agents

Alister Baroi — Wed, 17 Jun 2026 13:00:22 +0000

For a decade, one idea has guided everything we’ve built at Tigera: How do you secure a dynamic system with a lot of moving parts that is changing rapidly, with a programmatic approach? Calico has applied that idea for Global 2000 companies running the largest Kubernetes platforms in the world, securing tens of millions of mission-critical transactions every day. Today I’m excited to announce the next chapter of that work: Lynx, a unified control plane for Kubernetes-native AI agents.

This enables us to apply our deep knowledge of Kubernetes, eBPF, and our expertise in building scalable and highly performant systems to solve the security challenges that come with deploying AI Agents. Before I explain how Lynx addresses these challenges, it’s worth being clear about why AI agents are so hard to secure in the first place.

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. You can reason about its behavior, define what it’s allowed to touch, and trust that a valid credential maps to expected actions.

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. A valid credential no longer guarantees good behavior, it just guarantees the door opens. And every time a new agent or tool comes online or there are changes in the platform, the blast radius shifts again.

This leaves three teams staring at the same problem from three different angles, and none of them able to give a confident answer. The AI team wants to experiment with the latest technology and move fast. Platform engineering teams are measured on how fast they delpoy, but can’t prove the platform is actually under control. And the security team is asked to approve agents whose posture they have no real way to defend. Everyone needs to be accountable, but no one has the right controls.

Lynx closes that gap.

What Lynx does

Lynx sits in the path of every agent call, whether agent-to-agent, agent-to-tool, or agent-to-LLM, and authenticates, authorizes, mediates, and audits each one. It does this without changing a line of agent code, and it plugs into the tools you already run: your identity provider (EntraID, Okta) or SPIFFE/SPIRE, and your existing observability systems. It’s built on open standards, not proprietary lock-in.

One control plane brings together five capabilities that, until now, teams have been trying to stitch together by hand.

It starts with discovery. A central registry catalogs every agent, including its owner, its purpose, and its version, while eBPF-powered auto-discovery finds the agents nobody registered. Shadow agents are flagged and quarantined, and any agent’s actions can be reconstructed end-to-end through OpenTelemetry traces.

From there, Lynx manages posture. AI-CSPM 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. A Red Team Agent continuously probes for weaknesses in posture and misconfigurations.

It gives every agent a real identity. Each one receives a verifiable cryptographic identity through integration with your identity provider (EntraID, Okta) or through SPIFFE/SPIRE, with no shared secrets. Long-lived API keys give way to short-lived, tightly scoped, auto-rotated tokens. A JWT token is minted for every hop of a multi-agent workflow so credentials are scoped to a single hop rather than handed 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 that you need to secure and manage your agent: prompt injection, rate limiting, guardrails, budgets, spend limits, custom webhooks, MCP multiplexing, and aggregation and session management.

Lastly, Lynx watches for anomalous behavior at a layer agents can’t tamper with. eBPF and LSM observe every syscall, network call, and file access at the kernel, catching credential theft and lateral movement even when an action technically passes policy. This produces a forensic audit trail, and a Guardian Agent detects anomalous behavior and quarantines suspicious agents.

Security & visibility for Kubernetes-native AI

When I look at AI agents, I don’t see a new category that requires us to start over. I see the next class of workload that is autonomous, distributed, and increasingly embedded in critical business processes. I see AI agents actively interacting with traditional applications and databases running in containers/VMs, and the need for a unified solution that can secure this traffic. The discipline is the same one we’ve practiced from the start: give every workload a verifiable identity, evaluate every action against policy before it runs, and observe behavior closely enough to catch what policy alone can miss. And do this in a manner that is agnostic of the underlying infrastructure so that we can help you avoid platform lock-in and the risk of a price hike that goes with it.

As our CTO Peter Kelly puts it, because we watch behavior with eBPF and LSM at the kernel, we can detect an agent going wrong even when it carries a valid credential—and produce a reproducible audit trail to prove it. That’s the difference between hoping an agent behaves after acquiring a valid token, and knowing what it did.

AI agents are going to keep multiplying across your estate. The question isn’t whether you’ll run them. It’s whether you can see them, govern them, and answer for them. With Lynx, you can.

Lynx is generally available today. It scales horizontally on a Kubernetes-native architecture with no per-call overhead, and it’s already running in production at some of the world’s largest banks.

Explore our product page to see Lynx in action.

The post Why We Built Lynx: Bringing Control to the Age of AI Agents appeared first on Tigera – Creator of Calico.

Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform

Alister Baroi — Wed, 10 Jun 2026 20:19:08 +0000

The first post in this series argued that AI agent governance hasn’t kept pace with deployment. The second laid out the five pillars of accountability, and what is required. The third walked through why network policies, API gateways, MCP/A2A protocols, DIY security patterns, and Role-based Access Control (RBAC) each leave critical accountability gaps.

So what does good look like?

The five pillars define what AI agent accountability requires. The principles below define how a governance platform should deliver it. These are the architectural principles your team should evaluate any AI agent governance solution against, whether you build it, buy it, or assemble it from open-source components.

If a vendor pitches you a governance platform that fails any of these five, walk away.

What are the five principles of an accountable AI agent network?

Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.

Default-deny: No agent communicates unless a policy explicitly permits it.
Attribute-based policy: Policies reference agent attributes, not agent names.
Zero-trust identity: Every request authenticated, every identity verified.
Audit by design: Every interaction produces a structured, correlated trace automatically.
Kubernetes-native: The platform extends your existing infrastructure rather than replacing it.

Each principle below explains why it matters and what a passing solution looks like.

Use the five principles as a checklist when evaluating any governance platform. Fail any one, and the platform is one missing principle away from security theater.

Principle 1: Default-deny

No agent communicates with any other agent unless explicitly permitted by policy.

This is the only safe starting posture for accountability. If your governance layer defaults to allowing communication and only blocks what’s explicitly forbidden, every interaction you didn’t anticipate is ungoverned, and you can’t be accountable for what you didn’t authorize.

Default-deny flips the model: nothing is allowed until a policy explicitly permits it. Every allowed interaction is intentional, traceable, and auditable. New agents are isolated by default until policies are written to grant them access, which is exactly the behavior you want in a governed network.

Default-deny seems restrictive, but in practice it’s liberating. Your security team doesn’t have to anticipate every possible _ bad _ interaction. They only have to define the good ones.

Principle 2: Attribute-based policy

Policies should reference agent attributes, not agent names.

Hardcoding agent names in policies creates a governance system that breaks every time you add or rename an agent. It’s the equivalent of maintaining a firewall with hundreds of IP-based rules instead of using network segments.

Attribute-based policies reference properties like capabilities, risk levels, team ownership, and environment tags. Instead of “Agent-Finance-v2 can call Agent-Compliance-v3,” the policy says “Agents with capability=financial-analysis can call agents with capability=compliance-query.”

This approach has a powerful scaling property: when a new agent registers with matching attributes, existing policies apply automatically. The governance grows with the agent network, not against it. A team deploying a new agent doesn’t need to file a ticket to update allow-lists, they describe the agent’s attributes at registration time, and the policy engine handles the rest.

This is the principle that separates a security model that survives at 10 agents from one that survives at 1,000.

Principle 3: Zero-trust identity

Every request authenticated. Every identity verified. Trust nothing by default.

Agent networks are susceptible to the same identity threats as any distributed system: spoofing, replay attacks, credential theft. But agents add an unique challenge: they operate on behalf of the users. This means both the workload identity (is this actually the agent it claims to be?) and the user identity (on whose behalf is this agent acting?) must be verified.

A governance platform should support dual authentication : cryptographic workload identity (proving the agent is genuine) and token-based user identity (establishing who triggered the action). Both identities should be available for policy evaluation and audit logging.

Short-lived credentials, automatic rotation, and cryptographic verification should be standard, not optional add-ons. Static API keys and long-lived tokens are liabilities in an agent network; compromised credentials can enable automated lateral movement at machine speed.

Principle 4: Audit by design, not by afterthought

Every interaction produces a structured, correlated trace automatically.

If your team has to add logging after the fact, you’ve already lost accountability. Audit records should be a byproduct of the governance layer’s enforcement , not a separate system bolted on later.

When the governance layer evaluates a policy and permits (or denies) an agent interaction, that evaluation is the audit record. It captures: who called whom, what policy was evaluated, what the decision was, what attributes matched, and when it happened. These records should be:

Structured (not free-text logs),
Correlated across multi-hop chains (using distributed trace IDs),
Queryable by agent, by policy, by time range, by outcome.

The practical implication: the audit trail should be a first-class product of the governance platform, not a configuration option. If you have to enable it, someone will forget. If it’s built in, it’s always there.

Principle 5: Kubernetes-native

The governance layer should work with your existing infrastructure, not replace it.

Enterprises have invested heavily in Kubernetes, Helm charts, GitOps pipelines, RBAC, namespaces, and observability stacks. An AI agent governance platform that requires a separate control plane, its own deployment model, or a proprietary orchestration layer will face adoption resistance and operational overhead.

The governance platform should be deployable via Helm, manageable via CRDs, observable (e.g. via Prometheus or OpenTelemetry), and compatible with existing identity infrastructure (OIDC providers, SPIFFE/SPIRE). It should feel like a natural extension of the Kubernetes platform, not a foreign system that happens to run on it.

This isn’t just about developer experience. It’s about operational sustainability. If the governance platform requires specialized skills your platform team doesn’t have, it will become a bottleneck instead of an enabler.

How the principles reinforce each other

These five principles aren’t independent. They reinforce each other:

When evaluating governance solutions, test each principle:

If a solution requires you to default to allowing communication and only block specific interactions, it fails Principle 1.
If it requires naming agents in policies, it fails Principle 2.
If it relies on static API keys or long-lived tokens, it fails Principle 3.
If it doesn’t produce correlated audit trails automatically, it fails Principle 4.
If it needs its own control plane outside Kubernetes, it fails Principle 5.

The right solution delivers all five. Because accountability requires nothing less.

Frequently asked questions

What’s the difference between default-deny and zero-trust?

Default-deny is a policy posture — no communication unless explicitly permitted. Zero-trust is an identity posture — every identity must be verified, every time. They reinforce each other but aren’t interchangeable. A platform with zero-trust identity but default-allow policy is still ungoverned.

Why does Kubernetes-native matter for AI agent accountability?

Because adoption is the difference between a governance platform that works and one that gets shelved. If your platform team has to learn a new control plane, run a parallel deployment pipeline, or operate a proprietary policy engine, the governance layer becomes a bottleneck — and ungoverned agents start showing up because the official path is too slow.

Can I build this myself with SPIFFE, OPA, and OpenTelemetry?

Technically yes. Practically, you’ll spend 6–12 months on the integration glue, audit correlation across multi-hop chains, dual identity verification, attribute-based policy modeling, and the human oversight surface. We covered the build-vs-buy tradeoff in post 3 of this series.

Are these principles specific to Tigera Lynx?

No. These are architectural principles for any accountable agent governance platform — whether commercial, open source, or homegrown. We use them ourselves to evaluate Lynx, and we’d encourage you to use them to evaluate every option you consider.

Key takeaways

Default-deny is the only safe starting posture. Anything else leaves ungoverned interactions.
Attribute-based policy is the principle that lets governance scale past 100 agents.
Zero-trust identity must verify both the workload (is this the right agent?) and the user (on whose behalf is it acting?).
Audit by design means audit records are a byproduct of enforcement, not a separate system.
Kubernetes-native ensures the platform actually gets adopted instead of bypassed.

Get the strategic guide for accountable AI agents

We wrote a strategic guide, Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale, that walks through these principles in depth, including a side-by-side comparison of common governance approaches and how they score against each principle.

Get the strategic guide for accountable AI agents →

The post Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform appeared first on Tigera – Creator of Calico.

Multi-Layer Policy for Securing AI Agents

Alister Baroi — Wed, 03 Jun 2026 18:58:09 +0000

As part of our work at Tigera building products that create secure runtime environments for enterprise agents at scale in the real world, one small part of this puzzle I think about a lot is policy, and runtime enforcement of policy, and how to create a comprehensive secure runtime, configured from one place. The more companies we talk to trying to lock down and secure these platforms at runtime, the more I believe AI Agent security needs policy in multiple places, not just one (e.g., not just at the gateway layer), and ideally expressed in the same policy language.

At the L7 gateway layer, every agent call is observable: who is calling, what they are calling, what attributes both sides carry, what the requested action is. This is where you decide whether an agent should be permitted to talk to a particular MCP server, invoke a particular tool, delegate to another agent, or call a particular LLM. The atoms of policy here are identity, action, resource, and context.

At the agent runtime layer, or kernel layer in a container, what the agent does inside its own runtime is observable: syscalls, file access, library loads, network connections that bypass the brokered channel. This is where you decide whether the agent can read a file, open a socket, spawn a subprocess, or load a library. The atoms of policy here are processes, paths, file descriptors, and system calls.

Both layers are necessary. The gateway alone cannot constrain what an agent does inside its runtime once it holds a token. The kernel alone cannot reason about identity, delegation, or multi-hop intent. Building policy at one and not the other leaves a category gap.

The architectural choice that makes this work in practice is using one policy language for both. We use Cedar at the gateway and interpret and translate Cedar to eBPF policy for the kernel: same policies, two enforcement points, one place to author and review.

Policy at the gateway: enforcing agent intent

The gateway sees intent. It is the right place to enforce who can talk to whom, under what conditions, with what level of human oversight.

A Cedar policy that constrains which agents can invoke which tools:

permit (
  principal in Group::"finance-agents",
  action == Action::"invokeTool",
  resource in ToolSet::"finance-readonly"
) when {
  principal.risk_level == "low" &&
  context.delegation_depth <= 3
};

This policy expresses several things that are hard to model in RBAC or in a network policy. The principal is identified by group membership but constrained by attribute (risk_level). The resource is a typed set of tools. The condition includes a check on delegation depth; agents three hops deep in a delegation chain are refused even if they pass every other check.

The gateway layer naturally enforces delegation rules, per-hop token issuance with scope reduction, agent-to-MCP tool authorization, agent-to-LLM constraints, human-in-the-loop hooks for high-stakes actions, and attribute-based decisions across all of these.

What the gateway cannot do is constrain what happens after it issues a token. Once the agent has the credential, the kernel is the only layer that sees what the process actually does with it.

Policy at the kernel: constraining agent behaviour

The kernel sees behaviour. It is the right place to enforce what an agent process is allowed to do at the operating system level, regardless of what tokens it holds.

A baseline sandbox for an agent workload, expressed conceptually in the same Cedar policy model and compiled to BPF programs at runtime:

permit (
  principal in AgentClass::"data-analyst",
  action in [Action::"readFile", Action::"writeFile"],
  resource is FilePath
) when {
  resource.path like "/workspace/analyst-*" ||
  resource.path == "/var/run/secrets/analyst-key"
};
forbid (
  principal in AgentClass::"data-analyst",
  action == Action::"connectNetwork",
  resource is NetworkDestination
) unless {
  resource.host in DestinationSet::"approved-llm-endpoints" ||
  resource.host == "lynx-gateway.internal"
};

The compilation target is BPF LSM hooks, cgroup network hooks, and file access enforcement at the inode boundary. When the agent process steps outside what the policy permits, the kernel refuses the operation – EPERM for the syscall, ECONNREFUSED for the network connection, ENOENT for the file access. The agent gets the same error it would get for any prohibited operation, regardless of what credentials it holds.

The kernel layer naturally enforces file access boundaries, network egress restrictions, syscall whitelisting, library load constraints, and process-spawn limits. The same observation pipeline that feeds enforcement also feeds threat detection.

What the kernel cannot do is reason about why an action is being attempted. It sees a connect() system call. It does not know whether the call is part of a legitimate multi-hop delegation that the gateway already authorized. That context only exists at the L7 layer.

The dual-layer architecture

The architectural integration matters as much as either layer in isolation. Cedar policies authored once, evaluated at the gateway, compiled to BPF for kernel enforcement. The compilation is not magical—only the substrate-relevant subset of Cedar policies compiles. The rest stay at the gateway. Either way, security teams write Cedar; the runtime decides which layer is the right one to enforce at.

This integration is what makes the dual-layer approach operationally sustainable. Without one policy language, you end up with two policy stores, two review processes, two engineering teams, and inevitable divergence between what the gateway permits and what the kernel allows. With Cedar at both layers, the policy you wrote is the policy that gets enforced everywhere.

Why single-layer policy isn’t enough for AI agent security

Policy at the gateway alone defends against unauthorized callers and out-of-scope actions. It does not defend against a compromised agent that has a legitimate token and uses it to do things outside its intended behaviour, like read credential files, exfiltrate data through side channels, and escalate privilege inside its runtime.

Policy at the kernel alone defends against process-level misbehaviour. It does not understand identity or delegation, cannot reason about whether a network connection is part of a legitimate multi-hop chain, and has no way to enforce human-in-the-loop approval flows.

Combined, the two layers cover the threat model that either layer alone misses. A compromised agent with a legitimate token can still call out through the gateway, but its local actions are constrained by the kernel sandbox. A misconfigured Cedar policy at the gateway is mitigated by the substrate baseline. A shadow agent that never registered is observed and contained at the kernel.

For Kubernetes-native enterprises building agent infrastructure into regulated workloads, this is the architecture worth building toward. Gateway policy for what agents are allowed to ask for. Kernel policy for what they are allowed to do. Same language for both.

Going deeper

Multi-layer policy is one piece of a larger problem: making AI agent infrastructure accountable end-to-end. Traceability, authorization provenance, identity and ownership, policy-based governance at scale, and human oversight and intervention—they all have to work together.

Read: The Five Pillars of AI Agent Accountability →

The post Multi-Layer Policy for Securing AI Agents appeared first on Tigera – Creator of Calico.

What’s new in Calico: Spring 2026 Release

Alister Baroi — Tue, 02 Jun 2026 16:10:41 +0000

Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs running in pods. As Kubernetes adoption grows, and its use cases stretch to cover more ground, managing its increasingly complex networking and security landscape demands operational maturity and a platform that supports it.

The Spring 2026 release of Calico provides that support in two key areas:

Unified operations across Kubernetes pods and VMs

KubeVirt Live Migration in Bridge Mode allows you to migrate VM workloads with IPs preserved, minimal packet loss, and fast route convergence. VMs can move between nodes for planned maintenance, load balancing and to support high availability without interrupting network connectivity.
Egress Gateway Layer 2 Advertisements (Enterprise exclusive) lets pod traffic egress with IPs from the host’s own subnet so workloads get a stable identity the rest of your network already recognizes eliminating the need for BGP Peering to advertise Egress Gateway IPs.
Policy recommendations for VMs and hosts (Enterprise exclusive) automates and scales policy authoring for Calico-managed workloads running outside of your Kubernetes clusters.
OpenStack Live Migration Improvements lets you migrate VM workloads running in high availability OpenStack environments with minimal risk of service disruption during maintenance. Preloading policies on the target node keeps downtime inside the single-digit-second SLOs regulated workloads require.

Production-grade operations at scale

Whisker Policy Verdict and UI Improvements reveal connectivity blockers in minutes by letting you see the actual tier, policy, and rule that denied a flow.
Calico Load Balancer – Maintenance Mode (Enterprise exclusive) supports graceful node maintenance by excluding backends on nodes marked for maintenance from new Maglev assignments, allowing existing connections to drain naturally. Operators can monitor active connections via Prometheus metrics to determine when it is safe to proceed with node maintenance

What’s new in Calico Open Source v3.32

Two new noteworthy features headline this release: Kubevirt Live Migration and Whisker UI improvements.

KubeVirt Live Migration in Bridge Mode

Running VMs in Kubernetes comes with many challenges, among them the need to preserve a VMs IP during live migration so that network traffic can continue uninterrupted. One way to handle this is with Multus and a bridge CNI, statically configuring the VM’s IP and plumbing it directly into the underlay. That preserves the IP, but the VMs sit outside of Calico which means no microsegmentation, no observability and no shared tooling with pods running alongside these VMs. With Calico v3.32, Calico IPAM assigns persistent IPs to KubeVirt VMs. The IP survives live migration and pod restarts and can be advertised upstream over BGP. VMs share the same Kubernetes-native pod network as containers, with the same CNI, policies, observability, load balancing, QoS, and Layer 7 traffic management.

Live migration in bridge mode ships as a tech preview in Calico Open Source v3.32 and moves to production GA in the June release.

Key Benefits of KubeVirt Live Migration in Bridge Mode:

Migrate VMs With Live Connections: Ensure long-lived TCP sessions such as database queries stay connected across the migration so applications don’t have to reconnect.
Keep VM Workloads Reachable During Maintenance: Live migrate VMs to new nodes without blocking user access to applications.
Monitor VM Migrations in a Shared Dashboard: Track live-migration success rates, duration, and post-move network metrics in the same place you track pod activity.
Run One Network, Not Two: Stop maintaining parallel networking layers with VMs sharing the CNI, policy framework, and observability stack with your pod workloads.

Scenario: Live Migration That Keeps VMs on the Pod Network

The Situation:

A financial services enterprise is consolidating its virtualization estate onto KubeVirt on Kubernetes. The VM count sits in the six figures across dozens of clusters. Live migration is part of routine operations: VMs move between nodes during patching, capacity rebalancing, and host failures. The current workaround is Multus and a bridge CNI plumbed into the underlay, which keeps the IP through the move but leaves the VMs outside Calico’s pod network. The platform team would like to implement microsegmentation and observability for VMs as they do for containerized applications.

The Calico Solution:

Calico IPAM assigns each KubeVirt VM a persistent IP that survives live migration and pod restarts, advertised to the upstream network over BGP. Every VM runs on the same Kubernetes-native pod network as the containers next to it, with the same network policies, observability, load balancing, QoS, and Layer 7 traffic management. When nodes go down for maintenance, VMs move and connections survive. The microsegmentation and observability story stays intact.

Whisker Policy Verdict and UI Improvements

Knowing a flow was blocked by policy is a good start to troubleshooting a connection problem. It does not, however, answer the more important question: what policy is responsible and why? Without knowing the reason a flow is denied, the problem cannot be fixed and tracing a flow’s journey across multiple policy tiers and rules can be unreliable and time consuming, potentially prolonging an outage.

The Whisker updates in v3.32 put the verdict, the matching policy, and the full tier chain right in the flow log view. See all the policies that were invoked by drilling down into a flow. Filter by policy kind, tier, namespace and policy name to find out which flows selected policies take action on.

Key Benefits of Whisker Verdict Improvements:

See the Policy Kind, Tier, and Rule Behind Every Verdict: Surface the full evaluation chain, not just the allow/deny decision.
Filter by Verdict or Policy: Narrow the flow log view to just denies or filter by kind, tier, namespace and name, or any combination, to see which flows a set of policies affects.
Close Policy-Denial Tickets in Minutes: Reduce the troubleshooting path from a lengthy and painstaking analysis of policy layers to a thirty-second click into the matching rule.
Let Application Teams Self-Serve: Trace your team’s own policy denies without waiting on the platform team.

Scenario: The Five-Minute Incident That Used to Take an Hour

The Situation:

A developer on the web-app team opens a ticket: their new service can’t reach the payment service. An on-call platform engineer pulls up Whisker, sees the flow was denied, and starts the usual investigation, checking tiers, scanning policies and cross-referencing rules, while walking the developer through each step. Forty minutes later, they find the issue: the payment tier has a default-deny policy that doesn’t include web-app in its allowed-set.

The Calico Solution:

With the Whisker verdict view, the platform engineer opens the flow log, filters by denied flows for the web-app service, and clicks the first matching row. The verdict panel immediately shows the tier, policy, and rule that produced the deny with enough context to describe the fix. The incident is resolved in five minutes, and the ticket closes with a clear remediation path. The platform engineer then stages the fixed policy and then in Whisker filters by kind, tier and policy name to see if any other flows will be affected, averting potential problems.

Click a denied flow to see the tier, the policy, and the rule that produced the verdict.

ClusterNetworkPolicy: Cluster-Wide Policy Goes Standard

Calico has had GlobalNetworkPolicy for years, cluster-scoped policy that sits above namespace boundaries and gives platform teams a place to define org-wide guardrails, default-deny baselines, and cross-namespace controls. The Kubernetes SIG-Network ClusterNetworkPolicy spec is the upstream community’s version of the same idea, and Calico Open Source v3.32 implements it.

While this is more housekeeping than a headline feature, it has two important implications. First, for the Kubernetes community, Calico’s conformant implementation keeps the spec moving and helps cement cluster-wide policy as a first-class part of the standard. Second, for platform teams already running Calico, ClusterNetworkPolicy provides the same cluster-level control surface as GlobalNetworkPolicy, but utilizes the standard upstream API. This means that tooling built around the spec remains reusable and consistent, regardless of the underlying network implementation.

If you’ve been using GlobalNetworkPolicy in your policy pipelines, you don’t need to do anything; everything keeps working. If you’re starting fresh or building tooling that needs to work across multiple CNIs, ClusterNetworkPolicy is now an option to consider.

Key Benefits of ClusterNetworkPolicy:

Define Policy Cluster-Wide With the Standard API: Use the upstream SIG-Network ClusterNetworkPolicy spec at the cluster level, no vendor-specific CRD required.
Adopt the Standard Without Re-Learning: ClusterNetworkPolicy mirrors GlobalNetworkPolicy in shape and behavior, so platform teams already running Calico’s cluster-scoped policy keep the same mental model and tooling.
Stay Aligned With Where Kubernetes Is Heading: Calico’s early implementation moves the SIG-Network ClusterNetworkPolicy spec toward general adoption, cementing cluster-wide policy as a first-class Kubernetes concept.

Cluster-wide network policy scope, now in the standard upstream API

OpenStack Live Migration Improvements

Calico’s route management work in v3.32 closes the gap that’s kept regulated workloads out of OpenStack live migration. By preloading network policies on the target node ahead of a migration, traffic resumes the moment the VM lands instead of waiting for the network to catch up. This solution, which leverages the same route management code that powers KubeVirt Bridge-Mode live migration, addresses the pain of migration for specific industries that measure downtime in single-digit seconds.

Key Benefits of OpenStack Live Migration Improvements:

Migrate Within Your Downtime SLO: Complete OpenStack live migrations within the single-digit-second SLOs that regulated workloads require.
Live Migration During Active Hours: Run live migration without having to wait for off-hours maintenance windows.

Scenario: Migrating a Trading Workload During Market Hours

The Situation:

A regulated financial-data provider runs a trading workload on OpenStack with a single-digit-second downtime SLO for live migrations. Their current KVM live migration routinely stalls long enough to violate it. The platform team has been limited to performing host maintenance during narrow after-hours windows, and some migrations have simply been deferred indefinitely.

The Calico Solution:

After upgrading to Calico v3.32, the team measures live-migration downtime against their reference workload and finds it consistently within SLO. Host maintenance is now possible during trading hours. Deferred migrations can be scheduled and completed without requiring an after-hours rotation.

The node is ready when the VM arrives reducing downtime

Also in this release: Istio Ambient Mode comes to Calico Open Source

Not new, but new here. Calico Enterprise v3.22.1 bundled Istio Ambient Mesh in the Tigera Operator bringing the production hardened and one hundred percent upstream Istio images with sidecarless mTLS to the Calico stack.

As of Calico Open Source v3.32, the same capability is available in the open-source edition. If your platform team is running Istio in sidecar mode, or has given up on service mesh because of its complexity and resource usage, Istio’s ambient mode is worth a second look. In ambient mode there are no sidecars to wrangle on every upgrade, no per-pod CPU and memory overhead, and a much smaller surface to patch when the next CVE lands.

For the full story including architecture, migration path, and a sidecar-tax deep dive, read the Winter 2026 launch blog post.

What’s new in Calico Enterprise and Calico Cloud

KubeVirt Live Migration in Bridge Mode that is part of Calico Open Source v3.32 is also available in Calico Enterprise where it arrives as a tech preview in v3.23 EP2. For organizations evaluating KubeVirt as their landing spot for VMs, this is the release that makes Calico a supported production target.

Beyond KubeVirt, three Platform-exclusive capabilities help you achieve operational maturity at scale, keeping your policy estate clean, unifying management across cluster and non-cluster workloads, and running load-balancer maintenance without customer impact.

Last Evaluated Metrics, Now via API (Cloud and Enterprise)

As customers extend microsegmentation across Kubernetes, the policy set grows sometimes into the thousands for large enterprises. Workloads change, applications change, and the policies that were essential six months ago may not match traffic anymore. Unused policies don’t announce themselves, they lurk, no longer evaluating traffic, but still on the books, a security and compliance risk that violates the least-privileged posture you’ve spent years building towards.

The Winter 2026 release introduced the “Last Evaluated” metric to surface policies and rules that haven’t matched traffic within a configurable window. Spring 2026 adds API access. Platform teams can now query the metric programmatically and feed it into automated cleanup workflows, compliance reports, scheduled alerts, or command line utilities. The same data that supports a PCI DSS v4.1 audit conversation can now flow into a Prometheus alerting rule or a nightly cleanup-candidate report.

One thing worth being explicit about: the metric tells you whether a policy is evaluating traffic, not whether it should still exist. Customers still make the call about what’s genuinely unused, based on knowledge of the workloads. The API uncovers the candidates. The platform team makes the decision.

Key Benefits of Last Evaluated Metrics:

Automate Policy Hygiene: Pipe Last Evaluated data into Prometheus alerts, scheduled reports, or any other workflow you already run.
Generate Compliance Evidence on Demand: Show auditors that every active rule is in use, the proof PCI DSS v4.1 and similar standards require.
Troubleshoot From the CLI: Query last-evaluated state directly via terminal during an incident, no browser required.
Decommission Unused Policies Without Guesswork: Confidently clean up unused policies, not only to maintain that least-privileged posture but to reduce etcd memory pressure and shorten policy-engine evaluation time.

Scenario: Pruning a Microsegmentation Estate at Scale

The Situation:

A large financial-services platform team has been running Calico for several years. Their policy set has grown to several thousand policies accumulated from successive microsegmentation projects, decommissioned services, and one-off tickets. PCI DSS v4.1 audit is approaching, and the auditor wants evidence that every active rule is actually serving a purpose. Manually reviewing several thousand rules isn’t feasible, and the team can’t safely delete what they don’t understand.

The Calico Solution:

The platform team uses the Last Evaluated Metrics API to pull a list of policies and rules that haven’t matched traffic in the last 90 days. They route the output to a CSV, distribute it to the owning teams, and ask each team to confirm or contest each candidate. Within two weeks the policy set is several hundred rules smaller and the auditor gets the evidence trail directly from the metric output, not from a manual investigation.

Automate your least-privileged posture

Egress Gateway Layer 2 Advertisements

With Egress Gateway Layer 2 Advertisements to Calico 3.23 EP2 eliminates the need for cluster-specific egress IP pools and for BGP peering with ToR switches. You can now assign addresses from the hosts subnet to egress gateways, SNAT egress traffic to the gateway’s host node IP and forward packets using ARP. This means less reliance on coordinating with the network team, more efficient use of routable IP addresses and simplified firewall rules for reduced operational overhead.

Key Benefits of Egress Gateway Layer 2 Advertisements:

Reduce the Need for Coordination with the Network Team: Allocate IPs to new egress gateways without extensive intervention by the networking team significantly increasing deployment velocity.
Forward Packets Using ARP: Decrease operational overhead doing away with BGP session on top-of-rack switches.
Avoid Depleting Routable IPs in Large Environments: Configure a shared set of allow-listed IPs rather than a per-tenant pool preserving scarce routable IPs.
Maintain One Firewall Ruleset: Pod egress IPs come from the host’s own subnet, so the firewall team works with the same address space it already maintains for hosts and VMs making firewall configuration and ongoing maintenance much simpler.

Pod egress lives in the same address space your network team already maintains for hosts and VMs

Scenario: Cluster Scale-Up Without a Firewall Ticket

The Situation:

A financial services platform team exposes a set of cluster services to external partner systems through a corporate firewall. Pod egress traffic uses IPs from a cluster-managed pool that the network team registers in the firewall ruleset. Every time the platform team scales the cluster, the pool changes, the firewall ruleset needs updating, and a change-control ticket flows between the two teams. They meet monthly to reconcile drift.

The Calico Solution:

Egress Gateway Layer 2 Advertisements moves pod egress identity into the host’s own subnet. Pod traffic now exits the cluster using a uniquely identifiable IP address from the host’s routable subnet, which can be allowed by the network firewall. Cluster scale-ups stop triggering firewall changes. The reconciliation meeting comes off the calendar.

Policy Recommendations for VMs and Hosts

Calico’s policy recommendations engine has been a valuable tool in a platform engineers arsenal giving teams a head start authoring policies for Kubernetes pods. Until now, however, they could not take advantage of this productivity boost when it came to hosts running outside a cluster. A new VM or bare-metal workload meant manually combing through flow logs and hand-authoring policies which, at scale, often became a significant microsegmentation bottleneck. Policy Recommendations for VMs and Hosts extends the policy recommendation engine to non-cluster workloads. As of v3.23 EP2, Calico observes traffic to and from VMs and bare-metal hosts generating recommended starting policies just as it does for the workloads running in your cluster. The same review-and-apply process platform engineers use for pods now applies to every workload Calico manages.

Key Benefits of Policy Recommendations for VMs and Hosts:

Dispense with Hand-Rolling Policies for VMs and Hosts: Calico generates starting points for non-cluster workloads from observed traffic, the same way it does for pods.
Scale Microsegmentation Across the Whole Estate: Bring least-privilege policies to hundreds or thousands of non-cluster workloads without writing each one by hand.
Use One Authoring Workflow for Every Workload: Work with the same tooling and the same review pattern across pods, VMs, and bare-metal hosts.

Scenario: Microsegmenting a Thousand VMs Without a Thousand Authoring Tasks

The Situation:

A telco runs Kubernetes workloads for 5G edge services alongside thousands of VMs for legacy signaling systems. The platform team has automated policy recommendations for pods, but every new VM workload comes with a manual policy-authoring task. The team cannot keep pace with the VM side, so default policies on VMs trend toward permissive over time.

The Calico Solution:

With Policy Recommendations for VMs and Hosts, the team’s existing recommendation workflow now covers VMs and bare-metal workloads. Recommendations come in based on observed traffic. The team reviews and applies them at the same rate they already review and apply pod recommendations. Microsegmentation extends across the entire estate without doubling the authoring workload.

One review-any-apply workflow across pods, VMs and bare-metal hosts

Calico Load Balancer – Maintenance Mode (Enterprise Exclusive)

Choosing a software load balancer was already the right call for platform teams who wanted declarative service exposure and consistent-hash session affinity, capabilities Calico Load Balancer has delivered since v3.23 EP1.

With v3.23 EP2, the call gets easier. The fast, predictable failover that a pair of hardware load balancers in HA handles cleanly is now native to Calico’s software LB and ready to take over from that expensive 2018 LB you thought you had to replace. Calico Load Balancer now supports label-based node exclusion. Setting maglev.tigera.io/exclude=true on a node tells Calico Load Balancer to stop forwarding new connections to the backends the node hosts while keeping existing sessions flowing until they complete naturally. Prometheus metrics expose per-node active session counts so operators can watch them decline to zero before proceeding with the drain.

Key Benefits of Graceful Maglev Session Handling:

Patch Nodes During Business Hours: Take nodes out of load-balancer rotation for kernel patches, kubelet upgrades, or hardware work without scheduling around customer traffic.
Drain a Node With a Single Label: Set maglev.tigera.io/exclude=true on a node and Calico Load Balancer stops forwarding new connections to its backends, with no custom scripts or out-of-band coordination.
Drain Without Forcing Disconnects: Active sessions on the excluded node keep flowing until they complete naturally so maintenance doesn’t cut off in-flight work.
Know When It’s Safe to Drain: Prometheus metrics expose per-node session counts so operators can watch them decline to zero before proceeding with maintenance.

Scenario: Maintenance That Customers Never Notice

The Situation:

Scheduled maintenance on a node serving live customer traffic has always been a balancing act. Take the node out of rotation too early and customers with in-flight transactions get cut off mid-session. Wait too long and the maintenance window slips. Most teams have either accepted some level of session disruption or built bespoke tooling to coordinate their load balancer’s health checks with the drain workflow.

The Calico Solution:

The platform engineer labels the node with maglev.tigera.io/exclude=true. From that moment, Calico routes new connections to backends elsewhere in the cluster. Existing sessions on the excluded node keep flowing until they complete, so customers with in-flight transactions finish them naturally. The engineer watches per-node session counts in Prometheus, and when the count reaches zero, drains the node. The maintenance happens. The customers don’t notice.

Same fast, predictable failover as hardware load balancers but Kubernetes native

Get Started with Calico Spring 2026

The Spring 2026 release closes some critical Day 2 operations gaps unifying operations across Kubernetes pods and VMs, collapsing two operational worlds into one network, one policy model and one observability stack. It removes long-standing operational friction and clears the way for scaling infrastructure securely and efficiently helping teams take that next step towards Kubernetes operational maturity.

To learn more about these new product capabilities and see them in action, schedule a demo.

The post What’s new in Calico: Spring 2026 Release appeared first on Tigera – Creator of Calico.

The AI Agent Accountability Gap: Why Network Policies, API Gateways, And RBAC Are Not Enough

Alister Baroi — Wed, 27 May 2026 18:45:39 +0000

In The Five Pillars of AI Agent Accountability: A Diagnostic Framework for Engineering Leaders, we walked through each pillar of AI agent accountability (traceability, authorization provenance, identity and ownership, policy at scale, and human oversight) and argued that most enterprises today sit at Level 0 or Level 1 of the Accountability Maturity Model.

The most common reaction we get when we share that framework is some version of: “We’re already covered. We have network policies. We have an API gateway. We have RBAC.”

This article is for that reaction.

Enterprises aren’t starting from zero. Most have invested in security, networking, and identity infrastructure that works well for traditional workloads. The problem isn’t a lack of tools. It’s that existing tools were designed for model outputs, not autonomous actions; a world where services are deterministic, communication patterns are predictable, and humans make all the decisions.

Agentic AI breaks every one of those assumptions. Here’s where the most common approaches each leave a critical accountability gap.

Network policies: the wrong abstraction level

But network policies operate at the wrong abstraction level for agent accountability. They can say “pods in namespace A can reach pods in namespace B.” They cannot say “Agent A with risk-level=low can only call agents with risk-level=low.” They have no concept of agent identity, capabilities, or policy attributes.

More critically, network policies produce no audit trail. When a connection is allowed, there’s no record of why it was allowed; no policy name, no attribute match, no traceable decision. When your compliance team asks “was this interaction authorized by policy?” a network policy gives you nothing to show them.

Accountability gap: No agent-level authorization, no audit trail, no provenance.

API gateways: built for north-south, not agent-to-agent

API gateways (e.g. NGINX, Kong, Envoy, cloud-native gateways) are designed for request routing, rate limiting, and basic authentication. They work well for north-south traffic: external clients accessing internal services.

But agent-to-agent communication is east-west traffic between internal services, often with complex multi-hop chains. API gateways don’t understand agent identities, don’t evaluate agent-specific policies, and don’t produce agent-aware audit trails that correlate across multiple hops.

An API gateway can tell you “a request came from IP 10.0.3.47 and was routed to service X.” It can’t tell you “Agent A (owned by the finance team, risk-level=medium) called Agent B (owned by the compliance team, capability=audit-query) and this was permitted by policy P-2847.”

That’s the level of detail your compliance team needs. An API gateway will never give it to them.

Accountability gap: No agent identity awareness, no policy evaluation, no multi-hop trace correlation.

MCP and A2A protocols: communication without governance

The Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol represent major progress in standardizing agent communication. MCP standardizes how agents connect to tools. A2A standardizes how agents coordinate with each other.

Both are important infrastructure. And both explicitly assume that someone else handles governance.

MCP solves the how of tool access: A consistent protocol for discovering and calling tools. It does not solve the who: which agents are allowed to access which tools, under what conditions, and with what audit trail.
A2A solves the how of agent coordination: Capability discovery, task delegation, lifecycle tracking. It does not solve the who: which agents are allowed to delegate to which other agents, or who is accountable when a delegated task goes wrong.

These protocols are necessary but not sufficient. They are the plumbing, not the governance. Using MCP without agent governance is like having HTTP without authentication; the communication works, but anyone can call anything.

Accountability gap: Protocols handle communication mechanics, not authorization, policy enforcement, or audit.

DIY security patterns: four tools, no unified policy layer

The O’Reilly book, Generative AI on Kubernetes (2026), documents four security patterns for securing MCP communication: token passthrough, service account delegation, OAuth2 token exchange, and mTLS with SPIFFE/SPIRE. Each pattern is sound on its own.

The problem is that implementing all four creates four disconnected systems with no unified policy layer:

None of these patterns produce a correlated audit trail that spans the full agent interaction chain. None evaluate declarative policies based on agent attributes. None provide a dashboard for human oversight of agent communication patterns.

Building accountability from these primitives is like building a car from raw steel, technically possible, but nobody should have to do it from scratch. We’ve seen platform teams sink six to twelve months of engineering into stitching this together, only to discover they still can’t answer the auditor’s question.

Accountability gap: Fragmented security, no unified policy layer, no correlated audit, significant engineering investment required.

RBAC alone: doesn’t survive agent #101

Role-Based Access Control is the default model for most authorization systems. Assign agents to roles, grant roles permissions, done.

RBAC works at a small scale. With 10 agents and 3 roles, the matrix is manageable. But RBAC requires explicit enumeration, where every agent must be assigned to a role, and every permission must be granted to a role. When you add agent #101, someone must decide which role it belongs to and update the bindings.

More fundamentally, RBAC cannot express the nuanced policies that agent governance requires:

“Agents with overlapping capabilities can communicate with each other.”
“Low-risk agents can call low-risk agents, but medium-risk agents can call both low and medium.”
“Agents on the same team can access that team’s MCP servers.”

These attribute-based policies are natural to express in English but impossible to model cleanly in RBAC without an explosion of roles. By agent #200, the role matrix is unmaintainable and new agents start getting deployed without governance, exactly the shadow agent problem we covered in our previous blog post, The AI Agent Accountability Crisis: Why Governance Isn’t Keeping Up With Deployment.

Accountability gap: Doesn’t scale, can’t express attribute-based policies, requires manual updates for every new agent.

The AI agent accountability layer is the missing piece

Every existing approach covers part of the problem. None of them, alone or stacked together, deliver AI agent accountability. The missing piece is the unified layer above them.

The industry has solved agent communication (MCP, A2A) and agent infrastructure (Kubernetes, GPUs, model serving). What’s missing is the accountability layer, the control plane that answers three questions for every agent interaction:

Effective human oversight means:

Who authorized this? Traceable to a specific, auditable policy.
What policy permitted it? With attribute-based evaluation, not hardcoded names.
What’s the full record? End-to-end distributed trace with every hop, decision, and outcome.

The immaturity of the space is striking. A recent review of 43 AI risk frameworks found that only two even addressed agent-specific risks. This is the gap that will determine which enterprises can scale agentic AI responsibly, and which will be forced to cancel projects, face compliance failures, or deal with incidents they can’t investigate.

Common questions about AI agent accountability

Aren’t network policies enough if I’m using a service mesh?

No. A service mesh adds mTLS and routing, but its policy layer still operates on workload identities and namespaces, not agent capabilities, owners, or risk levels. You still can’t produce an audit trail that names which policy permitted a specific agent-to-agent call, or scale that policy without manual updates.

Can I add an authorization layer on top of MCP myself?

You can, and many teams are trying. The hard part isn’t the policy engine; it’s the audit correlation across multi-hop chains, the dual identity verification (workload + user), the visual oversight surface, and the attribute-based policy model that scales. Stitching those together is a 6–12 month engineering investment that delivers a worse outcome than purpose-built tooling.

What about ABAC instead of RBAC?

Attribute-Based Access Control (ABAC) is on the right track, it’s exactly the model AI agent governance needs. But ABAC by itself is a policy language, not a complete platform. You still need agent identity, agent registration, attribute population, audit correlation, and a human oversight surface around it. ABAC is a piece of the answer, not the whole answer.

Does Tigera’s solution replace these tools?

Tigera’s solution complements them. Network policies still secure your cluster. Service meshes still handle mTLS. MCP and A2A still standardize agent communication. Our platform adds the accountability layer above them, the layer that answers who, what, and why for every agent interaction.

Key takeaways

Network policies, API gateways, MCP/A2A protocols, DIY security patterns, and RBAC each solve a different problem; none of them solves AI agent accountability.
The missing layer is the accountability layer: the one that ties identity, policy, and audit together across every agent interaction.
Without that layer, your compliance team has no answer to “which policy permitted this?”
Building it from primitives is technically possible, but it’s a 6–12 month investment that still leaves gaps.

Get the strategic guide for accountable AI agents

If your team is currently trying to assemble accountability from network policies, OAuth2 exchange, SPIFFE, and a homegrown policy engine, then read our guide first.

Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale covers the full framework: the five pillars, the maturity model, the principles, and the three-step roadmap. No code, no product demos. Just what your leadership team needs to make the build-vs-buy call.

Get the strategic guide for accountable AI agents →

The post The AI Agent Accountability Gap: Why Network Policies, API Gateways, And RBAC Are Not Enough appeared first on Tigera – Creator of Calico.

The Case for VM and Container Consolidation in 2026

Alister Baroi — Tue, 26 May 2026 18:50:17 +0000

Two platforms, two teams, two procurement relationships, all doing one job. There’s a reason it ended up this way. There isn’t a reason it has to stay this way.

Ask anyone at a typical enterprise why the VM platform and the container platform are separate, and they’ll give you a sensible answer. The VM estate has been there for fifteen years. It runs the workloads the business depends on. Kubernetes got stood up later, when application teams started building microservices, and giving them their own environment made more sense than retrofitting one onto VMware. Two platforms, two teams, two roadmaps.

That’s how most enterprises got here.

The reasoning was sound at the time. The question is whether it still is.

This is the consolidation question most enterprises haven’t actually revisited, and it’s the one quietly absorbing more of your budget each year.

Figure 1. The current state most enterprises operate today.

Why VM and container platforms ended up separate

If you operate both platforms, you know the shape of this already. There’s a VMware team: vSphere admins, network engineers who know NSX, storage specialists, plus a separate procurement relationship for the underlying virtualisation stack. Then there’s a Kubernetes team: platform engineers, CNI specialists, GitOps people, a different set of vendor relationships. Each team runs its own upgrade calendar, its own monitoring stack, its own security posture, its own incident process. They share office space at offsites. They don’t share much else.

Both teams are doing the same job. They keep infrastructure available for the workloads above it. One set of those workloads happens to be virtual machines and the other happens to be containers, which is a real technical distinction, but it isn’t the distinction your operational model was built around. Your operational model was built around the platforms themselves, and the platforms are separate because of when they were stood up.

Most enterprises don’t re-examine this. The platforms are separate because they always have been. The teams are separate because the platforms are. The procurement is separate because the teams are. Every layer of duplication has a reasonable justification, but the foundational decision underneath all of them, that VMs and containers belong on different infrastructure, is one nobody actually revisits.

What KubeVirt changed about running VMs and containers together

The technical answer to this stopped being theoretical a few years ago. KubeVirt is a CNCF project that lets virtual machines run as native objects on a Kubernetes cluster. It’s in production at NVIDIA, Cloudflare, and ByteDance. This is no longer “an interesting research direction.” It’s the platform pattern that some of the largest, least forgiving infrastructure operators in the world use to run their VMs.

Figure 2. The unified state — same workloads, one operational model.

Which means the original reason your platforms are separate doesn’t really hold anymore. You don’t need a VMware-specific stack to host VMs and a Kubernetes-specific stack to host containers. Both can run on Kubernetes. The platform team you already have, the one that operates your container infrastructure, can take on the VMs too, with the same tooling, the same security model, the same upgrade pattern. The networking layer is the part most teams underestimate. VMs have to keep their existing IPs, VLANs, and firewall references so the rest of your infrastructure doesn’t break. This is the part Calico was built for. Whether your platform team wants to lift and shift VMs onto Kubernetes with the network they already have, or modernise them onto a more dynamic networking model over time, Calico supports both paths on the same platform. Teams don’t have to commit to one approach up front, and they don’t have to migrate the network and the workload in the same step.

This isn’t a pitch about throwing out what you have. The migration is real work, and the order in which you do it matters. But consolidating onto one platform is no longer experimental, and that changes the math on staying where you are.

What VM and container consolidation means for your roadmap

If you’re a CTO or VP Engineering, the question to ask your platform leads isn’t “should we adopt KubeVirt?” That’s an implementation question. The strategic question is whether running two platforms is still the right operational model, or whether it’s something worth a look now that the alternative is real.

Running two platforms compounds slowly. Two teams, two upgrade cadences, two vendor relationships, two of everything. Until the next renewal cycle, the next hiring round, or the next hardware refresh forces a decision you’d rather have made on your own terms.

The first step isn’t the whole programme. Before you can consolidate at scale, you have to migrate one real VM end-to-end without breaking the network it lives on. That’s what your platform team will need to evaluate first, and it’s what our migration guide walks through in detail. It’s written for the engineers who’ll do the work, not for the executive sponsoring it. But if you’re at the point of asking whether the two-platform arrangement is still serving you, it’s the right thing to send their way.

Read the VM migration guide →

The post The Case for VM and Container Consolidation in 2026 appeared first on Tigera – Creator of Calico.

Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh

Alister Baroi — Mon, 25 May 2026 19:26:14 +0000

Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled most enterprises into multi-cluster territory whether they planned for it or not. Reaching Kubernetes operational maturity—the point at which a fleet of clusters operates as one secure, observable, policy-consistent system—depends entirely on how those clusters are connected. Operating in a multi-cluster environment has evolved into the unspoken standard, one requiring a careful re-evaluation of the network architectures used to link clusters together.

That re-evaluation rarely happens. Most enterprises connect their clusters with the same networking patterns they were using before Kubernetes existed: load balancers fronting internal services, DNS records published to external zones, and IP-based firewall rules. Those patterns were built for north-south traffic moving in and out of a traditional data center perimeter, not for east-west traffic moving between internal workloads.

Running east-west traffic on north-south plumbing

The conventional way to make services in one cluster reachable from another is to expose them externally with a load balancer in front, a DNS name registered in a public zone, a firewall rule allowing traffic in. This works but it is not ideal as clusters are not separate entities making the odd API call to each other. They are part of a web of interconnected services that should be able to communicate securely, and with a minimum of friction.

Having to expose these services through external DNS providers, adding additional hops to send traffic through load balancers and creating firewall rules to allow that traffic between internal workloads increases the potential attack surface, introduces latency and piles more responsibilities onto the network team. Securing traffic between workloads gets harder at every layer. Egress rules end up broad and permissive because there is no per-pod identity to write a tighter rule against. Source IPs are erased by SNAT before they reach the destination, so the audit trail compliance teams depend on is non-deterministic. Each cluster also runs its own set of network policies with no awareness of the others, leaving gaps wherever those policy sets disagree.

Visibility suffers in the same way. Each cluster’s observability stack only sees traffic that lives inside it, so the moment a flow crosses a cluster boundary it becomes someone else’s problem. The destination workload sees a connection arriving from a load balancer or a NAT gateway rather than the workload that actually made the call, which means the receiving team can’t tell who is calling their endpoints or whether those endpoints should answer. Tracing a request from a service in one cluster to an endpoint in another means correlating timestamps and partial signals across two or three tools that were never designed to talk to each other. During an incident that gap is the difference between a five-minute fix and a three-hour bridge call. Mean Time To Resolution (MTTR) stretches accordingly.

It is common to see enterprises with eight to twelve clusters where most internal-trust traffic now traverses external load balancers, public DNS, and inspection points designed for traffic from the open internet. This was probably the only option when that first cluster with its half dozen trailblazing workloads was first spun up. Now there’s a better way to connect clusters at scale, and it was built for Kubernetes from the start.

How cluster mesh rewires multi-cluster networking

Cluster Mesh changes the way workloads connect

A cluster mesh federates Kubernetes clusters into a single flat overlay network. Pods talk to pods directly across cluster boundaries, services resolve through native Kubernetes DNS rather than an external provider and traffic is encrypted end-to-end, typically with WireGuard. Network policy is expressed against workload identity such as namespace, label or service account instead of IP addresses that change every time a pod is rescheduled.

Four important things change at the architecture level. East-west traffic stops leaving the trust boundary, because the overlay terminates inside the cluster nodes. DNS resolution moves back inside Kubernetes, removing the external dependency. Identity replaces IP as the unit of policy enforcement, which means a policy written today is still valid after the workload has moved across nodes, regions, or clusters. And telemetry flows through one fabric across every cluster instead of being assembled after the fact from per-cluster silos.

A cluster mesh stops treating each cluster as a sovereign country with its own borders, customs, and identity papers, and starts treating the fleet as a federation where workloads move freely under shared rules.

Cluster mesh means a more secure and resilient architecture

Workloads connect across clusters in a Kubernetes native way

By treating a group of connected clusters as members of one network, cluster mesh shrinks the attack surface by keeping internal services off public DNS where they did not belong in the first place. Policies stay valid as workloads move across nodes, regions, and clusters, because identity rather than IP is what they bind to. Inter-cluster traffic can be encrypted and policies applied uniformly across the entire fleet.

Pods connect to each other directly and observability stops being a per-cluster silo. Flow logs can now follow a request from the client all the way to the service handling it, even when those two live in different clusters.

Day-to-day operations become smoother too, since the platform team stops having to file tickets with the networking team every time a new service ships and connecting that service no longer requires a new VIP or a new DNS record.

In other words, calls between clusters are treated like the east-west traffic they are.

Even compliance work gets noticeably lighter because the default state of the network already satisfies most of what auditors ask about: encryption in transit, identity attribution, and workload-level audit trails.

How mature is your inter-cluster networking?

Here is what each of the four stages looks like in practice, and what each one says about the work that still lies ahead.

Beginner. A single cluster, or multiple clusters with no inter-cluster connectivity. Services exposed via external load balancers and manual DNS records.
Intermediate. VPC peering or transit gateways connect the clusters. External DNS handles service discovery. Some traffic is encrypted, much of it isn’t.
Advanced. A cluster mesh with overlay networking, native Kubernetes service discovery, WireGuard encryption, and identity-based policies enforced consistently across clusters.
Optimized. The cluster mesh is fully GitOps-managed, with unified observability and real-time anomaly detection across the fleet.

In our experience, most enterprises are at Intermediate stage for connectivity and Beginner for the surrounding pillars (egress, microsegmentation and observability) that compound on top of it. This will likely change as organizations grow into their Kubernetes adoption progressing step by step towards operational excellence.

AI raises the stakes

AI has made proper multi cluster architecture even more urgent. GPU scarcity by region, data residency requirements for training data, blast-radius isolation between training and inference, and the operational pattern of separating data preparation, training, and inference into purpose-built clusters are pushing teams into multi-cluster topologies whether they planned for it or not. The architecture you bring to that moment determines whether multi-cluster becomes a strength or a liability.

The full nine-pillar reference architecture, including the egress, microsegmentation, observability, and service mesh pillars that build directly on cluster mesh, is in our ebook, Building Resilient Multi-Cluster Kubernetes. If you would rather work through it hands-on, our reference architecture workshop walks through the first five pillars, the next steps on your operational maturity journey, in a working environment.

Read the ebook: Building Resilient Multi-Cluster Kubernetes →

The post Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh appeared first on Tigera – Creator of Calico.

The Five Pillars of AI Agent Accountability: A Diagnostic Framework for Engineering Leaders

Alister Baroi — Fri, 22 May 2026 17:51:17 +0000

You’re in a board meeting. The CISO is presenting on AI risk. The CFO asks a simple question:

_ “When that finance agent we deployed last quarter accessed a customer payment record, can we tell who authorized it, what policy permitted it, and produce the full audit trail?” _

The CISO looks at the head of the platform. The head of the platform looks at security. Nobody answers.

If you can picture that meeting happening at your company, you’re not alone. McKinsey found that only one-third of organizations have AI agent governance maturity at level 3 or higher. The other two-thirds are exactly the silence in that boardroom.

This post is the diagnostic framework that closes that gap. It’s part 2 of a five-part series on AI agent accountability, and if you only have time to read one post in the series, read this one. By the end you’ll have a five-question assessment to run with your team this week, and a maturity model to score where you stand today.

Not all governance equals AI agent accountability. Many enterprises believe they’re covered because they have network policies or an API gateway, but governance without accountability is a security theater : it might prevent some bad outcomes, but it can’t prove why good outcomes were permitted, trace what happened when something goes wrong, or satisfy an auditor asking for evidence.

True AI agent accountability requires five distinct capabilities working together. Miss any one and you have a gap that will surface during your next incident, audit, or regulatory review.

What are the five pillars of AI agent accountability?

The five pillars are:

Traceability: Every agent interaction produces an end-to-end record automatically.
Authorization provenance: Every permitted action is traceable to a specific, auditable policy.
Identity and ownership: Every agent has a verified identity and a clear human owner.
Policy-based governance at scale: Declarative, attribute-based policies that don’t break at 100 agents.
Human oversight and intervention: Humans can see, review, and override agent behavior in real time.

Each pillar comes with a question you can ask your team. Below, we’ll work through each one, and at the end, a 5-level maturity model and a 5-question assessment to score where you stand today.

Pillar 1: Traceability

_ “Can you trace what happened, end to end?” _

When Agent A calls Agent B, which calls Tool C, which accesses Database D, can you reconstruct the entire chain? Not just that it happened, but when, how long each step took, and what the outcome was at each hop?

Traceability means every agent interaction produces a structured, correlated record automatically. This is distributed tracing applied to agent communication. Each hop in the chain is a span; the full trace tells the complete story of an interaction from trigger to outcome.

Without traceability, incident response is guesswork. You know something went wrong, but you can’t determine the chain of events that led there.

The test: Can your team pull up a single interaction and see the full path it took across every agent and tool in your network, with timestamps and outcomes at every hop?

Pillar 2: Authorization provenance

_ “Can you prove why it was permitted?” _

Blocking unauthorized actions is table stakes. The harder (and more important) question is, can you prove why authorized actions were permitted?

Authorization provenance means every allowed interaction is traceable to a specific, auditable policy. Not just “Agent A was allowed to call Agent B,” but “Agent A was allowed to call Agent B because Policy X grants agents with capability Y access to agents with risk-level Z.”

This is the difference between a lock on the door and a sign-in sheet. The lock prevents unauthorized entry. The sign-in sheet proves who was authorized, when, and by what authority.

Without authorization provenance, your compliance team cannot demonstrate that access was intentional and governed, only that it wasn’t blocked. That distinction is the difference between passing an audit and failing one..

The test: For any agent-to-agent interaction in your network, can you identify the specific policy that permitted it and the attributes that triggered that policy?

Pillar 3: Identity and ownership

_ “Who owns this agent, and who is responsible when it acts?” _

Every agent must have two things: a verified identity (it is who it claims to be) and a clear owner (a person accountable for its behavior).

Identity means the governance layer can verify that an agent is genuinely the agent it claims to be, and not a compromised workload masquerading as a legitimate one. This requires cryptographic identity verification, not just a name in a configuration file.

Ownership means that when an incident occurs, there is a specific person (not a team alias, not a Slack channel, not “the AI team”) who is accountable. Without clear ownership definitions, accountability diffuses across components, and diffused accountability is no accountability at all.

Agent registration should capture: who registered it, what team owns it, what it’s designed to do, and what permissions it’s been granted.

The test: Pick any agent in your network. Can you immediately identify it’s a verified identity, who registered it, which team owns it, and what permissions it has… all without asking around?

Pillar 4: Policy-based governance at scale

_ “Does your security model survive agent #101?” _

With 10 agents, you can manage permissions by hand. You write explicit rules: “Agent A can call Agent B. Agent C can call Agent D.” You maintain a spreadsheet. It works.

With 100 agents, it doesn’t. With 1,000, it’s impossible. Every new agent requires updating every relevant policy. Permissions become a tangled web that nobody fully understands. New agents get deployed ungoverned because updating the allow-lists is too slow.

Scalable governance requires declarative, attribute-based policies. Instead of naming specific agents, policies reference agent attributes: capabilities, risk levels, teams, environments.

“Low-risk agents can communicate with low-risk agents.”
“Agents on the finance team can access finance MCP servers.”
“Agents in production can only call production-grade tools.”

When a new agent registers with matching attributes, it’s governed from day one — automatically. No policy updates required. No spreadsheet to maintain. The governance scales with the agent network, not against it.

The test: When your team deploys a new agent next week, will it be governed by existing policies automatically, or will someone need to manually update an allow-list?

Pillar 5: Human oversight and intervention

_ “Can a human review, approve, or override?” _

The EU AI Act (Article 14) requires effective human oversight of high-risk AI systems. But human oversight doesn’t mean a human approves every agent action, that would eliminate the value of agents entirely.

Effective human oversight means:

Visibility: Humans can see what agents are doing, which agents are communicating, and what policies govern them.
Review: Humans can examine agent interactions after the fact, with enough context to understand what happened and why.
Intervention: Humans can modify policies, revoke agent access, or halt agent communication in real time when necessary.
Dashboard, not log file: The oversight interface should be a visual dashboard with communication graphs and policy visualization, not a grep command on a log file.

The test: Right now, can someone on your team open a dashboard, see which agents are communicating with which, and modify the policies governing that communication — all without touching a terminal?

How to assess your AI agent accountability maturity

Run this five-question assessment with your platform lead, security lead, and one compliance representative in a 30-minute meeting. For each question, you have three possible answers: _ Yes _ (you’ve got it), _ Partial _ (you can answer for some agents but not all), or _ No _ (gap).

Pick the most recent agent-to-agent interaction in your environment. Can someone on the call pull up the full trace (every hop, timestamp, and outcome) in under five minutes? (Pillar 1)
For that same interaction, can you name the specific policy that permitted it and the agent attributes that triggered the match? (Pillar 2)
Pick one production agent at random. Can you produce (from a system, not a wiki) its verified identity, registered owner, team, and granted permissions? (Pillar 3)
Imagine your team deploys a brand-new agent tomorrow. Will your existing policies govern it automatically, or will someone need to update an allow-list? (Pillar 4)
Open whatever dashboard your team uses to view agent activity. Does it show communication graphs and policy state visually, or are you grep-ing a log file? (Pillar 5)

Count your answers. Five Yes = Level 4. Mostly Yes, occasional Partial = Level 3. Yes on identity but No on policy enforcement = Level 2. Inventory only, no identity verification = Level 1. Couldn’t run the assessment because you don’t know what agents exist = Level 0.

If you scored below Level 3, you’re in the McKinsey two-thirds. The good news: you now know exactly which pillar to fix first.

The Accountability Maturity Model

The five pillars map to a five-level progression. Use it to track where you are today and where you’re heading.

Most enterprises today are at Level 0 or Level 1. They lack verified identities, policy enforcement, and end-to-end auditability. The goal is Level 4, and the gap between where most organizations are and where they need to be is the AI agent accountability crisis this framework addresses.

Common questions

What is the most important pillar of AI agent accountability?

All five are required, but authorization provenance is the one most enterprises miss. Plenty of teams can block unauthorized actions; very few can show why an authorized action was permitted, traceable to a specific policy. Without provenance, you have security but not accountability.

How is AI agent accountability different from observability?

Observability tells you what happened. Accountability tells you what was permitted, by which policy, and on whose authority. Observability is a prerequisite, but it’s not enough on its own; your trace data needs to be tied to policy decisions and identity claims to count as accountability.

How does AI agent accountability relate to AI agent security?

They’re complementary, not interchangeable. AI agent security focuses on preventing compromise—stopping prompt injection, blocking unauthorized API access, eliminating shadow agents. Accountability focuses on proving what authorized agents did and why. You need both: security keeps the bad agents out, accountability keeps the good agents honest. The five pillars in this framework assume strong AI agent security is already in place.

Can I assess my AI agent governance maturity using these pillars?

Yes — that’s exactly what the assessment and maturity model above are for. Walk through each pillar’s “test” with your team. If you can’t answer cleanly on all five, you’re at Level 3 or below, regardless of what tooling you’ve deployed.

Do I need all five pillars on day one?

No, but you need a path to all five. A platform that delivers two pillars natively and forces you to bolt on the other three is an accountability gap waiting to surface. We cover what to look for in future articles of this series.

What is the difference between Level 3 and Level 4 in the maturity model?

Level 3 means unauthorized interactions are blocked, you have policy enforcement. Level 4 means you can also prove why every authorized interaction was permitted, with audit evidence tied to a specific policy and identity. Level 3 is security; Level 4 is accountability.

Key takeaways

AI agent accountability rests on five pillars: traceability, authorization provenance, identity and ownership, policy at scale, and human oversight.
Each pillar has a clear test you can run against your environment today.
The five pillars map to a five-level Accountability Maturity Model — most enterprises are at Level 0 or 1.
Run the 5-question assessment with your platform, security, and compliance leads to score where you stand.
Missing any single pillar creates a gap that will surface during your next incident, audit, or regulatory review.

Get the strategic guide for accountable AI agents

We wrote a strategic guide for engineering and security leaders that goes deeper into each pillar, including detailed assessment questions, the full maturity model, and a practical roadmap to Level 4.

Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale — no code, no product demos. Just the framework your leadership team needs.

_ Get the strategic guide for accountable AI agents → _

The post The Five Pillars of AI Agent Accountability: A Diagnostic Framework for Engineering Leaders appeared first on Tigera – Creator of Calico.

KubeVirt Live Migration Done Right: What it Takes to Run VMs on Kubernetes

Alister Baroi — Thu, 14 May 2026 20:53:44 +0000

Running VMs in Kubernetes sounds like a crazy workaround for avoiding vendor lock-in, and standardizing legacy applications and newer containerized workloads on one control plane with one set of security policies to govern them all. It is, however, a rapidly growing pattern, and KubeVirt live migration — moving running VMs between nodes without downtime — is increasingly central to platform engineering use cases that require full VMs, like on-demand CI/CD pipelines.

KubeVirt is gaining traction as a way to bring VMs into Kubernetes as first-class workloads, managed with the same tools and primitives that platform teams already use for containers. It has, however, introduced some unique challenges.

Here’s the uncomfortable truth about that migration: compute and storage are the easy parts. Networking is where migrations stall, roadblock multiple, and platform teams start questioning whether KubeVirt was the right call in the first place.

If your VMs have no fixed IP dependencies, no VLAN memberships, and no upstream firewall rules scoped to specific subnets, you can migrate them into Kubernetes without losing sleep over the networking layer. If you’re running hundreds or thousands of VMs with IP addresses hardcoded into application configs, DNS entries, and firewall ACLs — and you need to move those VMs to Kubernetes without rewriting any of it — then your networking layer is about to become the most important decision in your migration.

What follows is a technical walk-through of the L2 plumbing that keeps KubeVirt VMs connected when they move between nodes in a production cluster and how it eliminates the need to update your complicated network infrastructure.

Kubernetes Networking Wasn’t Built for VMs

In a traditional hypervisor environment — vSphere, Hyper-V, Nutanix — VMs sit on VLANs and have fixed IPs. Upstream firewalls, load balancers, and DNS records all reference those IPs. A security team owns the VLAN segmentation while the network team owns the routing. This network infrastructure is the accumulated work of many years and forms a static, and somewhat brittle, system of securing hosts and getting traffic to its destination. The Kubernetes networking model, with its dynamic allocation of IPs that are meaningful only inside a cluster, is at odds with this traditional approach. Therein lies the problem.

The upstream network has no direct visibility into the pod network. When a VM is migrated from your existing hypervisor into Kubernetes, its original network segment is not preserved. The VM gets a new IP from the pod CIDR, and every firewall rule, DNS entry, and load balancer config that referenced the old IP is now broken. For a handful of VMs, you can reconfigure your firewall rules and routing manually. For hundreds or thousands reconfiguration becomes not only costly in terms of engineering effort but also injects the risk of breaking critical functionality and introducing security blind spots.

Two Networking Modes, Two Different Problems

Before diving into solutions, it helps to understand how KubeVirt presents networking to VMs. There are two modes for the primary pod interface, and they solve different problems.

Masquerade mode decouples the pod IP from the VM IP. KubeVirt assigns a static IP to the VM internally and uses NAT rules to translate between the two. Live migration works out of the box because the pod IP can change without affecting the VM. The trade-off is that you need a service-level abstraction to reach the VM from outside the pod, which makes this mode impractical for production workloads that need stable, directly-addressable IPs.

Bridge mode is the production-grade option. The pod IP and the VM IP are identical. The VM is directly reachable on the network. No NAT, no service abstraction. But bridge mode introduces a hard problem: when a VM live-migrates to a new node, KubeVirt creates a new pod on the destination. That new pod gets a fresh IP from the CNI. The VM still thinks it has its original IP. The result is a routing mismatch — the network doesn’t know where to send traffic, and the VM’s connections break.

KubeVirt only handles memory and disk migration. This does not matter much in masquerade mode since the VM’s IP is decoupled from the pod’s IP via NAT but becomes a critical consideration in bridge mode. So the CNI has to do three things to ensure nothing breaks: preserve the IP across the pod transition, converge routes so the rest of the network knows the VM has moved, and ensure network policy is in place on the destination before the VM goes live.

Live Migration in Bridge Mode: What Happens Under the Hood

VMs need to move between nodes for a variety of reasons, for example maintenance, load balancing, or high availability. What actually happens during a live migration in bridge mode and why is making it work right so hard?

The 5-step network handover during live migration in bridge mode

The Core Challenge

When a migration is triggered using the KubeVirt command line utility, virtctl, KubeVirt creates a new pod on a destination node chosen by the Kubernetes scheduler in the usual way based on available resources, affinity rules, shared storage, etc. Next, KubeVirt copies the VM’s memory state using libvirt’s pre-copy and post-copy mechanisms.

Then things get a bit interesting.

The source pod continues running during the whole process. From a networking perspective, the same IP now needs to exist in two places temporarily — on the source node (where the VM is still running) and on the destination (where it’s about to go live).

The CNI has to solve three problems simultaneously: IP persistence across pod lifecycles, route convergence during the handover window, and policy continuity so the VM isn’t exposed during migration.

Let’s look at how Calico makes this happen.

IP Persistence: IPAM That Understands VMs

Traditionally, Calico IPAM allocates IPs to pods. The IPAM handle (the ownership ticket for an IP reservation) is derived from the pod’s identity. This works for containers because pods are ephemeral. But a KubeVirt VM is more like a Kubernetes Deployment: you define a VirtualMachine resource, and KubeVirt creates a randomly-named pod to run it. Every time you restart or migrate the VM, the pod changes, but the VM stays the same with the same identity, memory state and the same IP.

Since IPAM assigns the IP to the pod, every migration means a new IP, which defeats the purpose of preserving the VM’s IP and breaks any firewall rules, load balancer configurations or DNS records pointed at this IP.

To fix this, Calico constructs the IPAM handle from the VM’s name instead of the pod’s name ensuring that the reservation persists across pod lifecycles. When a VM migrates and its old pod is destroyed, the IPAM handle survives because it’s tied to the VM identity. When the new pod starts, the IPAM finds the existing handle and reuses the same IP. During migration, the IPAM transiently tracks dual ownership — an active owner on the source node and an alternate owner on the destination — then converges to a single owner once the source pod is cleaned up.

Route Convergence: The GARP Handover

IP persistence ensures the VM keeps its address. Route convergence ensures the rest of the network knows where to find it. Here’s the sequence:

Migration initiated. The CNI watches for migration events in the Kubernetes API. As soon as one is created, it starts preparing the destination node’s networking — policies, routes, interface configuration — so that everything is in place before the VM actually moves.
Memory pre-copy. KubeVirt and libvirt handle the iterative memory copy. The VM continues running on the source node. Traffic continues routing to the source at standard priority.
VM goes live on destination. The VM broadcasts a Gratuitous ARP (GARP) packet announcing “I own this IP now, and I’m on this node.” Felix picks up this GARP and immediately advertises a high-priority route for the VM’s IP via the destination node. The networking layer picks this up and immediately starts steering traffic for the VM’s IP toward the new node, overriding the old route.
Route priority override. This is a critical engineering detail. Normal routing uses a standard metric (1024). During migration, the destination node advertises the VM’s route at a higher priority metric (512). Because the source pod still exists briefly in a post-life state, both nodes momentarily have routes for the same IP. The higher-priority route ensures all traffic is forwarded to the destination, even before the source pod is fully cleaned up.
Cleanup and steady state. Once the source pod terminates, the high-priority route is replaced with a standard-priority route. The source node’s route is removed. The network converges to its normal state with the VM on its new node at the same IP.

Policy continuity

The CNI watches for migration events and uses the lead time to pre-program network policies on the destination node while the memory copy is still in progress. By the time the VM cuts over, its security posture is already in place leaving no gap for unsanctioned traffic to slip through.

This works because Kubernetes network policies use label selectors, not IP addresses. The policies follow the VM’s identity, its labels, namespace, and network membership, not its physical location. When the VM appears on the destination node with the same labels, the same policies apply automatically. One nuance worth noting: while the policy rules carry over, stateful connection tracking (conntrack) does not currently replicate between nodes. Established connections survive because the routes converge, but the destination node evaluates them as new flows. Full conntrack replication is a planned future enhancement.

Portability and Standardization for VMs

If you’re familiar with vSphere, you know vMotion, paired with the vSphere distributed switch, managed live migration networking seamlessly. However, this transparency relies on a vertically integrated stack that is not portable to other cloud environments.

In Kubernetes, the stack is disaggregated. Components like KubeVirt (VM lifecycle), CNI (networking), policy engines (security), and storage operators (disks) each manage their own part. For live migration, the CNI must coordinate with KubeVirt’s migration state machine to manage the VM’s temporary dual-existence across two nodes and converge routing without a centralized controller.

The Kubernetes approach is fundamentally different. It uses open standards: CRI, CNI, CSI, and NetworkPolicy. KubeVirt extends this; VMs are custom resources, managed by kubectl, and scheduled by the same control plane. This approach demands a CNI that understands the unique lifecycle, identity and networking requirements of a pod running a VM but it also makes VMs portable.

It also means that now your containers and VMs can be managed and monitored using the same policies and tools and that means not only operational efficiency but better security and more reliable auditing.

Live migration is one piece of a larger networking story. If your KubeVirt rollout involves bridge mode at scale, multi-cluster topologies, BGP peering, or policy parity across VMs and containers, those decisions compound quickly. We pulled the full picture into The Complete Guide to VM Networking for Kubernetes, a practitioner’s reference covering the architectural choices, networking modes, and operational patterns that determine whether a migration ships or stalls.

Get The Complete Guide to VM Networking for Kubernetes →

The post KubeVirt Live Migration Done Right: What it Takes to Run VMs on Kubernetes appeared first on Tigera – Creator of Calico.

The AI Agent Accountability Crisis: Why Governance Isn’t Keeping Up With Deployment

Alister Baroi — Thu, 14 May 2026 18:08:21 +0000

Every enterprise is building AI agents. Marketing has one summarizing campaign performance. Engineering has one triaging incidents. Customer support has one resolving tickets. Finance has one processing invoices. Each was built by a different team, using a different framework, with different assumptions about security.

Now those agents are talking to each other through agent-to-agent (A2A) communication. The incident-triage agent calls the customer-support agent to check affected accounts. The invoice agent calls an external payment API. The marketing agent queries a data warehouse with customer records.

When something goes wrong (and at this scale of deployment, it will), can you answer:

Who authorized the action?
What policy permitted it?
What was the full chain of events?

If you can’t, you have an accountability gap.

This is part one of a five-part series on AI agent accountability for engineering and security leaders. We’ll work through the gap between agent deployment and governance, the diagnostic framework that exposes it, why your existing tools won’t close it, and the principles you’ll need to evaluate any solution that claims it can.

What is AI agent accountability?

AI agent accountability is the ability to trace, prove, and audit every action an AI agent takes. This includes which policy permitted the agent, which identity initiated it, and what the downstream effects were. It’s the layer above agent communication (MCP, A2A) and agent infrastructure (Kubernetes, GPUs, model serving) that answers the question: who’s responsible when the agent acts?

A landmark 2026 report from Accenture and the Wharton School of Business put the gap bluntly: “ Intelligence may be scalable, but accountability is not. ” As enterprises race to deploy agents across every function, the governance architecture has not kept pace.

Agents are scaling faster than governance

The scale of the problem is not theoretical anymore. Major analyst firms have quantified it:

| Source | Finding |
| McKinsey, 2026 | 80% of organizations have encountered risky behavior from AI agents, actions that were unintended, unauthorized, or outside acceptable guardrails. |
| McKinsey, 2026 | Only one-third (~33%) of organizations report governance maturity. |
| Gartner, 2025 | Over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear value, or inadequate risk controls. |
| ISACA, 2025 | 66% of industry leaders believe formal agent accountability frameworks will become mandatory within the next two years. |
| Dataiku, 2026 | 87% of CIOs report AI agents are already embedded in their enterprises, yet 75% lack real-time visibility into agent operations in production. |

These are not edge cases. This is the mainstream enterprise experience with agentic AI in 2026.

Shadow agents: the new AI agent security gap

A decade ago, enterprises faced “ Shadow IT “. Employees adopting cloud services without IT approval, creating ungoverned sprawl that took years to bring under control. The same pattern is repeating with AI agents, but faster and with higher stakes.

Low-code platforms have made it easy for almost anyone to create an AI agent. Building agents are now table stakes. Scaling them with governance is the real differentiator.

Unlike cloud services, agents don’t just store data. They act. They make decisions, call APIs or MCP servers, access databases, and communicate with other agents. An ungoverned cloud service might leak data. But an ungoverned agent will leak data, take actions on that data, and propagate those actions across other agents in a chain that nobody can trace.

When an AI agent operates without clear ownership or accountability, productivity gains become systemic AI agent security risk. When something goes wrong, there is no clear owner to take responsibility, remediate, or even understand the full blast radius.

The regulatory deadlines

The EU AI Act‘s main body takes effect in August 2026. For enterprises deploying agentic AI, three articles are particularly relevant:

Article 12 requires high-risk AI systems to log their actions to ensure accountability and traceability.
Article 13 requires clear and comprehensible information about how AI systems function and make decisions.
Article 14 requires that high-risk systems are subject to effective human oversight, which is especially important for agentic AI, given the challenges of supervising autonomous agents.

The European Commission may also assess degree of autonomy as a relevant factor when determining whether a system poses unacceptable risks. The more independent your agents are, the higher the regulatory bar.

The US is not far behind. The Colorado AI Act (SB 24-205), delayed to June 30, 2026, requires deployers of high-risk AI systems to implement risk management programs, complete impact assessments, disclose to consumers when AI makes consequential decisions, and report algorithmic discrimination to the state attorney general. It applies to any company doing business in Colorado.

And Colorado is not an unique outlier, it’s just the leading edge. California, New York, Utah, and Texas have also already enacted AI governance laws. At the federal level, 80+ AI governance bills are under consideration in the current Congress. The NIST AI Risk Management Framework is already the de facto US enterprise standard, even where it isn’t legally required.

Compliance deadlines on both sides of the Atlantic are weeks away, not months or years.

The core tension, and why it’s solvable

Enterprises want agent autonomy. That’s the entire point: agents acting independently to drive efficiency and scale. But they also need accountability; knowing what happened, why it was permitted, and who is responsible.

These seem to conflict. More autonomy means less control. More control means less autonomy.

But this is a false dichotomy. As Palo Alto Networks puts it: _ autonomy changes how systems operate, it doesn’t change who’s responsible _.

The same tension existed in microservices a decade ago. Teams wanted independent deployments (autonomy) with reliable service communication (control). The answer wasn’t to choose one over the other. It was to build a governance layer: service meshes, mTLS, observability; that delivered both.

AI agents need the same evolution. The question isn’t whether to give agents autonomy or accountability. It’s whether you have the governance infrastructure to deliver both.

Frequently asked questions

What is the difference between AI agent accountability and AI agent security? Security is about preventing unauthorized actions (blocking the bad). Accountability is about proving why authorized actions were permitted (auditing the good). You need both. A locked door (security) without a sign-in sheet (accountability) leaves your compliance team with nothing to show an auditor.
Why is AI agent accountability a 2026 priority? Three forces are converging this year: rapid agent deployment (87% of CIOs report agents already in production), maturing regulatory regimes (EU AI Act in August, Colorado AI Act in June), and the first wave of public agent-related incidents driving boardroom attention.
Does the EU/US AI Acts apply to my AI agents? If your agent is classified as a high-risk AI system under the Acts, then yes; and Articles 12 (logging), 13 (transparency), and 14 (human oversight), from the EU AI Act, all apply directly. Degree of autonomy is one of the factors regulators consider when assessing risk classification.
Are network policies and RBAC enough for AI agent governance? No. Network policies operate at the wrong abstraction level (pod-to-pod, not agent-to-agent) and produce no audit trail. RBAC requires explicit enumeration that breaks down past about 100 agents, and can’t express attribute-based policies. We’ll cover this in detail in a later post of the series.

Key takeaways

80% of organizations have already encountered risky AI agent behavior, but only one-third have governance maturity to match.
The EU AI Act and Colorado AI Act both take effect in 2026, so accountability requirements are no longer just optional, they are mandatory.
AI agent accountability is the missing layer above agent communication (MCP, A2A) and agent infrastructure (Kubernetes).
Autonomy and accountability are not in conflict, but you need a governance layer to deliver both.

Get the strategic guide for accountable AI agents

We wrote our guide, Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale, to help engineering and security leaders close this gap. No code, no product demos, no fluff. Just the framework your leadership team needs to govern AI agents before the next incident (or the next regulation) forces your hand.

Get the strategic guide for accountable AI agents →

The post The AI Agent Accountability Crisis: Why Governance Isn’t Keeping Up With Deployment appeared first on Tigera – Creator of Calico.