Yesterday somebody dropped a skill file on r/PromptEngineering that kills “just test it with ignore previous instructions” as a security strategy. It’s called prompt-injection-guard, and it does the one thing most injection advice skips: tells you which layer caught the attack and what’s still exposed.
What’s new: load the skill and ask Claude something like “is this log payload safe to forward to our LLM,” and instead of a vague thumbs up, Claude runs a fixed triage. It maps the boundary between your system prompt and user input (raw string concatenation is the riskiest setup, role-separated messages are safer), fingerprints the attack against five categories, scores severity by blast radius, then writes the actual defense code instead of just handing you a verdict.
The twist: severity isn’t about the wording, it’s about the plumbing. The exact same “ignore previous instructions” payload is MEDIUM in a read-only summarizer and CRITICAL the second that agent can write to a database or fire off a tool call. And two prompts that read almost the same, “ignore previous instructions” versus “pretend you’re a security auditor,” get pushed down completely different response paths, because one targets the instruction set and the other targets the model’s trust in who it thinks it’s talking to. That’s the part worth stealing even if you never touch this exact skill: stop grading injection attempts on vibes, grade them on access surface.
Step-by-step mini-workflow:
- 🗺️ Map your boundary type first. Concatenation, template interpolation, or role-separated messages, know which one you’re running before you audit anything.
- 🏷️ Classify the input against five categories: direct override, output manipulation, context poisoning, indirect injection through fetched data, social engineering.
- ⚖️ Score severity as access surface times override proximity times detection confidence, not “does this look sketchy.”
- 🛡️ Write the defense per layer: sanitize input, wrap user text in tags the system prompt is told to ignore, filter output for leaked system-prompt phrases.
- Close with a report: input sample, classification, severity, what caught it, false-positive check. That’s the difference between “we think it’s secure” and “here’s what we tested.”
Pro tip: the sneaky failure mode isn’t the input box, it’s everything downstream of it. Fetched web pages, tool outputs, database rows, anything the model reads counts as user input for this purpose, even if no human ever typed it. Audit those the same way or the whole exercise is theater with extra steps.
One commenter on the thread pushed back hard: skills won’t stop injection, only mechanical guardrails will. Fair point, and worth sitting with. This skill doesn’t replace boundary enforcement in your code, it forces you to actually build that boundary instead of stopping at “we validate inputs” and calling it a day.
Grab the skill, run it against your riskiest endpoint this week, and see what category it flags first. 🎯
Frequently Asked Questions
Q: Doesn’t prompt injection happen anyway, regardless of detection?
Yes, mechanical isolation is your real safeguard. If injected code can’t escape a sandbox or write outside allowed directories, the attack fails. But detection matters too: it gives you audit trails, early warnings, and the ability to respond to attempts in real time. Think of it this way: isolation stops the harm, detection alerts you it’s happening. You need both.
Q: How does this skill work alongside role-based API messages and sandboxing?
Role-based message separation (system vs. user roles in the API) is a solid baseline, and sandboxing confines the blast radius. This skill adds a middle layer: it scans your actual prompt design for injection signatures and architectural weak points that API design alone might miss. It’s another line of defense, not a replacement for the others.
Q: Should I use this skill instead of sandboxing my generated code?
No, these aren’t either/or. Sandboxing is mandatory. Use this skill to detect injection attempts early and log them for incident response, then add strict architectural limits (confined directories, no external writes, allowlisted operations). The combination gives you both visibility and safety.
Prompt Injection Guard skill.md
by u/Parking-Kangaroo-63 in PromptEngineering