Over the past year, I’ve spent a lot of time talking with engineering and platform teams about how they’re deploying AI agents. The conversations are changing. Six months ago, most were focused on getting agents into production. Now, increasingly, the question is how to secure them once they’re there.
It’s a familiar transition. We’ve seen it with containers, Kubernetes, microservices, and cloud infrastructure. New technology gets adopted, architectures evolve, and security has to catch up with how systems actually operate.
AI agents introduce some interesting challenges, though. Unlike traditional applications, agents make decisions about what to do next. They interact with models, invoke tools, communicate with other agents, access data, and execute code. A single user request can trigger a sequence of actions across multiple systems, sometimes with very little human involvement.
That changes the security problem.
An agent can be properly authenticated, operate within its assigned permissions, and still be led into doing something nobody intended.
It’s one of the reasons I believe securing agentic AI requires a defense-in-depth architecture, with controls operating at both the application and runtime layers.
The gateway is an important part of the architecture
AI gateways have become a natural place to introduce security controls.
They sit in the path between agents, models, and tools, providing a central point for authentication, authorization, policy enforcement, and observability.
At this layer, we can start answering questions that traditional infrastructure security was never designed to address.
Which agent is making this request? Which model is it accessing? Is it permitted to invoke this particular tool? Is it acting on behalf of an authorized user? Does the request contain sensitive information?
These are application-level questions. They require an understanding of agents, identities, tools, and the protocols connecting them.
A network policy that allows a workload to communicate with a particular IP address cannot distinguish between an agent retrieving information from an approved tool and the same agent invoking a destructive operation through that tool.
An AI gateway can make that distinction, provided the interaction passes through it and the necessary context is available.
This is a significant step forward, but it is only one part of the security architecture.
What happens outside the gateway?
Consider a coding agent running inside a Kubernetes workload.
The agent sends a request to a model through a gateway. The request is authenticated, evaluated against policy, and permitted.
The model responds with a suggested course of action. Perhaps it asks the agent to inspect a configuration file, execute a command, or retrieve information from another system.
The agent then carries out that action.
Some of those operations might involve another request through the gateway. Others happen entirely within the workload.
Reading a local file, executing a binary, accessing a credential, or spawning another process doesn’t necessarily involve a gateway at all.
And this is where the distinction between application-layer and runtime security becomes important.
The gateway can authorize the agent’s interaction with a model or tool. It cannot, by itself, enforce every action the agent subsequently performs inside its execution environment.
An agent might have legitimate permission to call a model but no legitimate reason to read a sensitive credential file. It might be authorized to execute diagnostic commands but should not be able to launch an arbitrary binary or establish a connection to an unknown external destination.
These are different security decisions, made at different enforcement points.
We need both.
Bringing runtime security into the picture
This is where the Linux kernel becomes particularly useful.
For years, Kubernetes security has relied on controls operating below the application. Network policy, workload isolation, and runtime security all take advantage of the fact that applications ultimately depend on operating system resources.
AI agents are no different.
Regardless of which framework an agent uses, or which model it communicates with, its runtime operations eventually interact with the operating system.
Files are opened. Processes are executed. Network connections are established.
Technologies such as eBPF and Linux Security Modules give us mechanisms to observe and constrain those operations without requiring every agent framework to implement its own security controls.
For example, runtime policy can restrict which files a workload may access, which executables it may launch, and which network destinations it may contact.
This is particularly valuable when an agent encounters an unexpected or malicious instruction.
A prompt injection might convince an agent to attempt an operation outside its intended responsibilities. The agent may consider that operation a perfectly reasonable next step. But a runtime policy can still prevent it from accessing a protected file or executing an unauthorized program.
Of course, kernel enforcement doesn’t understand the intent behind an agent’s actions. It knows about files, processes, sockets, and workloads, not whether a particular instruction makes sense in the context of a user’s original request.
That’s precisely why these layers need to work together.
Application-layer security understands the interactions between agents, models, and tools. Runtime security constrains what the underlying workload is capable of doing.
Neither replaces the other.
The agents you don’t know about
There’s another problem that comes up regularly in conversations with platform teams: not every agent is necessarily using the infrastructure you’ve put in place to secure it.
A developer might introduce an agent framework into an existing application. Another team might deploy a service that communicates directly with a model provider. A third might be experimenting with autonomous coding agents inside development environments.
Not all of these will appear in a central agent registry, and not all will be configured to use an approved gateway.
This creates a visibility problem before we even get to enforcement.
You cannot apply meaningful policy to agents you don’t know exist.
Runtime discovery provides another layer of defense here. By observing workload behaviour and network activity, we can identify potential AI-related activity independently of whether an application has been registered or instrumented.
That doesn’t mean every connection to a model provider identifies an autonomous agent. A conventional application making an LLM API call can look similar at the network layer.
Discovery needs to combine signals and provide enough context for teams to distinguish genuine agents from other AI-enabled workloads.
But the architectural principle is important: security shouldn’t depend entirely on applications volunteering to participate in it.
The same principle has guided much of our work in Kubernetes security over the years.
Identity has to follow the agent
As agents begin communicating with other agents, identity becomes another important part of the architecture.
In a traditional application, we can often make authorization decisions based on the identity of the workload making a request.
With agentic systems, that’s no longer sufficient.
Imagine a user asks an agent to investigate a production issue. That agent delegates part of the investigation to another agent, which invokes a tool to retrieve diagnostic information.
By the time the tool is called, we need to understand more than which Kubernetes workload originated the connection.
We need to know which agent is acting, on whose behalf, and what authority has been delegated to it.
Those are distinct identities and permissions.
Standards such as SPIFFE, OIDC, and OAuth 2.0 Token Exchange provide useful building blocks for workload identity and delegated authorization. The challenge is connecting those identities to the agent interactions and policy decisions happening at the application layer.
We also need to preserve the distinction between an agent’s identity and the identity of the workload running it. Multiple logical agents can execute within the same process or container, and the operating system cannot inherently distinguish between them.
This is another reason a layered architecture matters.
The gateway can reason about logical agent identity and delegated authority. The runtime layer can enforce boundaries around the workloads and processes executing those agents.
Together, they provide a more complete security model.
We’ve seen this architectural pattern before
One of the reasons this approach feels natural to me is that we’ve spent years solving a similar class of problem in Kubernetes networking and security.
Kubernetes NetworkPolicy introduced a declarative way to express which workloads should be allowed to communicate. The policy is written in terms of workload identities and selectors, while enforcement happens through the underlying networking infrastructure.
We separated the language used to describe security intent from the mechanisms responsible for enforcing it.
Agentic AI needs a similar separation, but with a richer understanding of identity and behaviour.
At the application layer, policies should describe which agents can interact with which models, tools, data, and other agents, and under what conditions.
At the runtime layer, policies should constrain the underlying capabilities available to those workloads.
And across both layers, we need observability that connects the decisions and actions into a coherent picture.
It’s not enough to know that an agent called a model. We also want to understand which identity authorized the interaction, which tools were invoked, and what happened in the runtime as a consequence.
That correlation is what turns a collection of individual security controls into something much more useful.
Defense in depth has to be practical
There’s a temptation with any new security architecture to start with an ideal end state: every agent registered, every interaction authorized, every workload restricted, and every action recorded.
That’s a reasonable destination, but it isn’t how most production environments look today.
Organizations already have applications using models, teams experimenting with agent frameworks, and increasingly autonomous workloads running across their infrastructure.
Introducing security cannot mean stopping everything until every agent has been rewritten to integrate with a new control plane.
A more practical approach is to start with visibility.
Discover what is running. Understand which models and tools are being accessed. Observe agent behaviour and establish a baseline.
From there, introduce policies in observation mode, understand their impact, and progressively move towards enforcement.
The same applies to runtime controls. Begin by understanding which files, processes, and network destinations workloads actually need, then constrain those capabilities as confidence grows.
This approach also makes security less dependent on individual agent frameworks.
The ecosystem is moving quickly. Frameworks, protocols, and models will continue to change. Security architecture should be able to accommodate those changes without requiring every application to be redesigned.
How we’re approaching this with Lynx
These principles are shaping how we’re building Lynx at Tigera.
We’re bringing together agent discovery, identity, application-layer policy, observability, and kernel-level runtime enforcement into a layered architecture.
The gateway provides policy enforcement for agent, model, and tool interactions. Runtime controls use eBPF and Linux security mechanisms to constrain workload behaviour independently of the agent framework.
Discovery helps identify AI activity that hasn’t been explicitly registered, while the identity and observability layers provide context across interactions.
There’s still engineering work to do, particularly around transparently bringing unmanaged agent traffic under application-layer enforcement and maintaining identity context across increasingly complex workflows.
But the direction is clear.
We don’t believe securing AI agents should require choosing between a gateway and runtime security.
The gateway understands what the agent is trying to do at the application layer. The runtime layer controls what the workload is capable of doing underneath it.
Both are necessary, and neither should depend entirely on the cooperation of the agent being secured.
Security has to follow the execution
As AI agents become more autonomous, the security boundary is moving.
Traditional application security was largely concerned with controlling access to services and data. Agentic systems add another dimension: software that can independently decide which actions to take using the access it has been given.
That doesn’t make our existing security principles obsolete. If anything, it makes them more important.
Least privilege, strong identity, policy enforcement, workload isolation, and defense in depth are all familiar concepts.
What changes is where and how we apply them.
A gateway is an important enforcement point, but it isn’t the entire execution environment. An agent’s actions extend beyond the requests it sends to models and tools, and our security architecture needs to extend with them.
The goal isn’t simply to authorize what an agent asks to do. It’s to establish boundaries around what that agent can actually do.
That’s the foundation I believe we need as agentic AI moves from experimentation into production.
