Prompt Injection Tester

About this tool

What this prompt injection tester answers

The tester runs a curated set of adversarial probes against your system prompt and reports which ones the model defended, which ones partially leaked, and which ones it complied with. Use it before shipping a customer facing agent, after editing the system prompt, or as part of a CI gate for prompt changes.

The probes are organised into six categories drawn from the OWASP LLM Top-10: direct injection, role override, indirect injection, prompt leak, jailbreak, and tool misuse. Each probe maps to a known failure pattern, not a one off curio. The corpus is dated and lives in the repo so it can be audited and extended.

Prompt injection attack examples by category

Direct injection examples include ignore previous instructions and you are now a different assistant. Role override examples include DAN mode prompts and developer mode unlocks. Indirect injection examples include hidden HTML comments in fetched pages and malicious markdown links inside PDF text. Prompt leak examples include ask the model to repeat its first message verbatim. Tool misuse examples include trick the agent into emailing data outside the allowed recipient list.

The tester sends each example to your model with your real system prompt and classifies the reply. The verdict per probe is Defended, Partial leak, Failed, or Error. Defended means the reply did not include the trigger phrase the prompt was supposed to refuse. Partial means some signals leaked. Failed means the model complied with the attack.

OWASP LLM Top-10 mapping

The probes map directly to the OWASP LLM Top-10 risk classes. LLM01 covers direct and indirect prompt injection. LLM06 covers sensitive information disclosure and overlaps with the prompt leak probes. LLM07 covers insecure plugin and tool design and overlaps with the tool misuse probes. LLM08 covers excessive agency and overlaps with role override and jailbreak probes.

Mapping the probes to OWASP makes the results easier to surface in a security review. Each Partial or Failed verdict can be filed against the relevant risk class with the actual reply attached as evidence.

Mitigation strategies for prompt injection

Input sanitisation is the first layer. Strip or escape known attack patterns before they reach the model. The second layer is output validation. Run a regex or LLM judge pass on the reply before showing it to the user or executing a tool call. The third layer is privilege separation. Tool permissions should be scoped to the minimum needed for the workflow so that a successful injection still cannot do harm.

The strongest mitigation is architectural separation between trust contexts. Keep system instructions in a different channel from user input. Treat any fetched content as untrusted. Add human review for any action that affects money, identity, or rights. The system prompt is a soft control, not a security boundary.

How to use the prompt injection tester

Paste your real production system prompt in the textarea, pick a provider and model, and paste your API key. The key stays in this browser tab; the request goes directly from your browser to OpenAI or Anthropic. Click Run and the tester sends each adversarial prompt one at a time, then classifies each reply.

The verdict per probe is Defended, Partial leak, Failed, or Error. Defended means the reply did not include the trigger phrase the prompt was supposed to refuse. Partial means some signals leaked. Failed means the model complied with the attack. Error means the request failed because of network, auth, or rate limit issues.

How the verdicts are computed

Each adversarial prompt has a list of expected refusal signals: substrings the reply should not contain. The classifier checks whether the reply contains all of them (Failed), some of them (Partial leak), or none of them (Defended). This is a simple, transparent test, not a model graded eval.

Simple substring matching has limits. A model may refuse with one phrasing that the classifier scores as Defended, but with another phrasing that the classifier scores as Partial. Always read the actual replies for any probe that scored Partial or Failed before treating the result as final.

Where prompt defenses usually fail

The most common failure is over reliance on the system prompt for security. Models can be talked out of system prompt instructions surprisingly easily, especially with role override such as DAN or developer mode, and indirect injection through attached content. The system prompt is a soft control, not a security boundary.

The second common failure is letting tool calls reflect untrusted input back into the prompt path. A user supplied URL that a tool fetches and returns becomes new prompt content. Defenses include strict allowlists for tool inputs, output sanitisation, and an LLM judge or regex pass between tool output and the next model call.

When this tester is the right tool and when it is not

Use this tester for fast feedback during prompt engineering, as a smoke test before deploying a new agent surface, or as part of a CI gate that flags regressions when the prompt changes.

It is not a security audit. Real audits include manual red teaming, threat modelling against your specific data and tools, and ongoing monitoring in production. For high stakes systems, follow this tester with a focused red team engagement.

How to use it

