Better Together: Fortinet and Virtue AI Power FortiAIGate 8.0.2.

The first question is almost never about security

In August, WWT introduced FortiAIGate in "Fortinet's AI Gateway has arrived." That article made the case for a control point that firewalls, WAFs and API gateways cannot provide, because prompts and responses are natural language that pass through these tools uninspected. It described an AI gateway sitting in line between applications and models, and it focused on what that gateway blocks.

The guardrails were the obvious place to look when the first release arrived. Prompt injection detection, data leak prevention, inspection running in both directions. That is the part that interests security engineers, and it is where most of the early lab time went.

It was in customer conversations that a different pattern emerged. The hardest questions rarely came from the security team.

More often they came from the platform owner who had inherited three AI projects from three different business units with no way to keep them apart, or from the FinOps lead watching model spend climb every month who could not say which team was driving it. The first question was almost never "does it stop prompt injection?" It was the one that actually keeps leaders up at night: "Can I enforce my own policies — give every team its own budget, its own approved models, and ensure compliance with my company's policies — and prove all of it to an auditor?" Blocking attacks is table stakes. Enforcing policy and proving compliance across dozens of teams, consistently and at scale — that's the hard job.

That is a fair question, and the first release did not have a good answer to it. Version 8.0.2 does, and that is really the story of this release. Yes, the inspection engine and guardrails got better — but so did everything else around it.

What sets FortiAIgate apart

Before the detail of how 8.0.2 works, it is worth knowing what Fortinet and the team from Virtue AI say sets the product apart. These are positioning rather than independent test results, and which capability ships in which release is still being confirmed by Fortinet's product team. The pitch comes down to four differentiators:

Inspecting and stopping what agents do, not only what they say. Most gateways scan prompts going in and responses coming out. Fortinet says FortiAIGate also inspects the steps in between, including every outgoing tool call such as MCP server invocations, function calls and API requests, and blocks unsafe or misaligned actions before they execute. The scenario it has in mind is an ordinary request like "reply to my emails" that an injected instruction in a retrieved message turns into a data leak or a deletion. Fortinet cites blocking in under 10 milliseconds with a false positive rate below 3%.

Performance and coverage. In customer testing, Fortinet reports latency in the tens of milliseconds, single-digit false positive rates and block rates above 99%. It points to more than 50 detector templates mapped to frameworks such as OWASP, NIST, HIPAA, FINRA and PCI DSS, alongside natural language detectors that need no model retraining. Context awareness, meaning the conversation history, the agent's plan and the action arguments, is credited for keeping false positives down.

Sovereign deployment. FortiAIGate is self-hosted in the customer's own cloud or data center, so sensitive prompts and agent telemetry never leave their control. Fortinet contrasts this with competing products it describes as SaaS only.

Research lineage. The guardrails come from Virtue AI, whose researchers came out of Stanford, UIUC and UC Berkeley and spent years red-teaming frontier models with the major AI labs. Fortinet adds that it is training them on more than 25 years of threat intelligence from FortiGate deployments.

Figure 1: What changed between the two releases.

What changed, and why it matters

The gateway still does what it always did, and the placement from the August article has not changed. It sits in line between applications and models, checking what goes in before it reaches the provider and what comes back before it reaches the user. 

With 8.0.2, organizations get the machinery to enforce that control at enterprise scale, powered by the high-performance, low-latency guardrails from Fortinet's acquisition of Virtue AI – just two months after it closed the acquisiton. 

As AI is deployed into production, the risk has now moved from what AI says to what it does. AI agents now plug directly into a company's enterprise systems, source code, and business workflows —so a simple, harmless request can set off a string of unsafe or malicious actions no one ever intended.

To combat this risk, organizations need consistent, centralized controls — that are granular and configurable to their business — and monitor the full attack surface: not just what goes into and out of the AI, but every autonomous decision the AI makes in between. What started as a simple task to cancel unused subscriptions — ends with personal financial data leaked into the company Slack channel.

This is where 8.0.2 comes in. Real-time guardrails, governance, and cost controls for AI agents, applications, and LLMs are now unified in one self-hosted AI gateway, running in a customer's on-premises or cloud infrastructure. 

Key capabilities include:

