AI security used to be discussed like a model problem.
Which model is allowed? Where was it trained? Can the vendor keep our data? Is the output reliable enough for the workflow?
Those questions still matter. They are no longer sufficient.
The new control point is the inference path: the live route between users, applications, APIs, agents, prompts, tokens, model routers, retrieval systems and identity stores. That is where sensitive context enters. That is where tool calls happen. That is where the model stops being a procurement object and starts behaving like production infrastructure.
F5’s 2026 State of Application Strategy materials make the shift hard to ignore. F5 says 78% of organizations now run AI inference themselves, while the average organization coordinates seven AI models. It also says 77% report inference, not training or tuning, as their dominant AI activity (F5, F5 investor release).
That is not a model-selection story.
It is a perimeter story.
The Problem
Enterprise AI crossed into the same territory as application delivery. Traffic moves across clouds, SaaS endpoints, internal APIs and user-facing applications. F5 reports that 93% of organizations operate across multiple clouds and 86% distribute applications across hybrid multicloud environments (F5 investor release).
Inference now rides that same architecture.
The difference is that AI traffic carries instructions, not just requests. A conventional API call usually has defined fields and predictable side effects. An inference call can contain user intent, customer data, retrieved documents, system instructions, tool permissions, memory, identity claims and policy context.
That makes the old perimeter model awkward.
The firewall sees a request. The model sees an instruction. The application sees a workflow. The security team sees a data-handling event. None of those views is complete on its own.
F5’s security figures point in the same direction. Its release says 88% of organizations have faced AI-related security challenges and 98% are preparing for agentic AI systems that need identities, permissions and guardrails. It also says control is moving to prompt, token and API layers, with nearly 29% identifying prompt layers as the top delivery mechanism and 23% prioritizing token layers (F5 investor release).
The vendor framing is self-interested. F5 sells application delivery and security infrastructure. But the operating pattern is real. Once inference becomes distributed and embedded in business workflows, the perimeter follows the inference request.
That perimeter is made of prompts, tokens, routing decisions and identity.
The Analysis
Model governance and runtime governance are different jobs.
A model registry can say which models are approved. It cannot, by itself, answer whether a payroll assistant should send a prompt to an external model, whether a retrieved document should enter the context window, whether the model can call an HR API, or whether the response should be logged, redacted or blocked.
Those are inference-time decisions.
They happen too late for training governance and too early for post-hoc audit. They need policy in the path.
That is why multi-model operation matters. F5 says the average organization is coordinating seven models. In practice, that means enterprises are already doing model routing. They route by latency, cost, jurisdiction, accuracy, modality, vendor risk and task type.
Every routing rule is also a security rule.
Send a prompt with customer PII to the wrong endpoint and the problem is not that the model was bad. The router failed to enforce data policy. Let an agent use the same identity for reading documents and changing records and the problem is excessive authority in the runtime.
OWASP’s 2025 Top 10 for LLM Applications is useful because it describes risks at the application boundary: prompt injection, sensitive information disclosure, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses and unbounded consumption (OWASP PDF). These are not abstract model risks. They are failures in how applications accept input, expose context, call tools, trust output and meter use.
In other words, they live in inference.
NIST’s Generative AI Profile makes a similar point from the risk-management side. It treats generative AI risk as a system problem involving data, privacy, security, monitoring and incident response, not just a model-card exercise (NIST, NIST AI 600-1 PDF).
The enterprise control stack has to meet that shape.
Authentication is not enough. The system needs to know who the user is, which application is acting, which agent is in the loop, which model is being called, what data classification is present, which tools are available, and what output can trigger.
Observability is not enough either. Logging prompts after the fact helps investigations. It does not stop a prompt-injection chain before it calls a tool, prevent a router from sending regulated data outside the approved boundary, or cap runaway token use before the invoice arrives.
The inference path needs real controls: policy-aware routing, identity binding, prompt and response inspection, retrieval access checks, tool scoping, token-budget enforcement, output validation and audit trails.
That sounds heavy. It is also what production looks like.
The Implications
The biggest mistake is treating AI security as a separate specialty stack beside application security.
AI applications are still applications. They still need authentication, authorization, network controls, secrets management, logging, change control and incident response. The difference is that the request body can try to change the system, and the response may become input to another system.
That means CISOs should ask different questions.
Not only: which models are approved?
Ask: where does inference happen, which routers decide model choice, what identities do agents use, which prompts can carry sensitive data, what tool calls are allowed, how are tokens metered, where logs are retained, and what happens when retrieved content conflicts with system instructions?
Procurement should change too. A model provider’s benchmark score is less important than whether the enterprise can enforce policy from user to model to tool. Buyers should ask vendors for prompt-layer controls, token-layer visibility, routing policy, API authentication, logging boundaries, data-retention terms and agent permission models.
The useful architecture is not “one model to rule the company.” That was always a fantasy with a nice slide deck.
The useful architecture is a controlled inference fabric. Different models can answer different tasks. Some run in-house. Some run through external APIs. Some sit near regulated data. Some handle cheap high-volume classification. The value comes from consistent policy.
This will also change incident response.
An AI incident will not always look like a breached database or a stolen key. It may look like a poisoned retrieved document, a prompt-injection path through support, an agent identity with too much access, a router that sent confidential context to the wrong provider, or a token spike that signals abuse before data loss is obvious.
Security teams will need traces that connect user, prompt, document, model, tool, response and action. Without that chain, they will have logs and vibes. Vibes do not survive the first legal hold.
The strategic point is simple. Enterprises are not merely adopting AI. They are operating inference.
Once that happens, the perimeter is no longer the edge of the network or the model catalog. It is the live path where instructions meet data and authority.
Control that path, and AI becomes infrastructure.
Ignore it, and the model is just the most charismatic unmanaged endpoint in the company.
Discussion
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.