How much input do I need to scan?

A few realistic samples beat one benign sentence. Include inputs that resemble production traffic, and — if you use tools or retrieval — samples that exercise those paths.

What does the report actually contain?

Which injection patterns fired, a severity read, and a hardening checklist tied to what was found. It is a decision-support artifact, not a pass/fail certificate.

Should I scan before every deploy?

Scanning on every deploy (a CI gate) catches new patterns as your app changes. PromptShield's Pro tier supports CI-ready scanning so the check runs automatically.

Does a clean report mean my app is safe?

No. It means no known patterns matched your sample. New variants exist, and a scanner targets known shapes. Pair scanning with input validation, tool guards, and a real security review.

Can PromptShield replace a security team?

No. PromptShield flags known injection and jailbreak patterns and gives a hardening checklist. It does not make an app unhackable or replace a security team or a professional review.

How to scan your AI app for prompt injection before shipping

What you need before scanning

Before you scan, gather two things: a short description of your AI app (what it does, what inputs it accepts, whether it uses tools or retrieves content) and a realistic sample of untrusted input — the kind of text a user or external source would actually send. The quality of the sample drives the value of the report, so use inputs that resemble production, not a single benign sentence.

If your app retrieves content (RAG) or calls tools, include a sample of that too. Indirect injection and tool abuse are exactly the cases a chat-only sample would miss.

Step 1 — describe your app

In PromptShield, start by describing the app: its purpose, the inputs it accepts, and whether it can call tools or read external data. This context lets the report reason about which failure modes apply to you — an agent with email access is scored differently from a read-only summarizer.

A one-paragraph description is enough. You are not configuring a firewall; you are giving the scanner enough to interpret the patterns it finds.

Step 2 — paste a sample of untrusted input

Paste the sample input into the scanner. For a support bot, that might be a few representative tickets, including at least one that looks like it might be trying something. For an agent, include a sample that references a tool by name. The point is to exercise the shapes your real traffic will contain.

Run a few samples rather than one. Injection patterns are unevenly distributed, and a single clean sample can hide a whole class of risk in the next thousand.

Step 3 — read the injection-risk report

PromptShield returns an injection-risk report: which patterns fired, how severe they appear, and a hardening checklist tied to what it found. Use it to decide what to fix first — for example, if "tool abuse" fired, tighten tool-call permissions; if "system-prompt exfiltration" fired, move secrets out of the prompt.

The report is advisory. It tells you where the known shapes are; you still decide the fix and verify it. Treat each fired pattern as a ticket, not a verdict.

Step 4 — turn it into a CI gate (Pro)

For continuous coverage, run the scan on every deploy as a CI gate (PromptShield Pro). New code changes the inputs and the prompts, which changes the injection surface — a one-time scan goes stale fast. A CI gate keeps the check automatic as the app evolves.

Set the gate to fail the build when high-severity known patterns appear in your sampled inputs. That makes injection a visible, blocking concern rather than something discovered after a customer does it for you.

Authoritative references

OWASP Top 10 for Large Language Model Applications (2025): https://owasp.org/www-project-top-10-for-large-language-model-applications/
OWASP (general application security): https://owasp.org/