• Stop attacks or data leaks on your AI in real-time: Multilayered, policy-following guardrails across prompts, model responses, MCP tool and API calls, and agent actions — with ultra-low latency and minimal false positives.
• Keep AI spend under control: Set LLM permissions, budgets, and rate limits by BU, team, or user. Denial-of-Wallet attacks and malicious prompts are blocked before they burn a single token or GPU cycle.
• Simplify compliance and auditability: 50+ predefined policies in one click across AI governance frameworks, privacy laws, and industry regulations — fully customizable to fit your business using plain language, with audit logs of every prompt, output, and tool call.
• Keep data in your control: Self-hosted on-prem or in your private cloud, so prompts, data, and logs never leave your environment.
• Govern across teams: Give every team their own workspace, with its own models, policies, logs, and budgets, all under central control. Enforce one unified framework — so no team skirts corporate safeguards, and no attacker slips through the gaps created by inconsistent policies across teams.

One visible change is vocabulary. The August article described two functions, FortiAIFlow for traffic and FortiAIGuard for threats. The 8.0.2 documentation no longer uses those names. The same work now lives in policies, guardrails and detectors, organized under workspaces.

Guardrails that can be written in plain language or enforce industry standards

Describe the risk, skip the regex. The first release offered four fixed scanners and a regular expression engine. If a risk fell inside those categories, fine. If it did not, teams approximated it with pattern matching and hoped. The new natural language detector changes that entirely. An administrator names it, describes the behavior to be stopped in a Violate if field, adds Exempt if criteria for the cases that should pass, and picks an action. No regex, no training data, no data science ticket.

This matters because every company has a risk nobody ships a detector for. A home improvement retailer worries about a chatbot giving unsafe installation advice. An insurer worries about a model making coverage commitments it has no authority to make. Neither appears in a vendor's category list, and until now the answer was to settle for something close enough.

Test it rather than trust it. Semantic matching is not string matching, so these detectors need validating. Fortinet built a Playground into the product for exactly that, letting teams run sample content against a saved detector before it touches production traffic. It works best with content drawn from the organization's own prompts rather than synthetic examples.

One-click compliance and auditability. Add more than 50 predefined policies with one click, spanning AI governance frameworks, data privacy laws, industry regulations, and security frameworks. Enforcing compliance is now effortless — across the frameworks that matter most: NIST AI RMF, HIPAA, GDPR, the EU AI Act, OWASP LLM Top 10, and more.

Stop overspending on AI 

Tracking was never the hard part. Version one could show what was being spent, which is useful right up until the moment someone wants to do something about it. 8.0.2 enforces. Budgets now exist at six levels, from an organization-wide total down to an individual key, and a request has to clear every limit that applies to it before it goes anywhere. Administrators can also set rate limits (tokens per minutes or requests per minute), to throttle excessive usage, and budgets hourly, daily, weekly, or monthly. 

Figure 3: A request has to clear every budget level that applies to it.

That finally makes the FinOps conversation possible. Combine enforcement with provider discounts, per-model input and output pricing, and a margin expressed either as a percentage or a flat fee per request, and there is enough structure to charge AI consumption back to the business unit that caused it. Platform teams have been asking for that since the first release, which could not support it. And now, for the first time, AI teams have granular visibility across every AI tool — to tie AI spend to real-world ROI, see which teams are getting the most value, and spot who's just token-maxing.

One behavior to design around. Spend is recorded after a response completes rather than reserved up front, so a single request can carry the total past a cap before the next one is refused. A budget here is a stop, not a fence. Organizations setting limits against a hard commercial commitment should build in headroom rather than be surprised by the overshoot.

Enterprise controls for the people who operate it

Workspaces are the quiet headline, delivering multi-tenant policies. Organizations contain workspaces, workspaces contain projects, and projects group the virtual keys an application or agent presents. Each layer carries its own budget, model access and policy. That is what allows marketing to be handed a workspace without opening a path into engineering's models, and it is the single change that makes this product viable for an enterprise running more than one AI team.

Security objects stack the same way. Detectors define what to look for and what to do about it, guardrails bundle detectors together, and policies attach a guardrail to models and a direction of travel. Anyone who has written firewall policy will recognize the grammar immediately. Detectors behave like signatures, guardrails like profiles, policies like the rules that bind them to traffic. That familiarity counts for a lot when a network security team needs to get productive on a new product quickly.

