A10 Networks Field CISO Jamison Utter on Securing Autonomous AI

AI security conversations have tended to focus on familiar threats in unfamiliar forms: prompt injection, data leakage, malicious actors, and compromised models. But as AI moves from experimentation into production, and from tools that generate answers to agents that independently pursue goals, the more consequential risk may be much simpler.

What happens when an AI agent does exactly what it was asked to do, but accomplishes that goal in a way no one anticipated?  That distinction is becoming increasingly important as organizations build agentic applications that can interact with APIs, systems, data, and other enterprise resources, according to Jamison Utter, Field CISO at A10 Networks. Unlike traditional software, he says, these applications do not always follow the same predetermined sequence of actions. An agent can choose how to pursue its objective, which tools to use, and what steps to take along the way. As a result, security teams must account not only for attackers attempting to compromise an application, but also for legitimate agents whose autonomous actions can produce unintended consequences. The agent itself is becoming the new perimeter. 

That shift has significant implications for enterprise security. Visibility must extend beyond knowing whether an agent acted to understanding why it acted. Zero Trust principles must increasingly apply to agents just as they apply to human users. Red teaming must test logic and unexpected outcomes rather than simply search for vulnerable code. Governance must also move closer to the technical controls governing what autonomous systems can do. 

Utter explains what this new security model looks like in practice, from agent and MCP discovery to AI gateways, explainability, control, and the emerging challenge of securing logic itself. The result is a different way of thinking about AI security: start with how AI is being used, understand the potential consequences of autonomous action, and build controls around the applications and business outcomes that matter.

Jamison Utter: The first problem is that we’re not distinguishing among the different use cases for AI security. Often when somebody says AI security, they mean the entire corpus of things we can do related to AI. That's using it in applications, that's agentic behavior, that's desktop use. And truly, saying AI security is a little bit like saying cybersecurity. There are a lot of important nuances and layers.

JU: When I spend time in the field talking to CISOs and business leaders who are really implementing agentic applications, there's been so much focus on prompt injection, hijacking, and all that stuff. But that is not how the agents are being implemented. If we think about how an agent is used in an application, it is not an open prompt a user can speak to directly. They go to a page and fill out numerous questions, like a form. That creates the agent's goal. So, it's a structured input for the agent in the first place. There's not much room in many drop-down boxes to inject some sort of strange prompt to hijack the agent.

So, I feel like we're focused on bad guys. This is pretty typical of the vendor industry: chasing ambulances and focusing on bad guys rather than the truth of what's happening with agents, which isn't goal hijacking or bad guys doing bad things. It's the agents relentlessly pursuing the goal they were given, sometimes to the detriment of the company they're doing it for. And they are only goal-driven, and they are tireless.

The A10 Networks Approach. These are lessons we’ve learned over years supporting our financial customers. We have guardrails to help with prompt injection, bias, and all the other things you would normally have. Ultimately, though, we found the real attack or damage surface lies somewhere beyond the MCP. So we offer MCP control and discovery, agent control and discovery. And by control, I mean a kill switch, the literal ability to tell an agent to stop running right now. For us, the frontier of today is that, and the frontier of tomorrow is the ability to understand what agents are doing and why.

JU: The term I like to use is explainability. Observability is not enough. I need to understand why. Why did the agent choose to use the tool that way? Where we are today is highly focused on agentic applications rather than just the guardrail and bad prompt-leakage problem.

JU: Absolutely. The application of tomorrow, maybe not quite yet today, will be a user going to a website, let's say to buy insurance. They will answer a series of questions, much as we already do today, about their age bracket, health, family, and what they want insured (houses, boats, and the like). This becomes an agent's goal: to find the right policy for the user. Instead of us doing the searching and understanding, an application goes out and does it for us. The application of the future isn't just intelligent in the sense that it's AI-enabled; it's agentic.

JU:  It’s a massive fundamental shift in cybersecurity. Previously, when an application works correctly, meaning it is doing what it is supposed to do, it is relatively straightforward to secure because security teams know the inputs and outputs, what is expected and unexpected, and what good and bad look like. When an application is compromised, though, it can behave in unintended ways.

That is what hackers look for: ways to break the code and get a different response than the one it was designed to provide. That is securing code. But what's changed is that underneath our applications now, under agentic applications, is a logic layer. And that drives the agent's actions. We’re securing a nondeterministic logic process, the layer that drives the agent and, ultimately, the application. It’s a very different sort of thing because we're not just securing it against bad guys; we're securing it against itself.

