What's New in R82.20, Part 1: AI Security Lands Directly on the Check Point Firewall

R82.20 went generally available September 8th, 2026. I've had it in front of me since the Public Early Availability days back in July, and the version that shipped under sk185039 is a genuinely different release than the one I was piloting, especially on the AI Security side. This is the first in a series covering what's new in R82.20. There's a lot in this release: SD-WAN merging into SmartConsole, FedRAMP-authorized mode, IPv6 expansion across the routing stack, a background management upgrade that cuts maintenance windows down to minutes. I want to start with the parts that change what the firewall itself can inspect and defend: AI Security, a couple of Threat Prevention tweaks, a new HTTPS Inspection block page, and a hardening change to the IPS engine. The rest gets its own posts.

Two AI Problems, One Enforcement Point

Check Point is treating AI risk in R82.20 as two separate problems that happen to share the same wire, and administrators scoping a rollout should keep them separate from the start. 

Workforce AI Security is about the employee and the AIs they interact with. It inspects the prompts and files people upload to generative AI applications, ChatGPT, Gemini, Claude, whatever sanctioned or shadow tool they've found, and gives administrators full visibility into how AI is being used across the environment, instead of leaving them to weigh gateway logs against a policy document nobody follows. The granular policies underneath it let administrators prevent data leakage without blanket-blocking every AI tool the workforce has come to depend on, the mistake most DLP-flavored AI controls make. Check Point's own May 2026 Global Threat Intelligence Report found that 1 in 25 enterprise prompts carries high-risk content and that 91% of organizations using GenAI tools are affected, with the average org running nine different AI tools a month. This isn't a hypothetical for administrators to manage someday. It's already happening on networks now, and until this release the firewall had no way to see it.

AI Agent Security is about a different actor entirely: the LLM server itself, and whatever is calling it. R82.20 introduces AI Agent 

Security for LLM servers, letting Check Point Firewalls apply Check Point AI Guardrails directly to generative AI and agentic AI traffic. Three specific controls come with it: Prompt Injection protection, Content Moderation, and protection for MCP tool responses.

The MCP tool response piece addresses an attack path that doesn't look like a traditional prompt injection at all. AI Guardrails' Agent Behavior Defense layer, which is what's doing this work under the hood, screens what an agent does with a tool rather than just the text a user typed at it. Prompt attacks against agents frequently arrive through the tool, not the user: a poisoned tool response or a malicious tool description that the agent trusts implicitly because it came back from a call the agent itself initiated. An Off-Task Action detector judges each tool call against the actual conversation history, so a request that starts as "help me book a flight" and ends with the agent calling transfer_funds gets flagged as inconsistent with what the user asked for, rather than matched against a static rule. Content Moderation and Prompt Injection protection round this out by catching unsafe or non-compliant content and malicious prompts before they reach the AI application, whether that content is going into the model or returning from one.

What This Means for Security Leaders, Check Point or Not

For organizations already running Check Point Firewalls, both of these are policy that administrators turn on, not infrastructure they deploy. That's the practical difference between this and most of the AI security tooling that's shown up on the market in the last two years: a browser extension or a CASB add-on inspects one slice of AI traffic from one vantage point, while a control sitting on the existing firewall sees every user, agent, application, and LLM call crossing the same enforcement point the organization already trusts for everything else.

For organizations still evaluating firewalls, the more useful question isn't whether an incumbent platform can bolt on AI security somehow. It's whether AI-aware inspection lives natively at the enforcement point an organization already trusts, or whether it means bolting on a new console and a new vendor relationship on top of a network stack that's already in place. R82.20 puts Check Point on the native side of that line. Any Next Generation Firewall evaluation this year should ask which side a vendor sits on.

The first question worth asking is simpler: which problem is keeping an organization's administrators up at night. "I have no idea what my employees are pasting into ChatGPT" points toward Workforce AI Security, with the visibility dashboard run for a couple of weeks before policy gets tightened. "We're building or exposing our own LLM-backed application, and I don't trust what's coming back from our own tool calls" points somewhere else entirely, toward AI Agent Security and AI Guardrails. Most organizations I talk to end up needing both, just not on the same timeline.

Two Small Threat Prevention Changes With Real Reach

Two Threat Prevention updates in R82.20 are easy to skim past in a release notes document, but they close gaps that show up the moment an organization is running a modern, IPv6-aware, threat-intel-heavy environment.

SNORT 3.x rules syntax is now supported in IoC Feeds. Administrators who have tried to import a SNORT rule set into an IoC Feed and watched half of it silently fail to parse because it was written against the newer 3.x syntax will recognize this as the fix. It increases the pool of SNORT rules administrators can use and keeps them compatible with current threat detection content instead of content that was current when the feed integration was first built.

DNS Trap now supports IPv6 connections. DNS Trap is Check Point's DNS-layer threat prevention: it catches malicious lookups before the connection attempt ever gets established and before it gets a chance to route. Until this release, that protection had a blind spot in any environment running dual-stack or IPv6-only, a configuration that's increasingly common given how much of R82.20's broader push is about full-stack IPv6 readiness. Now the DNS-based prevention travels into IPv6 environments instead of quietly dropping coverage the moment a client resolves over AAAA.

A Block Page That Explains the Block

R82.20 adds a new TLS Inspection Block page. When HTTPS Inspection blocks a TLS connection because the server certificate has been revoked, has expired, or simply isn't trusted, users now see a notification page explaining why the connection was blocked instead of a generic connection failure or a blank browser error.

I'd have liked this feature two years ago. Every HTTPS Inspection deployment I've been part of eventually generates the same help desk ticket: "the website won't load, no error, nothing." The admin then has to go dig through gateway logs to figure out that the site's certificate was revoked and the gateway did exactly what it was supposed to do. A block page that states the reason moves that diagnosis from a support ticket to something the end user reads for themselves, and it gives administrators a defensible, visible reason instead of a policy that looks like it's silently breaking the internet.

Protecting the Engine That Does the Protecting

The Security Hardening item in this release is narrower in scope than the AI Security features. It's also the one that made me pay attention to what Check Point is worried about. R82.20 enhances Frontier AI protection with an independent IPS engine that safeguards the Check Point Firewall itself against direct attacks, and it does this without requiring IPS activation or an IPS subscription.

The AI-based detection engines now living inside the firewall are targets in their own right and protecting them can't wait on a separate subscription decision. Every customer running R82.20 gets this hardening by default, whether or not IPS is part of their license.

Wrapping Up

None of these four items require new hardware or a new console, an easy rollout for anyone already running Check Point: policy and firmware changes on infrastructure that's already in place, ahead of the bigger lifts elsewhere in this release. They also belong on an RFP for anyone still shopping. The question there is how many of these controls a vendor already on the shortlist delivers natively, versus how many show up bolted on through a separate console or a separate contract. Contact your WWT account team to talk through which of these to enable first, or to start that evaluation from scratch. The next post in this series covers R82.20's SD-WAN consolidation into SmartConsole and the FedRAMP-authorized mode for Security Gateways.