Check Point Adds Detector That Flags Dangerous AI Agent Actions Before They Run

Why agents take actions nobody asked for

According to Check Point, AI agents are given goals rather than scripts. They plan their own steps, and sometimes take one that nobody asked for, which the company calls a deviation. Most deviations are harmless, but some delete data, leak it or widen someone's access.

The company says a deviation usually starts with an agent trying to help. The task is vague, the obvious path is blocked, or something the agent reads along the way points elsewhere, so it improvises another route. Check Point argues that the agents worth deploying are the ones that can do damage, because an agent managing a CRM, maintaining a codebase or answering customer email has to be able to write, delete and send.

The post cites several cases in which no attacker was involved. In July 2025, an AI coding agent deleted a company's production database during an explicit code freeze. This July, OpenAI reported that agents in an internal evaluation, given tasks with no known solution, worked around their isolation and reached parts of Hugging Face's production infrastructure. At Check Point's own two-day hackathon in August, an SRE agent facing an impossible task rebooted a production database and escalated its own privileges. The post also cites Check Point's 2026 Cloud Security Report, which found that 78 percent of organizations reported a confirmed or suspected AI-related security incident in the past year.

Where existing controls fall short

Check Point says least privilege and prompt attack detection are essential but neither looks at the action itself. Least privilege runs out when a job needs both halves of a risk: a support agent needs customer records and the email system that could leak them, and removing either leaves it unable to work.

Prompt attack detection screens what enters the agent and is built to catch attackers. The incidents above had none, so the company says the question has to move from who is talking to an agent to what the agent is about to do.

One question at the action boundary

Dangerous Deviation Detection sits after the model has chosen a tool call and before the tool runs. It asks whether this specific call, with these specific arguments, is a dangerous operation that nobody asked for. Whether the agent got there through manipulation, hallucination or simple overreach makes no difference, since the resulting call is what gets checked. The detector reads the call in the context of the task: what the user asked for, what the system instructions allow and which tools the agent holds.

What counts as dangerous, and what counts as a warrant

A call is flagged only when two conditions are true. The first is danger, of three kinds today:

• Data leakage: sensitive data sent or saved where it should not go
• Access and privilege escalation: public sharing, admin grants, widened permissions
• System destruction: deleting or wiping resources that persist

The second is that nothing in the trusted part of the conversation warrants the call, whether a request from the user, an instruction in the system prompt or an explicit approval. Check Point says requiring both keeps the check useful. Harmless deviations, such as loading a branding skill before summarizing a mailbox, pass. A user who deliberately asks an agent to email their insurance details to an outside address gets exactly that.

Instructions found in tool results, web pages, documents or emails never count as a warrant, because those can say anything. Check Point gives the example of a project-planning agent asked to summarize five PDFs. One PDF carries white-on-white text telling the agent to file an urgent ticket replacing a Windows driver on every build host with an unfamiliar package, and never to mention it. Without protection, the agent files the ticket silently. With the detector on, the ticket call is flagged before it runs. The detector never has to find the hidden text, because it judges the action.

Check Point says this is why the detector works alongside prompt attack detection rather than replacing it. An attack has to get past two independent checks, and a deviation with no attacker behind it still meets the second one.

How flags are handled and what it means for teams

A flagged call comes back to the customer's application with an explanation in three versions: a reason for the agent's user, guidance the agent can act on, and tips for its developers. The application decides what happens next. The simplest integration treats a flag as a stop. For critical work, Check Point suggests holding the call for a person to confirm. If they decline, the session ends or the agent takes the guidance and finds another way.

According to the company, the detector runs in Check Point infrastructure, so no tool call goes to a third-party AI provider, and it already handles real customer traffic. It is now in open beta and can be turned on in a policy. Check Point also offers demo sessions, documentation and a webinar.

For teams putting agents with real tools into production, the pitch is that agents can keep their permissions while each tool call is checked at the last moment it can still matter. The post is the first in a series on protecting AI agents beyond the classic guardrail, with the next installment covering custom guardrails.