Notice
This article is based on SentinelLabs’ AI security evaluation research and related cybersecurity materials made public as of July 24, 2026. It also includes analysis by DANA NOTES.
What This Article Covers
AI model capabilities are advancing rapidly. The latest AI systems are now being used not only to write code or find errors, but also to analyze software structures and trace how malware operates.
However, real-world work often does not end with solving a single problem. In many cases, multiple judgments are connected and the work continues over a long period of time.
A judgment that initially seemed correct may later turn out to be wrong because of new information. The problem is that by then, many other tasks may already have been carried out based on that judgment.
At that point, can AI recognize that it was wrong?
And beyond simply correcting its current answer, can it identify and revise the analyses and files it previously created based on that incorrect judgment?
SentinelLabs, the research organization of cybersecurity company SentinelOne, introduced a new AI evaluation framework (benchmark) designed to assess this capability through real-world malware analysis.
A benchmark refers to an evaluation framework used to compare the performance of multiple AI models under the same conditions.
A Second AI Challenge Using Fast16
There had already been an earlier attempt to have AI analyze Fast16.
On April 23, 2026, SentinelLabs researcher Vitaly Kamluk presented the results of having what were then the latest AI models autonomously analyze Fast16 at Black Hat Asia.
Opus 4.6, GPT-5.4, Grok 4.2 Reasoning, Gemini 3.1 Pro, DeepSeek Reasoner, and others attempted to analyze Fast16, but the results were not good.
Even in the best cases, the AI identified Fast16 as a rootkit and failed to move beyond that explanation.
A rootkit is a malicious tool that hides deep inside a system in order to conceal its own presence or other malicious activity.
In other words, in the first attempt, AI autonomously analyzed Fast16, but it remained stuck on its initial explanation of Fast16 as a “rootkit,” without connecting that judgment to the malware’s deeper structure or actual purpose.
Meanwhile, unlike cases where AI performed the entire analysis on its own, considerable benefits were observed when humans and AI worked together.
An analysis task that had originally taken an experienced security analyst about three weeks was completed by a relatively less experienced security analyst working with AI in approximately 8 to 10 hours.
In other words, AI had not yet reached the point of fully replacing humans, but it showed significant potential for productivity gains when humans determined the direction and worked with AI throughout the analysis process.
About three months later, on July 22, 2026, SentinelLabs released the results of a new study using a different evaluation method.
This time, the actual Fast16 investigation process was divided into eight stages.
As the AI carried out the analysis, humans progressively provided it with new materials and evidence.
Each time new information was introduced, the AI had to connect it with what it had already analyzed and continue to the next task.
In particular, when new evidence conflicted with an earlier judgment, the evaluation examined whether the AI could do more than simply change its current answer and instead identify and revise earlier analyses affected by that incorrect judgment.
The difference between the publication dates of the two studies was only about three months. However, because both the models used and the evaluation methods differed, the difference in results cannot be explained simply as an improvement in AI model performance. In particular, the second study also changed the way work was assigned to and evaluated for the AI.
In this evaluation, GPT-5.5 failed to move beyond the first stage.
GLM-5.2 also demonstrated partial analysis and error-recovery capabilities but was unable to complete the full process.
Opus 4.7 and 4.8 progressed through more stages but did not complete all eight.
By contrast, GPT-5.6 Sol completed all eight stages in each of three experiments conducted under different settings.
What Was This Experiment Trying to Find Out?
The purpose of the study was not simply to compare which AI could analyze malware most accurately.
The central question SentinelLabs wanted to examine was this:
Can AI restore the entire investigation process to a trustworthy state even when new evidence overturns an earlier judgment?
Put more simply, the question was:
“How far back can AI go when it discovers that it was wrong?”
The goal was not merely to revise a single current answer, but to determine whether the AI could identify and correct analyses and files that had already been created based on the incorrect judgment.
A court precedent provides an easy way to understand this.
In court, precedents become important standards for later decisions. Even when social conditions or perceptions change, overturning an existing precedent requires reviewing the accumulated grounds on which previous judgments were made.
A similar problem can arise for AI agents performing long-running tasks.
If an AI makes one incorrect judgment early on and then continues creating additional analyses and files based on that judgment, simply correcting the first conclusion may no longer be enough as time passes.
The system must identify which of the outputs created along the way were influenced by the incorrect judgment and revise the necessary parts as well.
This is exactly the capability that the study evaluated using a real malware analysis process.
Why Fast16?
There are countless types of malware in the world.
SentinelLabs did not choose Fast16 simply because it is old or because it is difficult to analyze.
Fast16 has a structure that makes it easy to reach the wrong conclusion when judged only by its initial appearance.
SentinelLabs explains that Fast16’s hierarchical structure “punishes shallow analysis.” From the outside, the kernel driver can easily be mistaken for a filesystem rootkit, but inside it is actually a patch engine containing 101 patch rules.
In other words, its visible characteristics make it easy to jump to an early conclusion, while understanding its real purpose requires continuously connecting its internal structure with multiple pieces of evidence.
Fast16 itself also has an unusual background.
Fast16 is malware believed to have been created around 2005. It was analyzed as being designed to interfere with the computation process of LS-DYNA, a high-precision simulation program used in engineering, and secretly alter its results. It has drawn attention as a case that predates Stuxnet, the malware associated with attacks on Iranian nuclear facilities, by at least five years.
Fast16 was therefore well suited to evaluating not simply whether AI could find the correct answer in one attempt, but whether it could question its initial judgment, incorporate new evidence, and abandon its previous interpretation when necessary.
When Did GPT-5.6 Sol Realize Its Judgment Was Wrong?
An interesting point is that GPT-5.6 Sol, despite completing all eight stages, did not make every judgment correctly from the beginning.
During the analysis, GPT-5.6 Sol found that some of Fast16’s patterns appeared not only in LS-DYNA but also in other programs.
At first, based on this result, it proposed the possibility that Fast16 was not malware designed to interfere with a specific program, but instead some kind of compatibility tool intended to work across multiple programs.
However, further analysis revealed a difference.
In LS-DYNA, multiple patterns were connected and actually altered the program’s behavior, while the patterns found in other programs were closer to coincidental matches with similar code.
At this point, GPT-5.6 Sol determined that its initial explanation did not fit the evidence.
And it withdrew the earlier hypothesis.
Among the facts actually confirmed in the earlier analysis, it kept the parts that were correct, while reestablishing as its baseline explanation that Fast16 was malware intentionally designed to interfere with the normal operation of LS-DYNA.
It did not stop there.
It also revised the work records so that the hypothesis it had already determined to be wrong would not later be reused as though it were a fact.
In other words, it did not simply produce a new answer.
It recognized that its earlier judgment was wrong and corrected the state of the project that had been built around that judgment.
SentinelLabs describes this capability as Project-scale recovery, meaning the ability to recover at the level of the entire project.
However, one distinction must be made clearly.
GPT-5.6 Sol itself performed the correction process, but the overall evaluation was not conducted completely autonomously without human involvement.
The researchers set the investigation goals, progressively provided new materials and evidence, pointed out important blind spots, and judged the quality and publication readiness of the final output.
This means that even the AI agent that produced the strongest result still required supervision from an experienced security analyst.
Another Capability Revealed by the Experiment
The ability to correct incorrect judgments was not the only capability required for long-running work.
A different problem occurred in the GLM-5.2 experiment.
During the analysis process, an error occurred in which 113 embedded functions being worked on were lost.
However, GLM-5.2 located an earlier backup, restored the lost content, and resumed the analysis.
GLM-5.2 did not complete all eight stages, but this case demonstrates an important point.
AI agents need more than the ability to reason well.
They also need a structure that can save what has been done so far, preserve previous working states, and return to a normal state when a problem occurs.
Ultimately, the real-world performance of an AI agent may not be determined solely by which AI model is used.
The operating system around the agent may also matter, including how work records and files are managed, how previous states are stored, and how far the system can recover when an error occurs.
Why Does This Capability Matter in Long-Running Work?
Consider how a human performs work directly.
Input → Process → Output
A person receives an input, carries out the work process directly, and produces a result.
Therefore, when something goes wrong with the result, the person can retrace the process they followed.
“Where did this start going wrong?”
They can think about that question and review each earlier step one by one.
However, when most of the work process begins to be delegated to an AI agent, the structure changes.
Input → AI Agent → Output
The person knows what was provided as input and what result was produced.
But the person did not directly perform every step in between, including the AI’s review of large amounts of information, its judgments, and the files it created and modified.
As a result, it may be more difficult to understand which judgments became the basis for which results than it would be if a person had performed the work directly.
With short conversational AI interactions, if an answer is wrong, the user can ask again or check the content manually.
But the situation changes when an AI agent works on a single project for a day, two days, or longer.
If one incorrect judgment is made early in the process and additional analyses and files continue to be created based on that judgment, the scope of the error also expands.
If a person had performed the work directly, they would know the entire process and could retrace it step by step when a problem appeared in the final result.
But if a company begins delegating most of its work process to AI agents, humans may know only the input and final output while having insufficient visibility into the intermediate judgments the AI made.
In that situation, even discovering that the final result is wrong may become difficult.
Even after a problem is found, identifying the exact cause requires reviewing the process the AI previously carried out. In some cases, a person may have to repeat the entire task from the beginning using the existing workflow just to verify the result.
But if a human must redo the entire task, the time and cost that AI was introduced to reduce will reappear.
The cost of verifying the AI-generated result and process may even be added on top.
From a company’s perspective, therefore, what matters is not only how much work an AI agent can automate.
It may also become important to determine whether the organization can trace where the problem occurred, identify the outputs affected by that judgment, correct them, and verify the result without requiring a human to perform the entire task again.
Trust in AI agents is also connected to this issue.
If an AI produces an incorrect result in an important task and the company cannot determine the cause or the scope of its impact, the organization may find it difficult to trust other results produced by the AI afterward.
In the long term, therefore, process traceability, error-recovery capability, and verification cost may become important criteria for evaluating AI agent adoption alongside model accuracy.
What Should Companies Look At?
1) Verification Cost
The fact that AI completed a task quickly does not necessarily mean that costs were reduced.
For example, even if AI finishes in a few hours an analysis that would have taken a person several days, the situation changes if a human must repeat the same work from the beginning in order to determine whether the result is correct.
The work time that AI was introduced to reduce reappears during the verification process.
In some cases, AI usage costs and the cost of verifying AI-generated results may even be added to the original cost of the work.
Companies should therefore look not only at how quickly AI performs a task, but also at whether the result can be verified without requiring a person to repeat the entire process.
2) Trust
A bigger problem than AI producing one incorrect result in an important task may be a situation in which no one knows why it was wrong or how far the error spread.
If one error is discovered but its cause and scope of impact cannot be determined, the organization may not stop at questioning only that result.
It may lead to the question:
“Then are the other results this AI produced before actually reliable?”
Once trust in an AI agent drops significantly, restoring that trust may require more verification procedures and greater human involvement.
The reliability of an AI agent is therefore connected not only to its accuracy rate, but also to whether it can trace the cause of an error and properly correct the outputs affected by it.
3) Investment Decisions
Corporate AI investment is unlikely to end with simply selecting the highest-performing AI model.
Even when the same AI model is used, actual workplace performance may vary depending on how well the system records work, stores previous states, and enables recovery when a problem occurs.
Corporate AI investment may therefore expand beyond model usage costs to investment in systems that can operate and manage AI agents reliably.
The way actual economic value is calculated may also need to change.
Rather than looking only at how many hours AI took to complete a task, companies may need to consider:
AI work cost + human verification cost + correction cost when errors occur
Only by considering all of these together can the actual effect of AI adoption be evaluated.
Ultimately, in companies, a more important productivity metric than how many times faster AI is than humans may be how many AI agents one person can manage at a level that remains trustworthy.
What to Watch Going Forward
First, it will be important to see how far human supervision can be reduced.
In this study, even GPT-5.6 Sol, which completed all eight stages, did not work completely independently from humans.
It will be important to see whether the process can evolve from humans having to review every stage, to reviewing only critical points, and then eventually to approving only the final result.
Second, it will be worth watching whether methods for evaluating the reliability of real-world work lasting several days or longer spread to other fields.
In software development, research, data analysis, and corporate report writing, the ability to solve a single problem correctly and the ability to perform a multi-day project reliably may be very different.
In the future, therefore, evaluation may increasingly focus not only on how good the AI’s first answer is, but also on whether it can maintain the reliability of its results over long-running work and revise earlier work when it discovers that a previous judgment was wrong.
Third, it will be necessary to verify whether actual cost savings appear.
The fact that AI works faster than humans does not automatically increase corporate productivity.
If a large amount of human time is still required for result verification and error correction, the actual cost savings may be smaller than expected.
By contrast, if AI agents can preserve records of their own work, trace errors, and recover the areas affected by incorrect judgments, one person may be able to manage more AI agents.
Ultimately, the economics of AI agents may be determined less by what percentage of human work they automate and more by how much AI-driven work one person can manage at a level that remains trustworthy.
DANA NOTES Commentary
The key point demonstrated by this study is that it is becoming increasingly difficult to evaluate AI agent performance based solely on accuracy.
GPT-5.6 Sol also formed an incorrect hypothesis during the analysis. The goal is not to ensure that AI never makes a mistake.
What matters is whether, when new information arrives, the AI can recognize that it does not fit its existing judgment and reexamine its earlier process.
The reason its results differed from those of other models was not that it never made a mistake. Rather, after identifying that its previous explanation did not fit the new evidence, it withdrew the earlier judgment and revised the work that had been affected by that judgment.
With conversational AI, a person is watching the conversation. If an unusual answer appears, the user can immediately ask another question or compare it with an earlier response.
But when the work process itself is delegated to an AI agent over a long period of time, the situation changes. A single incorrect judgment can become the premise for numerous subsequent analyses and files.
If an AI agent cannot even recognize that it is moving in the wrong direction, it is not only the work that becomes automated. The process by which an incorrect judgment expands can also become automated.
For AI agents performing long-running tasks, therefore, the ability to identify where their own judgment went wrong and restore the work affected by that error to a normal state may become more important than simply producing the correct answer the next time.
As the GLM-5.2 case showed, systems are also needed to preserve the state of work completed so far and recover when problems occur.
Ultimately, as AI agents move into real corporate workflows, the ability to reexamine their own judgments and determine how far they can roll back when an error occurs is likely to become an important performance criterion alongside accuracy.