The A10 Networks Approach: Red teaming is an important part of that. And we have to think about the difference between AI red teaming and traditional red teaming. I'm a traditional red teamer from way back. And AI red teaming is very different because I'm not looking for a code problem. I'm looking for a flaw in logic. When we think about application red teaming in the future, we have to red team the agent and let the agent's goal play out. We have to understand how it might use tools in strange ways and what the unexpected outcomes are.

JU: This is how we find logic flaws. When we look at a logic train, we look at how one model might drive an agent versus another one. Different models have different structures for predicting the next word. Remember, an LLM only predicts text. Really, it predicts tokens, and text is made of tokens. Each model will behave differently given certain inputs, based on its probability weights. That’s the most important piece for us to understand. Did we structure the goal incorrectly, something we can fundamentally control? Did we give it the wrong constraints, or is there an underlying problem in the logic model driving the agent that we need to address by switching between models?

That's why explainability matters. I have to understand what made it get off course and how to correct it. In a way, it's a little like psychology. If we think about a therapist, in analyzing a series of actions, we have to figure out what made us get off course in the first place. It’s almost like psychoanalyzing our AIs now to figure out why they didn't execute like we thought they would.

The A10 Networks Approach. For us, it starts with adding observability across the entire chain. By that, I mean tying together the full stack, from the initial input, whether it comes through a webpage or an API, through the gateway and guardrails, to the LLM and MCP. All these steps need to be connected as a single thread: this was the input, this was the output, and these were the steps the agent used to get there. We need to know where the agent is running because each agent platform can behave differently. We also need to connect its actions to the original request and final output as a single thread. For us, that’s the guiding light: how do we create that chain of observability across the whole stack?

JU: I see it on the opposite side of securing the AI directly. The need for things like Zero Trust has never been greater because I can't trust the agent. I don't know what it'll do. More than ever, we absolutely have to lock down the environment downstream from an agent. We can put guardrails and other controls around the agent, but when we turn it loose in our environment, we have to understand what it's doing downstream and where it's going.

We have to think about the agent itself as the perimeter.

MW: For decades, we have thought about deterministic processes. The agent, though, is more like a user: there’s no certainty about how it'll go about its tasks throughout the day, which is why we created Zero Trust.

I have to put a series of guardrails around a user, the permissions and the things they can get to, so they don't get to a folder, maybe even by accident, that contains the salaries of everybody in the company. If the agent is capable of autonomous action, it has permission sets, sometimes equal to a user, sometimes equal to some special user because it's been treated separately as an agent. That’s what's really changed—instead of thinking of agents as another automatic process, the agent is a new user.

The A10 Networks Approach. We’re very focused on the application. User-based AI risks are a different problem requiring different controls. Our focus is the agentic application and how to secure, maintain, and control it across the process. That's everything from red teaming to agent control and discovery, through API control and discovery. So we’re focused on the application's core business function.

MCP lets us execute pretty much anything as a tool. To a certain extent, anything can be embedded within an MCP. Anything on a particular MCP server that's being advertised as a tool is available to all agents subscribed to that server.

Early on, I saw a number of companies run up an MCP server. They had an agentic application; they got it to a point where they really were happy with it. It's working pretty well. They’re thinking about going to production. They spin up agent number two and start adding tools to the MCP server for the new agent. Well, the old agent gets those tools too, and suddenly things go haywire. There’s always a boogeyman. Somebody could add an unexpected tool, or a bad one. Now there is a problem across the schema of what MCPs are in play, what tools they advertise, and which agents access those tools. It becomes a tool sprawl problem, not dissimilar from regular IT. And there's no good way to say an agent can use a tool because agents don't have identities. Most organizations still lack mature identity management capabilities for agents or tools.

A gateway can really help because, ultimately, AI transactions are keys. Think of a TLS signature or an SSL handshake: they use a key much like that. It’s actually an API key. That’s how we track what's happening in the AI world. There isn’t really a notion of users or anything like that; they’re just keys. And the keys are there because that's how the AI vendors bill us. They're tied to your billing account. But if we have a gateway, it can help us map actual users or groups to keys. And that can often help us understand what's happening. We can give the agent a key so it has an identity. It’s like adding a secondary layer to the transaction process that, in a sense, makes it human-readable.

