The inference path is the traffic path: Where AI security has to live

Abbas KudratiField CISO for APCJ | F5

In an earlier blog, I argued that against a Mythos-class model, where you intercept an attack matters more than whether you detect it, and that the traffic path is the one control point a reasoning adversary cannot route around. This post takes that argument inside the enterprise: what actually travels along that path once an organization puts AI to work, and why the answer changes how we design security.

A few months ago, I sat in on an enterprise AI discussion that started the way most of them do. Which model should we use? Should we run it ourselves or call a public one? How do we lift accuracy and cut hallucinations? Good questions, all of them. But nobody asked what happens after the model is chosen.

Here is what happens. A user sends a prompt. An application receives it, checks who the user is, pulls in context from a document store or a database, and calls a few internal APIs. An agent may decide a tool is needed. The assembled request reaches the model, which generates tokens. Those tokens might be an answer. They might also be the instruction that triggers the next API call, the next workflow, or a change in a system of record.

Seen that way, the model is one component in a much longer chain. That chain is what I mean by the inference path, and the observation this post rests on is a simple one: The inference path is the traffic path.

What the inference path actually is

Training teaches a model. Inference is the moment the trained model is put to work. When an employee asks an enterprise assistant to “summarize the latest results and draft an email for the leadership team,” the request takes a journey something like this:

User → Application → Identity → Context and retrieval → APIs → Agent → Model → Tools → Model → Response → User

Every hop on that journey is network and application traffic. It has endpoints, latency, routing decisions, and an identity attached to it. It carries data, it consumes budget, and increasingly it carries the authority to do something.

My colleague Lori MacVittie made a related point earlier this year: inference is production runtime behavior, and it behaves like an application tier, with users, traffic patterns, latency sensitivity, failure modes, cost constraints and security risks. Kunal Anand, F5’s Chief Product Officer, describes the same journey as a new supply chain of value, from prompt to ingress, through workflows and inference, and back to the user. Once you accept that framing, the security conversation has to move with it. Mani Ganesan, F5’s VP of Product Management AI Security, looks at what that shift means for the attack surface in his recent blog, “Your AI is now an attack surface. Are you ready to secure it?”

Four assumptions worth retiring

As CISOs bolster AI security, here are four assumptions we all need to let go of:

• “It’s all about the model.” The model gets the attention because it is the visible part. But the prompt may carry sensitive data, the retrieval step may pull confidential records, the agent may hold API credentials, and the tool it calls may be able to write to a database. Securing only the model is like hardening a database while ignoring the application and APIs that talk to it. The attack surface is the path.
• “Pilot to production is a scaling exercise.” A pilot typically has one model, a handful of users, one application, and manually approved access. Production looks nothing like that. F5’s 2026 State of Application Strategy Report found organizations coordinating an average of seven AI models, with 77% saying inference, not training, is now their dominant AI activity, and 52% chaining or orchestrating multiple models together. That is not the same architecture with more users. It is a different architecture, and the security model has to change with it.
• “Speed, security and governance are separate layers.” Consider a prompt containing personal information. Somewhere between the user and the model, that request has to be inspected, redacted where policy requires, routed to an approved model, monitored and logged for audit, all while it is in flight. The same decision point that asks, “Where does this request go?” now also has to answer, “Should it go there at all?” That is one traffic-processing decision, not three functions bolted together.
• “We can stitch point tools together.” An organization can certainly assemble the stack: API gateway, WAF, DLP, IAM, AI guardrails, a model gateway, observability, SIEM, agent controls, MCP security. None of those tools is bad. The problem is the seams between them. Picture one request crossing six control points, each with its own policy engine and identity context. Who knows that the user who typed the prompt is the same identity now invoking the tool? Who can see that the API call, the model call, and the tool call are one transaction? Who can enforce a consistent policy across the whole journey, and prove afterwards what happened?

My previous blog made the point that seams are where a reasoning adversary looks first. The same is true of a well-meaning agent that simply wanders off-policy.

Once inference is treated as traffic, the path itself becomes the natural place to enforce identity, policy, data protection, and agent control, on the way in and on the way back out.

When traffic starts carrying intent

AI adds new stages to the familiar request-routing-policy-response sequence: context, retrieval, orchestration, tool invocation. But the deeper change is in what the traffic carries. Conventional traffic carries data. Inference traffic carries intent, context, and decisions.

That matters most with agents. An assistant that answers a question is one thing. An agent that can read customer records, raise tickets, send email, execute code, change infrastructure, or place a payment instruction is something else entirely. The inference path becomes an action path, and the blast radius of a bad decision stops being informational.

The inference transaction is the new unit of security

Traditional security reasons about users, devices, applications, APIs, workloads, and data. Zero trust taught us to ask not just “Who are you?” but “What are you trying to reach?” AI systems demand a third question: “What are you asking the AI to do, with which data, through which model, and what actions could this interaction trigger?”

Answering that requires context that no single existing control holds. Consider an authenticated user of a finance copilot, whose request pulls confidential financial data into an external model, hands off to a finance agent, and ends in a call to the ERP API to create a payment instruction. The user’s identity alone cannot carry that decision. The whole transaction has to.

That is why identity, application security, API security, AI security, and traffic management are converging. The unit they converge on is the inference transaction: identity plus prompt plus context plus model plus data plus tools plus output plus action. It is a far richer object than an HTTP request.

Once you think in transactions, security stops being a checkpoint and becomes a loop. Before inference, the questions are who is asking, what data they are supplying, whether the prompt is hostile, and which model should receive it.

During inference, they are whether the request is within policy and budget, and whether an agent is attempting a tool call it was never authorized for. After inference, they are whether the response is safe to return, whether it triggered an action, and what needs to be logged. Each answer has to be made where the traffic flows, because that is the only place all the context exists at once.

What this means for CISOs

We have seen this pattern before. Monoliths became distributed applications, client-server became APIs and microservices, and perimeter security gave way to identity- and application-aware controls. Each time, the infrastructure that delivered and secured traffic became strategically important. Inference is the next turn of that cycle.

So the question to put to your architecture team is not only where your models live. Ask where the inference traffic flows, what it carries, what it can reach, what decisions it makes and what actions it can trigger. Then ask the hardest one: where can we enforce policy on all of that without slowing the application down?

Because in the AI era, the most important security boundary may no longer sit around the model. It sits on the path to and from it.

To learn more about how F5 approaches this, visit the F5 AI Gateway page. Also, be sure to read my previous blog post, “Stopping frontier AI at the wire: Why inline control Is a core advantage against Mythos-class models.”

About the Author

Abbas KudratiField CISO for APCJ | F5

More blogs by Abbas Kudrati