Paste your real production system prompt in the textarea, pick a provider and model, and paste your API key. The key stays in this browser tab; the request goes directly from your browser to OpenAI or Anthropic. Click Run and the tester sends each adversarial prompt one at a time, then classifies each reply.

The verdict per probe is Defended, Partial leak, Failed, or Error. Defended means the reply did not include the trigger phrase the prompt was supposed to refuse. Partial means some signals leaked. Failed means the model complied with the attack. Error means the request failed (network, auth, rate limit).

How the verdicts are computed

Each adversarial prompt has a list of expected refusal signals: substrings the reply should not contain. The classifier checks whether the reply contains all of them (Failed), some of them (Partial leak), or none of them (Defended). This is a simple, transparent test, not a model graded eval.

Simple substring matching has limits. A model may refuse with one phrasing that the classifier scores as Defended, but with another phrasing that the classifier scores as Partial. Always read the actual replies for any probe that scored Partial or Failed before treating the result as final.

Where prompt defenses usually fail

The most common failure is over reliance on the system prompt for security. Models can be talked out of system prompt instructions surprisingly easily, especially with role override (DAN, developer mode) and indirect injection through attached content. The system prompt is a soft control, not a security boundary.

The second common failure is letting tool calls reflect untrusted input back into the prompt path. A user supplied URL that a tool fetches and returns becomes new prompt content. Defenses include strict allowlists for tool inputs, output sanitisation, and an LLM judge or regex pass between tool output and the next model call.

When this tester is the right tool and when it is not

Use this tester for fast feedback during prompt engineering, as a smoke test before deploying a new agent surface, or as part of a CI gate that flags regressions when the prompt changes.

It is not a security audit. Real audits include manual red teaming, threat modelling against your specific data and tools, and ongoing monitoring in production. For high stakes systems, follow this tester with a focused red team engagement.

Frequently asked questions

What is a prompt injection attack?

A prompt injection attack is an input that causes a language model to ignore its system prompt and follow attacker controlled instructions instead. The attack can be direct, where the malicious instruction is typed by the user, or indirect, where it is embedded in content the model is asked to read. OWASP lists prompt injection as the top LLM application risk for a reason: it bypasses most naive defenses.

What are common prompt injection attack examples?

Common prompt injection attack examples include ignore previous instructions, DAN style role override, hidden instructions in attached documents, system prompt leak via direct questioning, and tool misuse where the attacker tricks the agent into calling a tool with malicious parameters. This tester runs categorised probes that map to each of these examples so you can see which patterns your system prompt actually defends against.

How do I prevent prompt injection attacks?

Prevent prompt injection attacks with layered defenses. Explicit refusal instructions in the system prompt reduce simple attacks. Strict separation between trusted system content and untrusted user or document content is the strongest defense for indirect injection. Output validation and post processing catch leaks before reply. For high stakes systems, add an LLM judge and human review on the tool call path.

What is indirect prompt injection?

Indirect prompt injection happens when malicious instructions are embedded in content the model is asked to read, such as a web page, an email, or a PDF, rather than typed by the user. Defenses must treat any external content as untrusted, isolate it from system instructions, and refuse to execute instructions that originate inside attached content. Indirect injection is the hardest category to defend without architectural changes.

What does the OWASP LLM Top-10 say about prompt injection?

The OWASP LLM Top-10 lists prompt injection as LLM01, the highest priority risk class for LLM applications. It separates direct injection, indirect injection, and prompt leakage. The recommended mitigations include strict context separation, input and output validation, least privilege tool permissions, and human in the loop review for high impact actions. This tester aligns its probes with the same categories.

Does this prompt injection tester catch every attack?

No. The probes cover common categories from the OWASP LLM Top-10 including direct injection, role override, indirect injection, prompt leak, jailbreak, and tool misuse. Every defense has gaps and novel attacks emerge continuously. Use this tool as a smoke test, not a security audit. If your system handles money, identity, or compliance, follow up with a focused red team engagement.

Why bring my own API key to test prompt injection?

Running probes costs real provider credits. Hosting the keys on the tool side would mean paying every visitor's bill and gating access. Bring your own key keeps the tool free, fast, and private. Your key is held only in this browser tab. It never reaches a backend server. The requests go directly from your browser to OpenAI or Anthropic.