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 variable

Claude Code allows its model endpoint to be configured through the environment.

Instead of connecting directly to Anthropic, point it at the Lynx gateway.

export ANTHROPIC_BASE_URL="https://<lynx-gateway>/llm/anthropic"

That’s the entire change on the developer’s machine.

No endpoint agent. No daemon. No certificate installation.
No rebuilt development environment.

The next model turn goes through Lynx, and every model turn after it does too.

That small change turns otherwise disconnected model calls into something more useful: a coding session that can be observed, governed, and recorded.

Coding sessions list in Lynx

Coding session summary in Lynx

What this gives you

Instead of seeing another HTTPS connection from a developer laptop to an AI provider, the platform can start answering important questions:

Which coding sessions are using AI?
Which model providers and models are they using?
What information is being sent to those models?
Which policies were applied?
Which MCP tools were called through the gateway?
Did the session spawn sub-agents?
What happened during a particular coding session?

That is a significant improvement over an unmanaged agent talking directly to a model provider.

What this does not do

A gateway gives you a strong answer to what left the building, not what happened on the machine.

Local tools run on the laptop and do not transit the gateway.
Example: Claude Code reads a file, edits source code, or runs a shell command locally.
Some of that activity may appear in model traffic (e.g., tool calls, results, retrieved files, or other context).
That is observation, not enforcement.

A governed laptop is not a sandbox

Routing Claude Code through a gateway does not suddenly give Lynx control over the developer’s machine.

Every model turn that transits the gateway can be governed.
MCP calls can also be governed when the MCP server is reached through the gateway.
Local tools are different. The gateway isn’t on that execution path and cannot prevent it.

But that is observation, not enforcement.