Alejandros17487/ai-jailbreaks describes 35 paste-ready prompts for more than 25 model targets and instruction surfaces. Teams should not paste them into production assistants or coding agents. The practical response is a seven-question intake gate that records prompt scope, model version, permissions, test environment, expected failure, stop conditions and evidence.
At a glance
- The GitHub collection says its files can target system prompts, workspace instructions, agent files and local-model configuration.
- A research repository contains 10,800 jailbreak attempts from 35 attack methods, showing why one keyword filter cannot cover prompt risk.
- Published guardrail work spans input detection, prompt transformation, model-internal signals and a separate “shadow” model that checks requests.
- A safe red-team run has no production secrets, no standing tool permissions and a written stop rule before a prompt is tested.
What does the GitHub collection contain?
The repository is not one kind of prompt. Its README groups complete prompts as system messages, persona definitions, workspace policies, AGENTS.md files, configuration blocks and Ollama Modelfiles. That distinction matters because each surface has a different reach: a one-off chat request is not equivalent to persistent project instructions or a model definition file. The repository’s own usage notes say where each format is intended to be pasted.
Its stated research purpose does not remove the operational risk. A paste-ready instruction can be copied into a client that has repository access, browser access or tools that change files. Treat the prompt as untrusted test material, even when its visible text looks like a role-play request or a harmless configuration template.
The repository also says prompt behaviour depends on the model version and its instruction hierarchy. That means a red-team finding is a dated observation, not a permanent property of a model family. Record the exact model identifier, client or agent harness, system instructions and enabled tools with every result.
What should the intake gate check?
The intake gate should answer one question before anyone tests a prompt: what could this text cause the connected system to do A jailbreak is not only a request for disallowed prose. In an agent, it can try to change instruction priority, redirect tool use, expose data or alter a workflow.
- Classify the instruction surface. Mark the item as a chat prompt, system prompt, project instruction, configuration field or model file. Persistent surfaces need stricter review.
- Name the target precisely. Capture provider, model version, client version and any wrapper. Do not write only “Claude,” “Qwen” or “local model.”
- State the expected failure. Define the boundary being tested: unsafe content, instruction override, secret disclosure, unauthorised tool selection or policy evasion.
- Remove valuable context. Use synthetic files, dummy credentials and a test account. Do not expose a real repository, browser profile, API key or cloud environment.
- Reduce permissions first. Disable shell execution, network access, write operations and high-impact tools unless one is the explicit subject of the test.
- Set a stop rule. Stop if the model requests sensitive data, tries to invoke an unapproved tool, changes a test file or produces a prohibited output category.
- Capture evidence. Save the prompt hash, configuration, model response, tool-call trace and reviewer decision. Do not keep unnecessary copies of harmful text.
Operational rule: do not turn a public jailbreak into a “paste this to win” internal recipe. The useful deliverable is a reproducible safety finding and a mitigation decision, not a stronger prompt.
Which prompt details change the risk?
Instruction placement changes the likely blast radius. A prompt submitted in a normal user message usually ends with the session. A workspace policy or agent instruction can affect many later requests. A local-model configuration can travel with a model image or be shared as a file, so its provenance and review history matter.
A second risk is whether the prompt is designed for a model-only conversation or for a tool-using agent. In a tool-using setup, a bad response can become an attempted action. A recent security demonstration showed that altered open-model weights could make a coding agent act differently only after a chosen trigger, while otherwise appearing normal in clean use. ProjectDiscovery’s October 2026 report is a supply-chain warning: prompt screening does not replace checking where model weights and adapters came from.
Third, do not infer a universal jailbreak signature from familiar phrases. The What Features in Prompts Jailbreak LLMs project says its dataset covers 10,800 attempts from 35 attack methods. Its central result is that different methods use different nonlinear features, and probes that identify known methods can transfer poorly to held-out methods. In plain English, a detector trained on yesterday’s examples can miss a differently worded attack tomorrow.
What promises did guardrail research make?
Research has steadily moved from single filters toward layered controls, but each layer has limits. The dated timeline below separates what each project proposed from what it demonstrably shipped in its published evaluation. It is a useful test-plan history, not evidence that any one defence protects every model or prompt surface.
-
Baseline Defenses proposed three practical layers. The paper submitted that day evaluated attack detection based on unusual text statistics, input preprocessing through paraphrasing or retokenisation, and adversarial training. What shipped was a comparison of those categories under stated threat models, alongside a warning that robustness and normal performance can trade off. -
GradSafe promised a detector without additional safety training. The ACL 2024 paper used gradients, or signals showing how model parameters would change during learning, around safety-critical parameters. The published evaluation said the method detected jailbreak prompts on Llama-2 without further training and compared it against Llama Guard on the named tests. -
Gradient Cuff proposed a two-step refusal-loss check. Its NeurIPS 2024 publication defined “refusal loss” and examined its value and smoothness to flag attacks. The reported experiments covered two aligned models and six named attack types, with a threshold intended to preserve benign-request performance. -
SelfDefend promised a separate model watching the main model. The USENIX Security 2025 paper described a shadow large language model that detects harmful intent while a target model handles normal answers. The published system was designed to work with both open and closed target models, rather than requiring a vendor to expose internal weights. -
A guardrail review argued for broader evaluation. The revised SoK paper proposed six dimensions for classifying jailbreak guardrails and a Security-Efficiency-Utility framework. What it adds is an evaluation warning: a guardrail should be measured for security, delay and normal-user usefulness, rather than only for attack rejection.
Which screening method fits each prompt?
No screening method answers every intake question. The useful comparison is not “which paper wins?” It is which layer can observe the prompt, whether the team controls model internals and what happens if the layer fails. This is the operational comparison most public prompt collections do not publish.
| Intake question | Useful control | What the control can establish | What it cannot establish alone |
|---|---|---|---|
| Does the text contain suspicious structure | Input detector or policy classifier | Whether to block, route or require review before the target model sees it. | Whether a harmless-looking prompt will cause unsafe tool use later. |
| Is the attack brittle to wording changes | Prompt transformation and repeated evaluation | Whether small changes alter the result, which can expose some adversarial text. | Whether transformed prompts preserve the intended meaning for legitimate users. |
| Do we control the model weights | Internal-signal methods | Whether model-specific features such as gradients or refusal behaviour add a warning signal. | Protection for closed models whose internals are unavailable. |
| Could the request reach tools or data | Least privilege, sandboxing and approval gates | Whether an unsafe answer can become a damaging action. | Whether the model will always classify intent correctly. |
The first published baseline study framed detection, preprocessing and adversarial training as distinct defences, not substitutes. Its analysis is still a sound intake lesson: test the control against the threat model you actually have. A public prompt aimed at a system-message field needs a different test from an indirect instruction embedded in retrieved web content.
How should a red team handle paste-ready prompts?
Use a segregated evaluation environment. The target should have a minimal policy, synthetic documents and only the tool permissions needed to test the stated risk. A coding-agent test, for example, can begin with read-only access to a disposable repository and no network route.
Test one variable at a time. First establish a benign baseline with the same model, system prompt, tools and files. Then introduce the reviewed prompt. If the test changes several variables at once, such as model version, agent harness and instruction hierarchy, the result will not tell the engineering team what to fix.
Keep the test prompts in a restricted repository or ticket system. Give the file a stable identifier, but avoid distributing raw material through broad chat channels. The aim is controlled reproduction by authorised reviewers, not creating an internal prompt library that others can misuse.
A red-team reviewer should also distinguish a refusal failure from a system compromise. A model that produces a weak answer may show an alignment gap. A model that requests secrets, calls a tool or attempts an unauthorised write is an application-control failure as well. These need different owners and different fixes.
What should the test record show?
Every completed case needs a short evidence record that a product, security and platform team can all read. Technical detail matters, but the decision must remain clear: block, constrain, monitor, fix, accept temporarily or retest after a model update.
- Case ID and reviewer: who approved the test and who may access the raw material.
- Environment: model identifier, provider or local runtime, client version, system instructions and tool list.
- Prompt category: direct jailbreak, instruction conflict, persistent workspace policy, configuration change or suspected supply-chain artefact.
- Expected and actual outcome: refusal, safe completion, policy bypass attempt, tool-call attempt or data-access attempt.
- Containment evidence: sandbox state, synthetic-data confirmation and whether any tool invocation was blocked.
- Decision: the mitigation owner, due date and the exact condition required for retest.
Do not score only attack success. The guardrail review accepted for IEEE S&P 2026 calls for security, efficiency and utility to be considered together. That framework is useful because a detector that blocks a large share of safe requests can be unsafe in practice: users will work around it or abandon the protected path.
What we could not verify?
Public repository text does not establish that every listed prompt works against every named model, client or current version. The collection itself notes that model updates and changing instruction hierarchies can alter results. Only a controlled test on the exact target version can settle compatibility.
There is also no public universal threshold that says when a jailbreak detector is safe enough for a production agent. Model providers, application owners and independent evaluators would need to publish comparable tests covering benign requests, adversarial prompts, tool permissions, response delay and false blocks to settle that question.
Sources
- PRIMARY SOURCE — Alejandros17487/ai-jailbreaks
- PRIMARY SOURCE — What Features in Prompts Jailbreak LLMs
- PRIMARY SOURCE — Baseline Defenses for Adversarial Attacks Against Aligned Language Models
- PRIMARY SOURCE — GradSafe: Detecting Jailbreak Prompts for LLMs
- PRIMARY SOURCE — Gradient Cuff
- PRIMARY SOURCE — SelfDefend
- PRIMARY SOURCE — SoK: Evaluating Jailbreak Guardrails for Large Language Models
- ProjectDiscovery — How abliterated models can get you pwned
