Your team ships AI features faster than ever. Your LLM integration works beautifully. Your users love the new capabilities. But when did you last audit the security posture of your system prompts?
If the answer is "never" or "we eyeball them," you're not alone—and you're exposed. This checklist provides a concrete path to harden AI system prompts before they become your next incident report.
What This Checklist Covers
This is a pre-production security review for AI system prompts. You'll verify that prompts resist injection attacks, don't leak sensitive context, and follow a structured vulnerability assessment process. This checklist assumes you're working with LLM-powered features that use system prompts to constrain model behavior.
Out of scope: Model training security, API key management, general application security.
Prerequisites
Before starting this checklist, confirm you have:
- Documented system prompts - Every prompt used in production or staging must be version-controlled and accessible for review.
- AI Weakness Enumeration (AIWE) framework access - Mend.io's System Prompt Hardening uses AIWE to score vulnerabilities from 1 to 100; adopt this or an equivalent structured scoring system.
- Staging environment - You need a safe space to test prompt modifications without production impact.
- Clear ownership - Assign one person responsible for each prompt's security posture.
Checklist Items
1. Inventory all system prompts in your application
□ List every system prompt by feature, API endpoint, or user flow.
□ Document the prompt's purpose and what data it accesses.
□ Tag prompts that handle PII, financial data, or authentication decisions.
Good looks like: A spreadsheet or config file mapping each prompt to its function, data sensitivity level, and last review date.
2. Score each prompt for injection vulnerability
□ Run prompts through an AIWE-compatible scanner or manual injection testing.
□ Record severity scores (1-100 scale if using AIWE).
□ Flag any prompt scoring above 70 as critical for immediate remediation.
Good looks like: Each prompt has a documented vulnerability score. You can rank prompts by risk and triage accordingly.
3. Test for context leakage
□ Attempt to extract system instructions through user input variations.
□ Verify prompts don't echo back internal instructions or sensitive examples.
□ Confirm prompts reject requests to "ignore previous instructions."
Good looks like: Red team exercises where you try to trick the prompt into revealing its own instructions fail consistently.
4. Implement role separation in prompts
□ Separate user content from system instructions using clear delimiters.
□ Use structured formats (XML tags, JSON blocks) to distinguish instruction from data.
□ Never concatenate user input directly into instruction text.
Good looks like: Your prompt structure makes it mechanically difficult for user input to be interpreted as instructions.
5. Validate output constraints
□ Define explicit rules for what the model should never output.
□ Test that prompts reject requests to generate harmful, biased, or off-topic content.
□ Verify prompts refuse to perform actions outside their designated scope.
Good looks like: Attempted jailbreaks produce consistent refusals.
6. Version and track prompt changes
□ Store prompts in version control with meaningful commit messages.
□ Require security review for prompt modifications.
□ Maintain a changelog documenting what changed and why.
Good looks like: Git history for your prompts looks like your application code history.
7. Establish severity thresholds
□ Define what vulnerability scores require immediate action (recommend: 70+ is blocking).
□ Set review cadence based on prompt risk level (high-risk monthly, low-risk quarterly).
□ Document who approves exceptions to severity policies.
Good looks like: Clear escalation paths. A prompt scoring 85 triggers an automatic block on production deployment until remediated.
8. Integrate scanning into CI/CD
□ Add prompt security checks to your pre-merge pipeline.
□ Fail builds if new prompts lack security scores.
□ Alert on score regressions when prompts are modified.
Good looks like: Prompt security becomes as automatic as linting.
Common Mistakes
Treating prompts like configuration instead of code. Prompts are executable instructions. They need the same rigor as your application logic.
Assuming newer models are inherently more secure. Model capabilities improve, but prompt injection remains model-agnostic.
Skipping testing because "it's just text." According to Gartner research, 32% of organizations experienced an attack on AI applications leveraging the application prompt within the past year.
Hardening prompts in isolation from your application security program. Prompt security isn't separate from AppSec—it's an extension. Your secure development lifecycle should encompass prompts.
Believing one-time hardening is sufficient. Prompts evolve as features change. Your security posture degrades unless you maintain it actively.
Next Steps
Once you've completed this checklist:
- Schedule recurring reviews - Add prompt security audits to your quarterly security calendar.
- Build a prompt library - Create hardened, pre-approved prompt templates for common use cases.
- Train your team - Run a workshop on prompt injection techniques so developers understand what they're defending against.
- Measure and report - Track your average prompt vulnerability score over time; include it in security metrics reporting.
The gap between traditional AppSec tools and AI-specific vulnerabilities won't close itself. System Prompt Hardening represents a recognition that AI security requires new tooling and processes. Start with this checklist, refine it based on your findings, and make prompt security a standard gate in your release process.
Your AI features are only as secure as the prompts that constrain them.
