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

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

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

How Lynx Works: A Technical Walkthrough

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:

1. 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.
2. 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 Continue reading

Multi-Layer Policy for Securing AI Agents

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 Continue reading

Why we need a unified approach to Kubernetes environments

Today, organizations struggle managing disparate technologies for their Kubernetes networking and network security needs. Leveraging multiple technologies for networking and security for in-cluster, ingress, egress, and traffic across clusters creates challenges, including operational complexities and increased costs. For example, to manage ingress traffic for Kubernetes clusters, users cobble together multiple solutions from different providers such as ingress controllers or gateways and load balancers for routing traffic, as well as Web Application Firewalls (WAFs) for enhanced security.

Despite the challenges it brings, deploying disparate technologies has been a “necessary evil” for organizations to get all the capabilities needed for holistic Kubernetes networking. Here, we’ll explore challenges this proliferation of tooling introduces, and provide actionable tips for today’s platform and security teams to overcome these issues.

Challenges Managing Multiple Technologies

The fragmented approach to networking and network security in Kubernetes leads to challenges and inefficiencies, including:

• Operational overhead: Each technology comes with its own learning curve, setup, configuration, integration, and maintenance requirements. This leads to a challenging user experience.
• Increased costs: Licensing and operational costs accumulate as more tools are deployed.
• Scaling challenges: As clusters grow or spread across diverse environments, ensuring consistent and secure networking becomes harder.
• Security gaps: Disjointed solutions Continue reading

Calico WireGuard support with Azure CNI

Last June, Tigera announced a first for Kubernetes: supporting open-source WireGuard for encrypting data in transit within your cluster. We never like to sit still, so we have been working hard on some exciting new features for this technology, the first of which is support for WireGuard on AKS using the Azure CNI.

First a short recap about what WireGuard is, and how we use it in Calico.

What is WireGuard?

WireGuard is a VPN technology available in the Linux kernel since version 5.6 and is positioned as an alternative to IPsec and OpenVPN. It aims to be faster, simpler, leaner and more useful. This is manifested in WireGuard taking an opinionated stance on the configurability of supported ciphers and algorithms to reduce the attack surface and auditability of the technology. It is simple to configure with standard Linux networking commands, and it is only approximately 4,000 lines of code, making it easy to read, understand, and audit.

While WireGuard is a VPN technology and is typically thought of as client/server, it can be configured and used equally effectively in a peer-to-peer mesh architecture, which is how we designed our solution at Tigera to work in Kubernetes. Using Calico, Continue reading