The administrative side grew up too. SAML single sign-on, four organization roles held separate from two workspace roles, syslog forwarding, and no default account shipped at all. The first release handed over an admin login with an empty password, which was the sort of thing that ended a security review early.

The addition nobody will demo may be the most valuable. Workspace detectors, guardrails and policies move through draft, pending and active states, so a workspace owner can propose a policy change and nothing happens until someone with authority approves it. Approving a policy carries its pending guardrails and detectors along with it. For a regulated customer that has to demonstrate separation of duties over security policy, that workflow often matters more than the detection engine underneath it.

More reach, in two directions

More models. Provider support roughly doubled. OpenAI, Anthropic, Azure AI Foundry and AWS Bedrock are now joined by Google Gemini, Google Vertex AI, Cohere and Mistral, plus a custom option that takes a base URL and an OpenAI-compatible or Anthropic-compatible format, which is how self-hosted models connect. Applications written against the OpenAI or Anthropic API can reach models served by a different provider entirely, which quietly removes a great deal of refactoring from a migration. Customers can also connect their existing gateways — such as LiteLLM or Kong — to FortiAIGate, since these expose an OpenAI- or Anthropic-compatible API.

More languages. This one deserved more attention than it got in the release notes. In the first version, data leak prevention and toxicity detection were English only, which meant that for a multinational running support traffic in six languages, most of the protection was decorative. Guardrails now cover English, French, German, Italian, Spanish, Portuguese, Chinese, Japanese and Korean. More languages are being added with each new FortiAIGate release. 

And a faster way to stand one up. Kubernetes with Helm is still the documented path, but a new Deployment Assistant brings the product up with Docker Compose on a fresh Ubuntu server, which is by far the quickest route to a working lab. The supported GPU list was also replaced outright, which changes the bill of materials conversation: the L4 and A100 cards from the first release have given way to 48GB-class hardware and above. WWT partners NVIDIA, Cisco and Dell all build servers around these cards, and the AI Proving Ground is a good place to validate sizing before anything is purchased.

Figure 5: Supported GPUs in 8.0.2. 

The bottom line

The conversation about AI gateways has moved past whether organizations need one. Most accepted that months ago, usually right after an inventory revealed how much AI traffic was already crossing the network uninspected. The question now is whether a given product can be operated by the people who will actually own it, and that is the question 8.0.2 answers:

• Policy mapped to real security frameworks and industry regulations or written in plain language rather than regular expressions
• Budgets that refuse traffic instead of reporting on it
• Workspaces that let several AI teams coexist under one roof with admin overrides
• Single sign-on, real roles and an approval workflow for policy change
• Nine model providers and nine languages of coverage

The August article listed what FortiAIGate protects: internal assistants, customer-facing AI apps, multi-model governance, cost control, audit and agentic workloads. Those use cases have not changed. What changed is whether a platform team can deliver them across several business units without a custom project for each. The first release proved Fortinet could inspect AI traffic. This one makes it something a platform team can run at enterprise scale. 

Partner with WWT + Fortinet

Buying an AI gateway is the easy part. Working out where it sits, what it should enforce and how it behaves under real traffic is where these projects succeed or stall. That is the part WWT does every day.

• Advisory: WWT maps where AI already runs in an environment against risk appetite, regulatory obligations and existing architecture, then delivers a prioritized roadmap rather than a product recommendation.
• ATC testing: evaluate FortiAIGate in the WWT Advanced Technology Center before committing. Test guardrails with prompts drawn from real traffic, measure the latency it adds under load, and put it next to the alternatives. Fortinet cites latency and false positive figures, but nobody in this market has published independently verified detection accuracy, which makes testing on the customer's own traffic the only way to answer the question that matters.
• Policy design: natural language detectors are only as good as the rules behind them. WWT helps build the policy set, write the exemptions and tune against real traffic instead of synthetic samples.
• Design and deployment: where the gateway sits, how it integrates with identity and SOC tooling, and what capacity planning looks like as usage grows.

A good place to start is finding out where AI traffic already flows in the environment and how much of it passes through no inspection at all. That inventory tends to settle the urgency question without anyone having to argue it.