On 9 September 2026, Check Point's R82.20 release notes described what the company calls the industry's first Network AI Firewall: prompt injection protection, content moderation and protection for MCP tool responses, running on the firewalls enterprises already operate. It is the clearest signal yet of something that has been building for a year. AI security is no longer a category of startup. It is becoming a line item in infrastructure people already own.
That deserves to be said plainly, because a lot of AI governance marketing has spent the last two years implying the opposite. Check Point acquired Lakera on 22 October 2025 for approximately $187 million in net cash consideration. It launched an umbrella "AI Defense Plane" on 23 March 2026. Workforce AI Security now ships as an endpoint agent, browser extension and IDE integration with published pricing on AWS Marketplace at $44 and $94 per user per year. Prompt DLP for Claude, ChatGPT and Microsoft Copilot is arriving in the SASE console.
So the honest starting point is not that a security vendor cannot block AI traffic. It can, it does, and it will keep getting better at it. The interesting question is narrower and more useful: when one of these systems stops an action, what does the auditor get?
Two different questions
There are two questions you can ask about an AI action, and they are not the same question asked at different volumes.
The first is a security question: is this interaction dangerous? Does this prompt look like an injection attempt? Does this response leak a credential? Is this employee pasting source code into an unapproved model? This is detection, and it is genuinely hard. It requires adversarial research, a corpus, multilingual coverage, and continuous retraining against attacks that did not exist last quarter. Lakera built a real one, and Gandalf and the PINT benchmark are credible public artifacts. (We keep a side-by-side comparison of where the two layers differ.)
The second is an authorization question: is this specific action permitted, by whom, under which policy? May this agent move $50,000? May this model issue an adverse action notice without the reason codes ECOA requires? May this tool call write to the system of record for a customer in a jurisdiction the mandate does not cover?
Detection answers a question about content and risk. Authorization answers a question about permission and consequence. A system can be excellent at the first and structurally silent on the second — not because it was built badly, but because it was built to answer a different question.
Ask what the system returns when it decides. If the answer is a risk verdict — flagged, a confidence tier, a detector name — that is detection. If the answer names the policy, the policy version, and the specific rule that produced the disposition, and does so in a record a third party can verify without calling the vendor, that is authorization.
What the decision object actually contains
This is where documentation is more useful than positioning, because the decision object is a typed schema and you can read it.
Check Point's published API reference for the Guard endpoint specifies the complete success response: a flagged boolean; an action enum of detect or enforce; a payload array giving match locations; a breakdown array carrying project_id, policy_id, detector_id, detector_type, detected and result; an optional dev_info debug block; and metadata containing a request_uuid.
That is a well-designed detection response. Read it as an audit artifact, though, and three things are absent. There is a policy_id but no policy version and no policy content hash, so a decision cannot be bound to the exact policy text that produced it. There is no signature, hash, or attestation of any kind, so the record cannot be verified without trusting the system that emitted it. And the request_uuid is a correlation identifier, not a cryptographic commitment.
The export path has the same shape. Guard logs are delivered as plain JSONL files to a customer-supplied S3 bucket; Check Point Portal Event Forwarding delivers Syslog, CEF, LEEF or JSON to a SIEM under a separate licence. These are ordinary application logs. There is no hash chain, no per-record signature, and no key held separately from the producing system. An auditor's confidence in them reduces to confidence in the vendor's infrastructure.
Two further details from Check Point's own documentation matter for anyone evaluating agent governance specifically. The Agents policy layer — the one that governs MCP tool calls — supports exactly two actions, Allow and Block. And global Prompt Attack Detection on the MCP path is, during Early Availability, explicitly documented as operating in Detect mode only: it does not block, modify or sanitize traffic, it runs asynchronously so as not to delay tool execution, and its detection events carry no policy attribution.
None of that is a criticism of the engineering. It is a description of scope. These systems are built to tell you an interaction was dangerous. They are not built to tell an examiner which business policy authorized a consequential action two years after it executed.
Why "detect vs enforce" is the wrong axis
The industry argument has been stuck on whether guardrails can block. It is the wrong axis, and it is now empirically settled: they can. Check Point enforces inline at the gateway. The Guard API, by its own integration documentation, is deliberately advisory — customers "implement their own response logic" — but the network plane is not.
The axis that actually matters is reproducibility and attribution. A detection verdict is produced by machine learning models that are retrained against observed misclassifications, graded on confidence tiers rather than binary outcomes. That is the correct design for detection — you want it to improve. But it means the same input can yield a different verdict after a model update you did not schedule and cannot pin, unless you self-host. Combined with a policy identifier that carries no version, a decision made last March cannot be re-performed today.
Re-performance is not an academic concern. It is the mechanism by which control testing works. An auditor samples decisions, re-runs the control against the recorded inputs, and checks that the outcomes match. A control that cannot be re-performed is, in audit language, not a control — however effective it is at stopping attacks.
Security signals should inform authorization, not become it
The useful architecture is not either/or. It is a pipeline where each layer answers the question it is good at.
Security platform detects → normalized security context → deterministic policy evaluation → ALLOW / MODIFY / BLOCK → signed decision record → single-use execution authority → protected executor → evidence back to the SIEM.
A DLP finding on an outbound transfer, a prompt-injection detection on the turn that proposed a payment, an unapproved-application signal on the session that requested a data export — these are excellent inputs to an authorization decision. What they should not be is the decision itself, and the reason is a trust boundary rather than a turf question.
If an external detection can only ever tighten an authorization — block it or route it to a human — then a signal that is forged, replayed, stale, or simply wrong can cause a refusal. Annoying, recoverable, and safe. If a detection can also loosen an authorization, then compromising the security vendor's feed becomes a way to authorize actions. That asymmetry should be structural, not a configuration setting someone can get wrong.
We have implemented that boundary in EVE as a module called Security Signals, and it is worth being precise about its status: it ships off by default, it has an observe mode that records what enforcement would have done without changing any verdict, and it has no vendor-native connector and no authenticated ingest endpoint yet (our integrations page classifies every connector by what the code actually does). What it does have is the invariant. A normalized external security finding produces a directive with exactly two levers — block and escalate — and both tighten. There is no third lever, and a test sweeps every combination of signal class, severity, trust class and freshness mode to prove no input widens authority. Signals that arrive without an authenticated sender can escalate to human review but cannot block at all, which bounds what a forged request can do.
Freshness is treated the same way. A finding's age is measured from when the upstream observed it, never from when we received it, so redelivering old data cannot make it current. And whether a missing signal blocks is an explicit per-source declaration: a source marked REQUIRED blocks when it goes dark; a source marked OPTIONAL does not, because an optional SIEM being offline must never take authorization down with it.
What a decision record has to survive
The reason to care about any of this is temporal. A security incident is investigated in days. A regulated decision is examined in years.
When an examiner asks why an automated system declined a credit application in March 2026, the useful answer is not "our AI security platform did not flag it." It is: this decision was produced by a CoreGuard policy pack lending_v1 at a named version with a published content hash, these rules fired, this was the disposition, here is the signed record, and here is the public key you can verify it with — without calling us, without our systems being available, and without trusting us.
That is a different artifact from a detection log, and it has to be designed for from the start. In EVE’s enforcement path, a BLOCKED decision mints no execution token at all, so there is nothing for a downstream connector to redeem; the tests that cover that boundary assert the side effect — that the connector was called zero times — rather than that an API returned the string "BLOCKED", because an API returning BLOCKED proves nothing if the tool ran anyway.
What buyers should actually ask
If you are evaluating this layer, the questions that separate vendors quickly are not about detection quality. Everyone's detection demo works.
- When the system blocks, does the downstream connector receive the call? If it receives it and you write an event about it, that is monitoring. If it never receives it, that is enforcement.
- Which exact policy version was in force? Not the policy identifier — the version, and ideally a content hash of the policy text.
- Can the decision be re-performed? Same inputs, same policy state, same outcome — today and in three years.
- Can the evidence be verified without you? If verification requires calling the vendor's API, the vendor is a dependency of your audit.
- What happens when the security provider is offline? Fail-open, fail-closed, and is that a decision someone made deliberately or a default nobody chose?
- Can security signals feed authorization policy at all — and if so, can a signal ever widen what an agent is allowed to do?
The layers are not competing
It would be easy, and wrong, to read Check Point's expansion as a threat to the authorization layer. The more accurate reading is that the market is separating into layers that need each other.
Detection belongs where the traffic is: at the gateway, in the browser, on the endpoint, in the proxy. It needs scale, adversarial research and constant retraining, and a security platform with a decade of network presence is a better home for it than a governance vendor pretending to build one. We have not built prompt-injection detection or a DLP, and we should not.
Authorization belongs where the consequence is: immediately before the action executes, evaluated deterministically against a named policy version, producing a record that outlives the platform that made it. That is a different discipline with different requirements — reproducibility over recall, attribution over coverage, evidence over telemetry.
As AI security becomes part of the enterprise security fabric, the remaining control problem is not more detection. It is making sure consequential actions execute only under explicit authority, and producing proof of that authority that still means something when the vendor, the model version and the security console have all moved on.