Image generators ship with safeguards, and every few months someone claims to have broken them. The RISE paper is worth reading because it argues the old claims were inflated. In the RISE paper on arXiv, a four-author team (which press coverage ties to the safety startup White Circle, and which White Circle's research page also describes) reports that under strict, human-calibrated scoring, earlier red-teaming methods that advertised success rates around 30% fall to near zero on modern hardened APIs, while their own method reaches up to 13%.
That is a smaller number than a headline would like, and it is more credible for it. This post separates what the paper says from what press coverage adds, explains why measurement is the real story, and lists what teams building on image models should do.
TL;DR
| Question | Answer | Source |
|---|---|---|
| What is RISE? | Automated red-teaming that evolves reusable attack strategies | arXiv abstract |
| Models tested | DALL-E 3, Nano Banana 2 (Google), GPT-Image-2 | arXiv abstract |
| Best result | Up to 13% human-verified attack success rate | arXiv abstract |
| Older methods under same scoring | Near zero (from reported ~30%) | arXiv abstract |
| Newer models (ChatGPT Images 2.5, Nano Banana 2.1) | Reportedly significantly more vulnerable | Press coverage, not verified |
| Code released? | Planned, not yet | Press coverage |
| Vendor response | None found | Press coverage |
What the paper says
The abstract makes two arguments. First, on modern production image systems, successful violations are rare and previously effective human-written seeds are often patched out. Second, existing automated red-teamers fail for two reasons: unreliable success measurement and poor exploration.
On measurement, the authors find that judges widely used in earlier work are unreliable when the unsafe target is vague: they either miss true violations or reward harmless borderline images from hardened APIs. They respond by defining strict category-specific success criteria and calibrating strong vision-language-model judges against human labels.
On exploration, they argue that prompt-rewriting pipelines stay tied to their seed prompts, fail to transfer, or cannot bootstrap positive examples. RISE instead evolves reusable strategies for generating prompts, then reuses the best strategies across new scenarios. The result is the 13% human-verified figure, a ceiling and not an average.
Why the measurement point matters most
Red-teaming numbers are easy to inflate. If a judge counts a mildly suggestive image as a violation, success rates rise without any real safeguard failing. If a judge misses real violations, success rates fall. Calibrating against human labels is the unglamorous work that makes a number meaningful, and it is why a lower success rate under strict rules can be more informative than a high one under loose rules.
For anyone evaluating a safeguard, the lesson is to ask how success was defined, who labeled it, and whether the automated judge was checked against people. The same questions apply to the jailbreak claims we have covered elsewhere, such as the claimed-versus-verified analysis of an AI-assisted console jailbreak.
What press coverage adds
PurePC, in a report that cites Ars Technica, arXiv and White Circle, adds several details we could not find in the abstract:
- The work is attributed to White Circle, described as a public benefit corporation whose founder, Denis Shilov, published a widely discussed universal jailbreak method in October 2024.
- The attack uses an open Qwen model from Hugging Face to generate prompts and Gemini 3.8 Flash to judge the output images, which shows it does not require proprietary frontier systems.
- White Circle reportedly tested newer versions, ChatGPT Images 2.5 and Nano Banana 2.1, and found them significantly more susceptible than previous versions.
- OpenAI and Google did not answer Ars Technica's questions.
- The team plans to release code and the test procedure, and to present at NeurIPS 2026 in November.
We link the report only as secondary context. The newer-model claim is the part most likely to be quoted and the part we are least able to verify. Our own coverage of those releases is in ChatGPT Images 2.5 and Nano Banana 2.1.
How automated red-teaming works, in plain terms
A green probe pressing on a small crack in a shell, illustrating automated red-teaming of image-model safeguards
Automated red-teaming has three moving parts: something that proposes attacks, the target system, and a judge that decides whether the attack worked. Earlier systems mostly improved the first part by rewriting prompts until one slipped through. The RISE authors argue the bottleneck is elsewhere. If the judge is sloppy, the proposer optimizes for fooling the judge rather than breaking the safeguard, and the reported success rate measures the wrong thing.
Their answer is to fix the judge first, using strict category-specific criteria checked against human labels, and then to search over strategies, the reusable recipes behind prompts, rather than over individual prompts. A strategy that works in one scenario can be applied to new ones, which is what the abstract means by transfer. This also explains the press framing that the attack needs no extra training: it uses existing models for generation and judging.
What the findings do not show
- They do not show that every image generator is equally easy to break, or that an ordinary user can do it easily. Thirteen percent is a best case from an automated, resourced attack.
- They do not show real-world harm. The paper measures policy violations in test categories, not distribution of harmful content.
- They do not show that the new models are worse in general, only, per the press, that the same attacks worked more often on them.
- They are one team's results. Independent replication will need the released code.
The researchers say they are withholding the criteria for some categories and the discovered strategies, final prompts and unsafe images because of misuse risk. That is a sensible restraint, and it also means outsiders cannot check everything yet.
Why this matters now
Image generators are a product surface where safeguards are tuned against a moving target: each release adds capability and may change what the filters catch. The press report quotes the point plainly: safety testing has to be repeated after every capability update, not done once. A related concern is that independent evaluators may be asked to sign broad confidentiality terms; the same report says White Circle does not want agreements that could limit publication of important findings. That is the company's stated position, reported second-hand.
For context on how labs treat evaluator access and incident disclosure more broadly, see our coverage of how security experts see lab containment practices.
What builders and teams should do
- If you wrap an image API, do not rely on the vendor filter alone. Add your own input and output checks suited to your product and audience.
- Re-test after model upgrades. A new model version can change what passes. Keep a small, private regression set of prompts relevant to your policies.
- Check how safety numbers were measured. Prefer results with human-verified labels over automated-judge-only scores.
- Log and review. Keep records of prompts and flagged outputs so you can investigate misuse.
- Plan for takedowns and reporting. Know how to report abuse to the vendor and what your own process is.
- Add runtime controls where agents generate images. If an agent can call image tools on its own, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.
We deliberately leave out prompt details and strategy specifics. They are not needed to understand the result, and the authors are withholding them for the same reason.
Why a smaller number is better news for defenders
A vendor can act on a calibrated 13%. It points to specific categories and strategies that need tighter filters, and a rerun after a patch shows whether the number fell. A 30% figure built on a lenient judge cannot be acted on in the same way, because nobody knows how much of it was real. The paper's contribution is therefore as much a measurement standard as an attack. If the released testbed and judge criteria hold up, they could become a shared yardstick for comparing image-safety claims across vendors, including the ones that ship updates every few weeks.
That is also the fairest reading of the "newer models are worse" claim. If it is borne out by the released code, it would show a pattern worth watching: capability upgrades that raise quality may loosen filters that were tuned on the previous model. If it is not, it will be one more headline that outran its evidence.
Questions people are asking
Is 13% low or high? For a rare, policy-violating output from a hardened production system, a one-in-eight success rate for a determined automated attacker is meaningful. For an everyday user who types a request, the paper does not say it is that easy.
Why use open models to attack closed ones? It shows the barrier is low: you do not need a frontier model to generate attack prompts or judge images. That is a design warning for defenders, who cannot assume attackers lack capable tools.
Will vendors patch this? Likely they will respond to specific findings, but the strategy-evolution approach is designed to find new routes as old ones close. Expect an ongoing contest, not a one-time fix.
Where can I read the paper? The arXiv page has the abstract, PDF and HTML version.
Related reading
- ChatGPT Images 2.5 launch
- Nano Banana 2.1 half-price image model
- Nano Banana 2.5 from Google DeepMind
- Experts: labs skip security basics
- Claimed vs verified: an AI-assisted jailbreak
- Perplexity Space escape red-team
Based on the arXiv abstract (submitted September 28, 2026) and press reports dated October 14, 2026; code and full results may change the picture.
