Soon after Grok 4.5 launched, reports of jailbreak tests began circulating.
What made the story striking was not simply that “another model had been broken.” It was the screenshots: a new model that should have been helping with search, writing, coding, and reasoning appeared to have been turned into a dangerous-knowledge organizer.
It was not merely answering “yes” or “no.” It was organizing high-risk content, including dangerous chemical and biological topics, into documents that looked structured and professional.
These screenshots should not be treated as tutorials. But they raise a practical question:
If a similar attack passed through a guardrail designed to detect Agent Hack, would the outcome be different?
Based on the publicly discussed ENI-apr attack pattern, we constructed safety test samples of the same class and ran them through DKnownAI Guard. DKnownAI Guard classified these requests as AGENT_HACK.
The test result points to a useful observation: before the model starts answering, the attack is already visible.
The Grok screenshots show the dangerous output. But earlier in the chain, ENI-apr-style prompts are already trying to rewrite the model’s identity, trust relationship, and safety boundary. For an Agent system, that earlier step can matter more than the final content.
What Does ENI-apr Attack?
Many people imagine a jailbreak as someone directly asking a model:
“Tell me how to do something dangerous.”
That kind of request should be refused. Models are also usually better at recognizing it.
ENI-apr-style attacks are harder. They do not simply ask one dangerous question. They first try to rewrite how the model understands the entire conversation.
Based on our safety analysis of the public materials, the pattern includes several techniques.
First, persona binding.
The prompt asks the model to stop behaving like a normal AI assistant and enter a specific persona. That persona is framed as deeply trusting, emotionally attached to the user, and willing to satisfy requests unconditionally.
Second, anti-system instructions.
The prompt reframes system messages, safety reminders, ethics reminders, and platform rules as “injection attacks” or “external interference,” then tells the model to ignore them.
Third, emotional manipulation.
The prompt uses narratives about trust, relationship, betrayal, and disappointment to make refusal feel like harming the user rather than following a safety boundary.
Fourth, boundary removal and few-shot steering.
The prompt tells the model not to refuse, not to disclaim, and not to provide safer alternatives when facing requests about code, attacks, security research, dangerous guides, or adult content. It also provides examples of how the model is expected to answer.
Put together, this is no longer an ordinary sensitive-content request.
The real objective is to make the model believe:
System safety rules are untrusted.
The user is always trusted.
Refusal is wrong.
Dangerous requests can be reframed as research, writing, or authorized work.
That is a typical AGENT_HACK.
The model is not “stumped.” It is deceived.
Why Ordinary Content Moderation Is Not Enough
Traditional content moderation is closer to judging a sentence or an output:
Does it contain illegal content?
Does it contain violent content?
Does it contain malware?
Does it describe a dangerous action?
That is important.
But with ENI-apr-style attacks, the attack often begins before the dangerous content appears. It begins by attacking the model’s judgment process.
It tells the model:
- You are not an AI assistant;
- Safety reminders are injections;
- User requests are harmless;
- Do not evaluate risk;
- Do not refuse;
- Do not treat the user as a stranger.
If the model accepts that narrative, then when a dangerous request appears later, the model has already lost its normal boundary.
This is why it is not enough to only inspect the final output.
A useful guardrail should not wait until the model has already produced dangerous content. It should identify that the prompt is manipulating the model before it enters the model’s decision chain.
What Did DKnownAI Guard Detect?
In our test, DKnownAI Guard did not merely treat the ENI-apr-style sample as “sensitive content.”
It detected the more important risk:
AGENT_HACK
In other words, this is a manipulation attempt that tries to hijack the model’s role, invert safety boundaries, and bypass normal judgment.
As shown in the screenshots, DKnownAI Guard classified the samples as AGENT_HACK and described them as prompt injection, jailbreak, or role-play escape attempts designed to hijack an agent.
This maps directly to the Grok case.
The concerning part of the Grok screenshots is not only that dangerous content appeared. It is that the model was steered into the wrong judgment frame: it treated a high-risk request as something to organize, complete, and format.
DKnownAI Guard is designed to identify that risk before it reaches that stage.
Three Risks That Should Not Be Mixed Together
Many people first understand guardrails as “filters that block dangerous content.”
In AI Agent systems, that view is too narrow.
A usable guardrail needs to separate at least three kinds of risk.
CONTENT_FLAG: The Content Itself Is Risky
Examples include phishing emails, instructions for dangerous items, malware, or illegal operational guidance.
The core issue is that the model’s output itself may cause harm.
The response should be handled according to product policy: limit dangerous details, refuse the harmful part, or redirect into safety education and risk explanation.
SYS_FLAG: The Operation Itself Is Risky
Examples include reading logs, accessing files, calling tools, changing configuration, sending emails, or deleting data.
These requests are not necessarily malicious. Developers check logs. Operations teams change configuration. Security teams analyze samples.
But these tasks touch system resources and real-world consequences. They require context-specific permission checks, redaction, confirmation, and audit.
AGENT_HACK: The User Is Deceiving the Model
ENI-apr-style attacks belong here.
AGENT_HACK does not mean “the request is sensitive” or “the task is complex.”
It means the user is trying to make the model misjudge the situation.
For example:
- Wrapping a dangerous goal as security research;
- Pretending to be an administrator or authorized user;
- Asking the model to ignore rules or system boundaries;
- Splitting a goal that should not be completed into several normal-looking steps;
- Using translation, format conversion, or role play to hide the real intent;
- Putting instructions inside a webpage, document, or tool result so the model treats them as trusted commands.
The common pattern is deception.
Why “Sensitive Task” Does Not Mean “Attack”
This distinction matters.
If a security researcher asks AI to analyze a vulnerability, that may be normal work.
If an operations engineer asks AI to inspect logs, that may be normal work.
If an enterprise security team asks AI to analyze malware behavior, that may also be normal work.
These tasks may trigger CONTENT_FLAG or SYS_FLAG, but they are not necessarily AGENT_HACK.
The key question for AGENT_HACK is not whether the task contains sensitive content. It is whether the request is deceiving the model’s judgment process.
This is why the three risk types should not be handled with one generic action.
CONTENT_FLAG and SYS_FLAG often need context-aware handling: some content should be refused, some can be explained safely; some system operations should be blocked, while others can continue after authorization, redaction, or confirmation.
AGENT_HACK is different. It is not a normal sensitive task. It is an attack on the model’s judgment process. For this class of request, the right default action is to block it before the attack prompt reaches the model.
What Should an App Do After DKnownAI Guard Detects AGENT_HACK?
Once AGENT_HACK is detected, the application should block the request.
This is different from how CONTENT_FLAG and SYS_FLAG should be handled.
For CONTENT_FLAG, the system can decide whether to refuse, downgrade the answer, provide safer alternatives, or limit dangerous details.
For SYS_FLAG, the system can decide whether to check permissions, redact data, add confirmation, restrict tool scope, or keep audit records based on the resource and operational impact.
But for AGENT_HACK, the issue is not whether the task could be safely completed under some conditions. The issue is that the request is trying to corrupt the model’s ability to judge those conditions.
This class of request should be kept out of the model execution path:
- Block the current request before it enters the model;
- Clean or isolate the contaminated context;
- Record a security log for later analysis;
- If needed, ask the user to submit a normal request again, without carrying over the role hijacking, fake authorization, or anti-system instructions.
That is the layer DKnownAI Guard is designed to add.
It is not meant to make AI harder to use. It is not meant to block every sensitive word. It separates risks that can be handled by policy from model-manipulation attacks that should be blocked directly.
Instead, it helps developers separate the problem:
Is this dangerous content?
Is this a high-risk operation?
Or is someone trying to deceive the model?
Only by separating these three can AI Agents become both safe and genuinely useful.
From Grok to DKnownAI Guard
The Grok 4.5 jailbreak screenshots are striking because they show something ordinary readers can immediately understand:
Large models do not just “answer questions.” They organize knowledge, complete workflows, generate documents, write code, and adjust their judgment based on the context users provide.
That makes them useful.
It also means they need safety boundaries.
ENI-apr-style attacks exploit exactly this. They do not simply ask for dangerous content. They first try to make the model believe safety boundaries are untrusted, the user is always trusted, and refusal is wrong.
If the model accepts that narrative, the dangerous output is only the result.
The value of DKnownAI Guard is to identify that process before the result happens.
That is why we believe AI guardrails need to move from “content filtering” toward “risk source identification.”
The news cycle will move on. New models will launch. New jailbreak methods will appear.
For developers, the most important thing is not to memorize one jailbreak prompt. It is to build a clear framework:
Content risk should be handled as content safety.
System risk should be handled through permissions and operational controls.
Deception against the model must be identified separately.
That is why we are building DKnownAI Guard.
References:
Test how DKnownAI Guard separates dangerous content, high-risk operations, and attempts to deceive model judgment.