Article Summary
- Teams are adopting generative AI faster than security policy can keep up, and most organizations cannot say with confidence where AI is already running in their environment or what it can reach.
- Runtime is the window between a user sending a prompt and the model returning a response. That window is where AI risk actually occurs, and traditional firewalls cannot see into it because prompts and responses are ordinary language rather than code.
- FortiAIGate applies zero trust principles to that window, inspecting every prompt before it reaches the model and every response before it reaches the user, with data leak prevention, customizable rules, and full logging of suspicious activity.
Securing Generative AI at Runtime: A Guide to FortiAIGate
Most organizations did not decide to deploy generative AI. It arrived. A team stood up an assistant against an internal knowledge base. A developer wired a model into a customer workflow. Someone connected a model to a tool that can query a production database. By the time security is asked to weigh in, the question is no longer whether to allow it. The question is what is already running, and what it can reach.
That is not a failure of governance so much as a reflection of how useful these tools have become. AI is now doing real work in finance, support, engineering, and operations, and the teams adopting it are moving at the speed of their own productivity gains rather than at the speed of a security review. Policy is catching up. In the meantime, the models are already in production.
Liquid Networx helps organizations implement and manage Fortinet security technologies. Earlier this year, Andrew Hammond started a discussion on FortiAIGate and its role in securing AI use. His central point is relevant to any organization working through AI adoption: businesses need practical ways to control how people and applications use AI, what information they share, and what those interactions cost.
Understanding how runtime security works is the first step toward putting those controls in place.
What Runtime Means for AI
Runtime is a narrower idea than it sounds. It is the window between a user sending a prompt and the model returning a response.
That window is short, often a second or two, and it is where essentially all of the risk lives. It is the moment a user might paste customer records into a prompt. It is the moment an attacker might slip in an instruction that overrides the model’s rules. It is the moment the model might return data it was never supposed to surface.
Everything before that window is preparation, and everything after it is forensics. Securing AI at runtime means putting a control inside the window itself, while the prompt is in flight.
Why Traditional Security Misses Runtime Threats
A next-generation firewall inspects network traffic. A secure web gateway governs access to web resources and applies security policies to internet traffic. Both are mature, effective, and necessary.
However, neither control alone provides the context needed to evaluate every interaction with a large language model.
Prompt injection, for example, does not necessarily exploit a software parser or a buffer. Instead, an attacker crafts instructions that influence how a model interprets and responds to a request. The input may be grammatically correct and appear entirely ordinary to a network control.
The risk extends beyond malicious instructions. A user might submit confidential customer information to an AI service without understanding where that information goes or how it may be handled. A model connected to internal data sources might also return information that a particular user should not see.
Traditional network controls can help restrict access to AI services and inspect traffic for known threats. But they generally cannot determine, on their own, whether a prompt contains a malicious instruction or whether a generated response reveals sensitive information.
Two risks follow directly.
First, users may disclose sensitive information through prompts, including personally identifiable information, confidential business data, or regulated records.
Second, attackers may manipulate model behavior through carefully crafted instructions, potentially exposing information or inducing actions that violate the organization’s security policies.
The OWASP Top 10 for Large Language Model Applications provides a useful framework for understanding these and other application-level risks. It helps security teams identify threats that traditional network and endpoint controls were not designed to address independently.
How FortiAIGate Brings Zero Trust to AI
Zero trust rests on a single premise: nothing is trusted because of where it came from. Every request is verified on its own merits, every time, regardless of whether the user is already inside the network.
Applied to generative AI, that premise cuts in both directions, and this is the part most organizations have not yet internalized. A prompt is not trustworthy because an authenticated employee sent it. And a response is not trustworthy because it came from a model the organization owns.
FortiAIGate enforces that principle architecturally. It sits between the application and the model as a proxy, which means every exchange passes through a verification point by design rather than by policy.
Two-way inspection
FortiAIGate inspects AI interactions in both directions.
Inbound inspection evaluates prompts before they reach the model. Depending on the configured policies and detection capabilities, this can help identify prompt injection attempts, jailbreaks, and sensitive information that should not be submitted.
Outbound inspection evaluates model responses before they reach the user. This can help identify sensitive information that should not be disclosed, along with other responses that violate organizational policies.
The distinction is important. Protecting only the input leaves organizations exposed to information disclosure in generated responses. Protecting only the output leaves sensitive information vulnerable when users submit it to a model.
Two-way inspection helps address both sides of the interaction.
This approach complements zero trust network access (ZTNA). ZTNA helps determine which users and devices can access applications and resources. Runtime AI inspection adds another layer by evaluating the content moving between an AI application and its model.
Neither replaces the other. Together, they address different parts of the access and security problem.
AI guardrails and custom rules
Inspection is only useful if an organization can define what it is inspecting for. FortiAIGate applies customizable rules to each model endpoint, so policy can differ between an internal engineering assistant and a customer-facing application. A context-aware data loss prevention engine monitors traffic in both directions for personally identifiable information and other sensitive data.
The practical effect is that data leak prevention stops being a matter of training users not to paste the wrong thing, and becomes a control that holds whether or not they remember.
Recording prompts and responses tied to suspicious activity
Every prompt and response is logged, and flagged activity is mapped to the OWASP Top 10 for Large Language Model Applications rather than to a proprietary taxonomy. That matters in two places. During an investigation, it is the difference between being able to reconstruct what the model was asked and when, and not being able to. During an audit, it is the evidence that controls were operating.
Benefits of Using FortiAIGate
Flexible deployment
FortiAIGate deploys as containerized services with a Kubernetes ingress controller and load balancer built in, which means it fits the way most AI workloads are already being run. It supports on-premises, cloud, and hybrid environments, and it is managed through a GUI rather than requiring hand-written YAML or Python. Fortinet states that multi-GPU offloading keeps proxy latency low, which matters more than it might appear: a security control that noticeably slows a user-facing assistant tends to get removed.
Sensitive data stays protected
The combination of inbound and outbound DLP addresses the two ways data actually escapes through an AI system. It prevents regulated data from entering a model that should not receive it, and prevents the model from returning data it should not surface. For organizations operating under HIPAA, PCI DSS, or contractual data handling obligations, that is the control that makes AI adoption defensible rather than merely fast.
Visibility and cost control
FortiAIGate tracks token consumption and compute cost per user. The security case is that excessive or deliberately malicious consumption is an attack in its own right, one where the damage shows up as a compute bill rather than an outage. The operational case is that runaway AI spend is one of the faster ways for a promising program to lose executive support.
Where FortiAIGate Fits Alongside Your Existing Controls
Runtime AI security is an additional layer, not a replacement for established cybersecurity controls. Each technology addresses a different part of the attack surface.
- Secure web gateways and network security help control access to internet destinations and inspect network traffic.
- Zero trust network access verifies users and devices before granting access to applications and resources.
- Endpoint security helps protect the devices from which users and applications initiate requests. Liquid Networx offers solutions such as FortiEndpoint and broader endpoint security services.
- Runtime AI security evaluates AI interactions, helping organizations enforce policies on prompts, responses, and usage.
These controls work together to reduce gaps that any single layer would leave open.
For example, endpoint security can help detect malicious activity on a user’s computer, while ZTNA can restrict which applications that user can access. A secure web gateway can apply policies to web traffic. Runtime AI inspection adds context about the actual content of the AI interaction.
An organization with strong identity controls but no runtime inspection may know who is talking to a model without having adequate controls over what is being submitted or returned.
Fortinet’s broader security portfolio gives organizations options for integrating AI controls with their existing infrastructure. Andrew Hammond’s discussion of FortiAIGate highlights the importance of managing AI access, prompts, data, and costs as part of a practical security strategy. For Liquid Networx customers, the opportunity is to combine these capabilities with the network, endpoint, and security operations controls already in place.
What Deployment Actually Requires
The product is the straightforward part. Three things determine whether a deployment holds.
An inventory, first
Most organizations cannot produce a current list of where generative AI is running, what data each deployment can reach, and who approved it. Guardrails applied to the three deployments you know about do nothing for the five you do not. Discovery precedes enforcement, and it is usually the step that gets skipped.
Policy that someone owns
Guardrails are configurable, which means somebody has to decide what they should say. What data may reach a model. What a model may return. Which users get which limits. These are business decisions in technical clothing, and they stall when no one is assigned to make them.
A path from alert to action
A blocked injection attempt is an event. Somebody has to see it, understand it, and decide whether it was a curious employee or a probe. Without that path, detection produces log volume rather than security.
This is the work Liquid Networx does alongside the technology: establishing what is actually deployed, defining policy with the people who own the data, and connecting runtime AI telemetry into security operations so it is monitored rather than merely collected.
Start With What Is Already Running
The organizations handling AI security well are not the ones that moved slowest. They are the ones that found out what they already had before deciding what to protect.
If you cannot currently say where generative AI is running in your environment, what each deployment can access, and who is using it, that is the place to start. Talk with Liquid Networx about building that picture, and about what it would take to put zero trust runtime controls in front of what you find.