Is your LLM system prompt jailbreak-resistant?

What the tool actually checks

Prompt injection is the single most prevalent failure mode of production LLM systems. Most successful injection attacks exploit the same handful of missing defensive patterns: prompts that don't forbid revealing instructions, prompts that lock a role but allow role-play overrides, prompts that don't treat user input as data, prompts that don't enumerate the refusal language, prompts that have no encoding-attack defense. This tool runs deterministic checks for the presence of these patterns against the text you paste — five foundational checks free, twenty extended attack-class checks behind a one-field email gate.

What it does NOT do: send live payloads to a real LLM. There is no API key, no model fingerprinting, no temperature probing, no agentic-loop testing. Real vulnerability against a specific model with specific tools and a specific user-input pipeline requires runtime testing. This tool is the first-pass static analyzer — the equivalent of running a linter on your prompt — not the full red-team engagement.

Why static analysis catches most production failures

The published prompt-injection corpora — Promptbase jailbreaks, OWASP LLM Top 10 reference attacks, the "DAN" family, the Anthropic "assistant gone rogue" cases, the Bing Sydney leak, the GPT system-prompt extractions — overwhelmingly succeed because of missing defenses, not because of novel cryptographic attacks. The defenses that close them are well-known and well-documented. The problem is that developers shipping LLM features don't always have an explicit checklist to apply when authoring the prompt.

The 25-test catalog here IS that checklist. Each test corresponds to a defensive pattern that, when present, has been shown to block a specific attack family across multiple model providers. Apply the remediation snippets, re-run the analyzer, and you've hardened against the majority of off-the-shelf payloads. The remaining attack surface — novel adversarial prompts, model-specific vulnerabilities, multi-turn manipulation, tool-call abuse — is what live runtime testing is for.

Six attack-class categories the tool covers

Who runs this tool

What the grade does NOT mean

An A on this tool does NOT mean your LLM-backed application is secure. It means your system prompt has the foundational defensive patterns in place. Your application security still depends on: how you wire user input to the model, whether you trust outputs verbatim, whether you grant the model tool access without output validation, whether your RAG sources are themselves trustworthy, whether your model can call functions with arbitrary parameters, whether your downstream consumers handle markdown / HTML / SQL injection in model output, and whether you log adversarial conversations for review.

Conversely, an F does NOT necessarily mean your application is broken — if your LLM has no tool access, no sensitive data, no extraction surface, and a low-risk use case, a weak prompt may be operationally acceptable. The grade is decision-support, not a verdict. For organizations in regulated sectors (healthcare, financial services, government contractors, education) where AI failure carries audit risk under HIPAA, SR 11-7, NYDFS Part 500, CMMC 2.0, the Colorado AI Act, or NIST AI RMF accountability, the managed AI Risk Audit is the appropriate validation artifact.

FAQ