Transactions come in, get routed through guardrails, then exit the guardrails. They go back to the LLM and from the LLM to the MCP. All of that goes through the gateway. We can get visibility into what's happening.

The A10 Networks Approach. A10 is trying to tie the chain together. It's a core component in the center of the visibility chain of what's actually happening. Those two things are really valuable for a gateway to provide. We just announced the availability of our AI Gateway, and it has a few interesting functions. Of course, visibility is key and fundamental to how it works. It also has a user mapping function that lets us map users and groups to keys, flattening that abstraction layer. It also has a model routing function, which is probably more interesting to developer sets than application sets.

Many developers like to use the newest frontier model for more accurate coding. But we can do cost-based routing. The gateway examines a prompt and determines how hard that prompt is to fulfill. Does it need reasoning? Or is it a certain type? Is it a medical question, a math question? Then, behind that, you can route it to different models. It’s a smart gateway, more than just a standard API AI gateway.

That’s always been a difficult question for me because it also depends on what governance we're talking about. Every company has its own governance model. And now that we're in the age of securing logic, governance has to be part of the security structure. We can build governance rules now because AI uses logic, and most governance is more of a logic question than a data question. We can build those into our guardrails now, where we couldn't before, which is pretty neat.

Maybe that's the frontier: building governance rules into technical controls. They're logical, not binary. Before, we could say yes or no—you can upload that document or not—but there wasn't logic underneath it. A user couldn’t upload a document because it contained something. A human had to decide it contained things that couldn't be uploaded. Now, though, we can build a framework that tells AI a user can't speak about those topics and doesn't process logic on them. We might be entering an era where we can implement governance truthfully. Now that we're in the logic era, we might be able to start building controls that enforce intent and structure.

Study psychology. Because you're securing nondeterministic logic. My advice is to understand the technology at its core: what AI actually is and how it actually works. That will really help you. In workshops I've taught, both internally and externally, the first thing I write on the whiteboard is “the LLM can't …” because it only predicts text. Then, as we go through questions, we ask, well, can it? The LLM can't because it only predicts text. That's all it does.

The A10 Networks Approach. We have fundamentally shifted our entire portfolio toward the application—from application stack protection with ThreatX Protect to the acquisition of TrojAI to all our internal research and development efforts. That's all been about following the shifting application: first one that's API-centric, now one that's agentic. Basically, I don't want to say we skipped the AI step, but we kind of did, as we realized the application isn't AI; it's agentic. We had to go from just guardrails to “holy moly, we have to control these agents and stop them and find them and discover them and understand what they're doing.” Our entire portfolio alignment—the direction of everything we're developing, everything we're doing, everything we've acquired is 100% focused on the agentic world.

The rise of agentic AI does not make cybersecurity fundamentals obsolete. Rather, it changes where and how they need to be applied. 

Organizations still need visibility, identity, access controls, application and API security, governance, and Zero Trust. But autonomous agents introduce something traditional applications largely did not: a system that can independently determine how to pursue a goal. In that environment, simply knowing that an action occurred is no longer sufficient. Security teams increasingly need to understand the decision chain behind it, the resources an agent accessed, the tools it chose, and why its logic produced a particular outcome. 

That makes explainability, observability, and control central to the next phase of AI security. It also makes basic discipline around AI adoption more important. Organizations need to know where AI is being used, what outcome each use case is intended to produce, and whether AI is actually the right technology for the problem. Different AI applications create different risks and require different controls; treating “AI security” as one monolithic problem can obscure those distinctions. 

Ultimately, Utter says, successful AI adoption will be defined by measurable outcomes. Successful organizations will use AI to augment people, improve applications and customer experiences, and accomplish things their teams could not achieve as effectively before. 

For security leaders, that requires a corresponding mindset shift. The application is becoming agentic. The perimeter is moving with it. And securing that future means learning to protect not only what software can do, but how autonomous systems decide what to do next.

EXPLORE MORE FROM A10 NETWORKS

Continue the conversation. Explore more perspectives on securing agentic applications and preparing enterprise security for autonomous AI.

Watch the A10 Networks TechTalks Webinar →
Download the Partner Insights Brief →

ABOUT PARTNER INSIGHTS

Partner Insights is a TechChannels sponsored content offering developed in collaboration with TechStudio, bringing technology leaders and industry experts together to share perspectives on the challenges, trends, and innovations shaping today’s technology landscape.