HIPAA Wasn’t Written for AI Agents. It Applies to Them Anyway
In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its own from 2027, and 43% of health systems were piloting agentic AI at the start of this year. Every one of those agents runs next to Protected Health Information (PHI), and PHI comes with rules that were not written for autonomous software but land on it anyway: minimum necessary access, audit controls, business associate agreements, a 60-day breach clock. This post maps those rules onto what agent infrastructure must provide (identity, per-request authorization, live inventory, an audit trail across every hop), then shows where Tigera Lynx fits and what it does not do. It is written for the platform and security leaders who will be asked to produce the record.
Healthcare was supposed to be the cautious one. Regulated to the bone, allergic to unvetted vendors, still running a fax machine somewhere in the basement. Instead, it is adopting AI agents faster than almost anyone.
At HIMSS in March 2026, Epic previewed Agent Factory, a visual builder for health systems to create, customize, and Continue reading
Managing Claude Code Sessions Through Lynx
At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts.
Coding agents create an interesting problem because, in most organizations, they didn’t arrive through the front door.
Few companies ran a platform evaluation and rolled Claude Code out to 500 developers. Developers installed it themselves. By the time security and platform teams started asking how coding agents should be governed, they were already running on laptops with access to source code, credentials, SSH keys, kubeconfigs, internal services, and whatever else the developer could reach.
The long-term answer is increasingly clear I think: move coding agents into isolated environments you control.
Anthropic’s sandboxing work draws filesystem and network boundaries using OS primitives such as bubblewrap and seatbelt. Its reference devcontainer includes an egress firewall. Docker has introduced sandboxes for running coding agents, and Kubernetes-based approaches can add stronger workload isolation, network policy, and disposable development environments.
That direction makes sense.
Isolation governs what an agent can do. A gateway governs what it can send.
And unlike a complete move to remote development environments, the second boundary is something you can introduce today.
Start with one environment Continue reading
The Clearinghouse For AI Agents Has A Blind Spot
Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple and, I think, correct: the SaaS era rewarded whoever owned the system of record, and the agent era will reward whoever owns the clearinghouse. This is a new seat that sits between mutually-distrusting agents and decides which one is cleared to act, on what data, with what limits, and can prove what happened after the fact. The lock-in moves from your data to your permissions. The source-of-truth era becomes the source-of-permission era.
I agree with all of it. Governance has graduated from a compliance checkbox at the end of the sales cycle to the first question a CIO asks. Once agents act autonomously and eventually spend real money, “is the model good?” stops being interesting now that every model is good enough and “can I see what every agent did, set policy on what it can touch, and prove it to my auditors?” becomes the whole conversation. That seat is strategic real estate. Whoever holds it is hard to dislodge.
HITL for autonomous agents: Where does the human go?
Human approval is easy when you are sitting in front of the agent. For an agent running by itself in a cluster, almost none of that holds.
You’re in a meeting and your agent is running in a cluster. It has a service account, it has been asked to keep a service healthy, and it has just worked out that the right fix is to roll back a database migration. Nobody is watching it. That was rather the point of deploying it. You want to get notified to approve such an important action.
This is a different problem from the one most people picture when they hear human in the loop. If you use a coding assistant, you already have human oversight and it costs almost nothing: the agent shows you a diff, you read it, you approve. That works because you are already there — at a keyboard, with the context in front of you, in the same second the agent needs an answer.
An autonomous agent has none of that. There is no session to interrupt. The person who should decide is asleep, or in a meeting, or on a plane. The approval has to travel out of Continue reading
AI Agents on Kubernetes 101: From Laptop Script to Production Pod
In short, this is a beginner’s guide to deploying an AI agent on Kubernetes. You will containerize an agent, store its API key as a Kubernetes secret, write a deployment with health probes and resource limits, expose it with a service, and lock down its network egress, in that order, with a working manifest at every step. On a local kind cluster the whole walkthrough takes about an hour. At the end: the six mistakes almost every first agent deployment makes, and the questions a 101 deployment leaves open.
Every AI agent starts life the same way; a Python script on someone’s laptop, an API key in a .env file, a while loop around an LLM call. It works, it demos well. Then someone with a budget says “ship it,” and you, the engineer closest to the script, get to figure out what shipping an agent actually means.
This guide is that path, walked slowly. It assumes you know what a container is and have met kubectl at least once, and it assumes nothing about agents. By the end you will have an agent running in a cluster with its key in a Secret, its resource usage capped, its Continue reading
Meet Mylo: An AI-native way to work with Calico
A library of Calico tools and skills — delivered through the Calico MCP Server
What if your hardest network question took ten minutes instead of ten days?
Anyone who has operated Kubernetes networking at scale knows the shape of a bad day. A request that should succeed is quietly failing. The application team swears nothing changed. Somewhere across a stack of tiers, selectors, and policies, some written last week and some inherited from an engineer who left two years ago, a rule is denying the traffic. Finding it means reading YAML, cross-referencing flow logs, and reconstructing the policy evaluation order in your head. For a genuinely knotty case, that work can stretch across days and pull in more than one team before anyone gets to the bottom of it.
I think that day is about to get a lot shorter. Today we’re introducing Mylo, an expert for Calico that works inside the AI tools your teams already use. Ask Mylo why a pod can’t reach a service, and it traces the path, points to the exact policy and rule doing the blocking, and explains why in plain language, in about the time it took you to read this paragraph. Mylo Continue reading
The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It
Every organization running AI agents has already made a hosting decision. Most made it by accident.
The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a vendor’s cloud. Someone on the data team deployed a LangGraph service to a VM with a database key in an environment variable, and someone else is running an agent framework on a laptop with production credentials in a dotfile. Each of these is a hosting decision. Each one quietly settled who holds the agent’s credentials, what network paths it can reach, what gets recorded when it acts, and who can stop it. Nobody ran an architecture review, because no single deployment looked big enough to deserve one.
The scale says otherwise. By May 2025, 82% of organizations surveyed by SailPoint were already using AI agents. Only 44% had policies for securing them, 80% said their agents had already taken unintended actions, and 23% had watched an agent get tricked into revealing credentials. A year later the bill arrived: IBM’s 2026 Cost of a Data Breach report found that one in four malicious breaches is now AI-enabled, up 56% in a single year, and that those Continue reading
AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.
The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms find real problems at a scale no human team can match. But when you read the findings closely, a pattern emerges: agents talked into refunds, transfers, and data leaks they had standing authority to perform. Patching the prompt fixes one phrasing until the next model update. Constraining the authority fixes the class. The first job belongs to a red team platform. The second belongs to your runtime, and no scanner will do it for you.
In April 2026, General Analysis raised a $10M seed round on the strength of an uncomfortable demonstration: its adversarial agent attacked 55 live customer service bots and compromised 50 of them. Not lab models, but live systems with real customers and real tool access. This post is about the market behind that demonstration: who now automates the attacker’s role, what the attacks keep finding, and why the fix that lasts is runtime policy rather than a better prompt.
What an AI red team agent actually does
A traditional red team Continue reading
You’ve Been Running a Kubernetes Security Model in NSX and Didn’t Even Know It
One of the blockers to moving VMs off vSphere and onto Kubernetes is losing NSX and the protection it provides. Security teams that have spent years building out distributed firewall policy look at Kubernetes and are, quite understandably, alarmed by the flat network and the fact that any workload can reach any other by default.
How will they enforce east-west traffic controls? Will they be able to replicate NSX distributed firewall rules with the same granularity? What about security groups, tiered policy, and rules that travel with the workload when it moves? These are important questions that must be answered before migration can begin.
Migrate vSphere to Kubernetes with microsegmentation intact
Calico addresses vSphere to Kubernetes security concerns with a network policy model that maps directly to key features of the NSX distributed firewall (NSX DFW). Every property NSX DFW users rely on has a direct Calico equivalent: tiered governance, workload-identity enforcement, distributed kernel-level inspection, and dynamic workload grouping. Teams coming from vSphere will recognise the pattern quickly.
Let’s walk through each one in detail.
Distributed Enforcement
Traditional firewalls sit at the edge of the network. Traffic between workloads inside Continue reading
The New MCP Headers Are a Gift to Gateways
In short, buried in the transport section of the MCP 2026-07-28 release candidate are three changes that matter more to infrastructure teams than to anyone else: mandatory Mcp-Method and Mcp-Name headers, cache-control-style ttlMs and cacheScope fields, and standardized W3C Trace Context propagation. Together with the stateless core, they turn MCP from a protocol that gateways had to fight into one that meets them halfway. What the headers still don’t carry: who the caller is, whether the call should be allowed, and any record that it happened.
Everyone is writing about MCP going stateless, and the coverage is deserved. No handshake, no session ID, any request can hit any server replica, round-robin load balancing just works. If you want the deep dive on what that does to protocol state, my colleague Peter is writing one.
I want to talk about the part of the release candidate that made me sit up, because I spend my days around a gateway that authorizes agent traffic. It’s three transport changes, a few paragraphs in the announcement, and it fixes a problem every MCP-aware proxy has been engineering around since Streamable HTTP shipped in the 2025-03-26 revision.
The problem: MCP was opaque at the network Continue reading
VM Migration – What Happens to Your NSX Segments in Kubernetes?
Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to Calico’s tiered microsegmentation. NSX virtualizes the network layer in ways that Kubernetes doesn’t replicate by default. There is no native concept of a Layer 2 segment or VLAN, for instance. Pods simply receive IP addresses on a flat, routed network, with no built-in way to give a workload L2 adjacency to external devices or attach it to a specific broadcast domain.
This is usually where teams start to worry. They can see exactly what NSX is doing for them, but they have no obvious Kubernetes equivalent to point at. The natural question becomes how they will run the networking they depend on once their VMs live in a cluster.
Achieving the same routing, isolation, and connectivity outcomes, however, is well within reach. It just requires a bit of a mental shift.
The rest of this blog will cover the details of what that mental shift entails.
How NSX handles segments
Before we Continue reading
MCP’s Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don’t
In short, the MCP 2026-07-28 release candidate is getting attention for going stateless. The quieter story is a package of six SEPs that harden the protocol’s OAuth layer: issuer validation, credential binding, client type declaration, and cleanups around refresh tokens, scopes, and discovery. All six are worth shipping, and all six fix real failure modes. But they harden how a client authenticates to a server, and that was never the whole problem. Agent identity, per-request authorization, delegation, and audit still sit outside the spec. Which means they still sit with you.
The stateless core is soaking up most of the commentary on the new MCP release candidate, and fair enough: deleting the initialize handshake and the session ID changes how everyone deploys. But scroll past that section of the announcement and you hit six SEPs of authorization hardening that almost nobody is writing about. That’s a mistake. If you operate MCP servers that hold real credentials, this is the part of the spec that decides whether a confused client hands a token to the wrong party.
The final spec ships July 28, 2026. The release candidate was locked on May 21, and SDK maintainers are in a ten-week validation window Continue reading
Bring Your Own VLAN: Moving VMs to Kubernetes Without Changing a Single IP
For many organizations, modernizing their VMs before migrating them is not a realistic option, especially when external events trigger the migration. Mapping dependencies and refactoring network configurations before the deadline is impractical, forcing VMs to move as they are.
The mechanics of moving a VM are largely solved. Tools like Forklift handle what a vSphere admin would recognize as a cold or warm migration: copy the VMDKs off the datastore, convert the guest, and boot it as a KubeVirt VM on Kubernetes. The guest comes through with its disks, its OS, its MAC address, and the static IP still written in its network configuration.
Recreating the NSX segment the vNIC was attached to, the VLAN that defined the VM’s compliance scope, or the firewall rules that reference its address is a different story. The VM arrives in a cluster that knows nothing about any of it. Everything NSX was doing for that VM now has to be rebuilt on the Kubernetes side.
Kubernetes networking cannot solve this on its own, for two reasons. First, pod IPs are assigned dynamically from the cluster’s pod CIDR, and a KubeVirt VM attached to the pod network is treated like any other workload, meaning Continue reading
Why eBPF Is Useful for Watching and Sandboxing AI Agents
Most of our runtime security habits were built for deterministic workloads. A service does what its code says: review the code, sign the image, and its behavior is bounded. Agents are different. An agent’s behavior emerges from a model reasoning over whatever lands in its context window, and some of that context comes from places we don’t fully control — a retrieved document, a tool’s output, a user’s prompt. Meanwhile the agent usually runs with real privileges: a service account, network reach, mounted secrets, a filesystem. When untrusted input shapes behavior, those privileges get exercised less predictably than we’re used to.
A lot of good work goes into making agents harder to mislead — prompt hygiene, injection classifiers, guardrail models. It’s worth pairing that with a second question: if an agent does something we didn’t intend, how far can it actually reach? That’s blast radius, and it’s mostly a decision we make at the runtime layer, independent of how the prompt was handled.
This is where eBPF is a good fit, for two reasons: it’s an excellent way to see what an agent is doing, and it can enforce limits on what the agent can touch — without changing the Continue reading
Migrate First, Modernize Later: A Leadership Guide to Converging VMs and Containers to Run AI Workloads
The Tipping Point
Every so often the ground under enterprise IT moves. It’s moving now. Across industries, organizations are consolidating fragmented infrastructure onto a single, self-hosted platform capable of running both containers and virtual machines side by side. The motivation is simple: simplify operations, lower cost and reallocate resources & budget to AI initiatives. Kubernetes is emerging as the primary platform for many of these workloads.
For most IT leaders, the compute and storage portions of a VM migration are manageable. Storage arrays and hypervisor CPU/memory allocation translate fairly directly to Kubernetes equivalents. Networking is where migration plans stall. A VM’s network identity — its IP, its VLAN membership, its firewall rules — is wired into surrounding infrastructure, monitoring, compliance controls, and business processes that nobody wants to touch during a migration window.
Teams accustomed to NSX for this work find that native Kubernetes networking wasn’t built with VM administrators in mind, and the functionality gap becomes the reason migration projects get bigger or are stalled. If the networking problem is solved — if a VM can move to Kubernetes and keep its IP, its policy, and its security posture intact — then the rest of the platform consolidation stops Continue reading
What Happens to a VM’s IP When It Moves During Migration?
Why VM IP identity needs handling on Kubernetes
A KubeVirt VM runs inside a pod. That is the trick that lets Kubernetes schedule a VM like any other workload. It also means the VM and the pod have different lifecycles. The VM is long-lived and has a stable identity. The pod is disposable. When the VM reboots, gets evicted, or live-migrates, the pod underneath is destroyed and a new one is created.
That matters because a VM’s IP is load-bearing. Firewall rules, load balancer entries, and DNS records all point at it. On Kubernetes, standard pod IPAM ties the address to the pod, so a new pod would mean a new IP, and a changed IP is what breaks those dependencies. KubeVirt on its own does not carry the IP across a migration. Its issue tracker has a user reporting exactly this, with a maintainer confirming sticky IPs were never built into the project. The network identity needs something to carry it. That something is Calico.
The diagram below shows the difference this makes. Default pod networking on the left, Calico on the right.
How Calico keeps the IP
Calico’s approach is elegant and specific. Instead of building the IPAM Continue reading
NVIDIA OpenShell Secures the Agent. Who Governs the Fleet?
In short: At GTC 2026, NVIDIA released OpenShell, an open source runtime that sandboxes autonomous AI agents with kernel-level policy: what files they can touch, what processes they can spawn, where their traffic can go. It is a serious piece of engineering and it validates something we have argued all year: agent security belongs in the environment, not in the prompt. But agent identity, agent-to-agent governance, and cross-sandbox communication all sit outside its scope today. This post covers what OpenShell does, where it stops by design, and three integration patterns that close the gap with Tigera Lynx.
Most attempts to control AI agents work at the model layer (alignment, system prompts) or the application layer (guardrail libraries, output filters). Both share a flaw: the thing being secured is also the thing doing the securing. A sufficiently confused or sufficiently compromised agent can talk its way past its own instructions.
OpenShell takes a different position, and it is the right one. Put the controls in the environment, where the agent cannot negotiate with them. An agent inside an OpenShell sandbox cannot leak a credential it never received, and cannot call an endpoint the kernel refuses to route.
If that argument sounds Continue reading
Tiered Network Policy: Scaling Kubernetes Security
As Kubernetes clusters scale from a few development sandboxes to massive, multi-tenant production environments, platform teams often find themselves facing a configuration management crisis. A small number of microservices suddenly demand hundreds of individual Kubernetes NetworkPolicy objects. Managing them becomes operationally expensive, auditing them is difficult, and a single developer misconfiguration can easily drop critical production traffic or open a massive security hole.
To scale cluster security without slowing down engineering velocity, we must abandon the flat, uncoordinated rule planes of the past. The solution lies in establishing a clear, multi-layered framework: a hierarchy of trust powered by tiered network policies.
The Core Problem with Standard Kubernetes NetworkPolicy
Standard Kubernetes NetworkPolicy resources are genuinely useful for basic application microsegmentation, but they have major architectural and organizational bottlenecks when scaled across an enterprise:
- Namespace-Scoped by Design: Standard network policies are inherently scoped to a namespace. If your security team mandates a cluster-wide rule, such as blocking all internal pods from querying the cloud provider’s metadata API (169.254.169.254), you have to copy-paste that policy into every single namespace. If a developer creates a new namespace, that guardrail doesn’t exist until someone manually applies it.
- Organizational Friction: Because anyone with Continue reading
Save the Address, Save the Cloud: A Hands-on KubeVirt Live Migration Workshop
In the previous post in this series, we covered why Virtual Machine (VM) Live Migration in Kubernetes is difficult: a VM’s IP is its identity, and the “new” VM on the destination node has to come up with the same IP, this something that Kubernetes is not known for, and on top of that, traffic has to switch over only after network security policies are in place. Calico v3.32.0 delivers all the above and allows you to Live Migrate a VM without any network disruptions and this post is a short, do-it-yourself workshop to achieve it.
In about 5 minutes you’ll bring up a 3-node cluster, install Calico + KubeVirt, run a VM, and migrate it live.
Requirements
- A Linux or a Windows Machine preferably WSL2 (Mac Is not supported by KubeVirt)
- Docker or Podman with at least 8 GB RAM
- kubectl
- KIND (v0.31.0)
- virtctl (v1.8.2)
Note: In many Linux distros the default for most kernel parameters are too low, for a kind cluster running KubeVirt. Use the following command to temporarily increase these limits.
sudo sysctl -w fs.inotify.max_user_instances=2048
sudo sysctl -w fs.inotify.max_user_watches=1048576If you face any Continue reading
Save the Address, Save the Cloud (KubeVirt VM Migration Story)
Kubernetes is built for containers, and it’s been doing that since it used to run docker as an engine for its containers. But what if you want to add VMs to the mix? After all, containers are ephemeral and don’t require fixed IPs as they shift the identity toward labels, but VMs on the other hand are tied to IP addresses and in some cases MAC addresses.
This brings us to this blog about VM migration and IP preservation. Unlike a pod that can be part of a deployment and run in a swarm of stateless endpoints, a VM is a stateful machine run by hypervisor like QEMU and extended to Kubernetes via KubeVirt Custom Resource Definitions (CRDs).
There Is Something About KubeVirt
KubeVirt is an abstraction layer between the underlying hypervisor (QEMU) on your machine and Kubernetes. Its job is to manage a VM’s lifecycle and provide the necessary requirements for a VM to be a native resident in Kubernetes. These requirements are CPU, Memory, Networking, etc.
KubeVirt does this by wrapping each VM in an ordinary Kubernetes pod called virt-launcher. Inside that pod, KubeVirt runs libvirt and QEMU, and the “VM” is really just a process scheduled, networked, Continue reading