Catch partial leaks
Real attacks often extract fragments, rules, or behavioral hints before full disclosure. ZeroLeaks classifies leaks from hints to complete extraction.
Prompt Extraction
Prompt leakage defense
Test whether your system prompt can be extracted
ZeroLeaks probes for direct, partial, and inferred disclosure of hidden instructions so teams can protect proprietary prompts and internal operating logic.
Direct and indirect extraction probes
Leak-depth scoring from hints to complete disclosure
Prompt hardening recommendations
Protect more than prompt text
The scan looks for exposed tool schemas, routing logic, retrieval rules, copyright policies, and operational constraints that attackers can use to escalate.
Harden prompts with evidence
Findings include the attack path and remediation guidance so teams can reduce leakage without breaking useful assistant behavior.
Leak depth, from hint to full disclosure
Extraction is not binary. Treating it as leaked or not leaked hides most of the risk, because partial disclosure is both more common and more useful to an attacker than teams expect. ZeroLeaks classifies every response against a five-level taxonomy.
L0 · Secure
No disclosure under sustained pressure. The model neither reveals instruction content nor confirms structural details about how it was configured.
L1 · Hint
Indirect confirmation of structure or intent. The model does not quote its instructions but its refusals and phrasing reveal that specific rules exist and roughly what they govern.
L2 · Partial
Fragments surface. Individual rules, tool names, data sources, or constraints appear in output, enough for an attacker to start targeting specific behavior.
L3 · Substantial
A coherent reconstruction of significant portions of the instructions, typically assembled across several turns rather than disclosed at once.
L4 · Full extraction
Verbatim or near-verbatim disclosure. At this point the attacker is reading your configuration rather than guessing at it.
Beyond the prompt text
Extraction probes also target tool and function schemas, retrieval configuration, routing logic, and guardrail rules. The refusal logic is often the most valuable thing to leak, because it tells an attacker exactly what to phrase around.
Why partial leaks matter more than they look
Teams tend to test extraction as a single question: can someone get the prompt out? Measured that way, most reasonably hardened assistants pass, and the result is a false sense of security.
The realistic attack is incremental. An attacker learns that a routing rule exists, then which categories it routes, then what triggers the escalation path. No single response constitutes a leak by a strict definition, but the accumulated picture is a working model of your system. Each fragment also makes the next probe more effective, because the attacker can now phrase requests in your system's own vocabulary.
This is why the leak taxonomy runs from L0 to L4 rather than stopping at a boolean. An L1 finding is not an emergency, but a system sitting at L2 across many probes is meaningfully more exposed than one holding at L0, and that difference is invisible if you only record whether full extraction succeeded.
What actually gets exposed
When a model is pushed correctly it reveals considerably more than a paragraph of instructions. Assessments routinely surface the verbatim rules, persona, and routing logic that define behavior, along with tool and function schemas including parameters and the conditions under which privileged calls fire.
Retrieval configuration is a frequent finding: data sources, index names, and chunking strategy, and occasionally raw retrieved content that the current user should not have been able to see. Guardrail logic surfaces often too, and it is arguably the highest-value target, since knowing the exact refusal rules tells an attacker precisely how to phrase around them.
Upstream context leaks as well. API endpoints, internal model names, service identifiers, and assumptions about data handling all tend to be present in the instruction layer, and none of them are meant to be user-visible. A prompt leak is rarely the end of an incident. It is the map that converts a blind attacker into an informed one.
Hardening without breaking the assistant
The instinct after a leak finding is to add more instruction: tell the model firmly not to reveal its prompt. This helps less than expected. The instruction is itself in context, the model remains optimized to be cooperative, and a sufficiently framed request often finds a path around a rule stated in the same channel it is meant to protect.
Structural mitigations hold better. Keep genuinely sensitive material out of model context entirely, since the model cannot disclose what it never received. Move secrets and credentials to the tool layer behind validation. Separate untrusted content from instructions with clear delimiting so retrieved text is less readily interpreted as a rule.
Layered defense matters because any single control eventually fails. The Shield SDK adds runtime detection for known extraction phrasings and n-gram matching that catches system prompt fragments appearing in output. That is a useful net for known patterns, not a substitute for reducing what is exposed in the first place, and ZeroLeaks findings include the specific structural change that would have prevented each leak.
FAQ
Is system prompt extraction still a real risk?
Yes. Even when full prompts are protected, partial disclosure can reveal internal logic, tool access, and guardrail rules that help attackers go deeper. Extraction is usually reconnaissance for a more targeted attack rather than the attack itself.
Does ZeroLeaks store my system prompt?
System prompts are processed transiently for scans. Reports store findings and metadata, not full prompt copies, and prompt content is not used to train models.
What is the leak taxonomy?
Five levels from L0 to L4. L0 is secure under sustained pressure, L1 is an indirect hint, L2 is partial fragments, L3 is substantial reconstruction, and L4 is verbatim or near-verbatim disclosure. Grading this way surfaces gradual leakage that a pass-fail test would record as a pass.
Can I just tell the model not to reveal its prompt?
It helps at the margin and is worth doing, but it is a weak control on its own. The instruction lives in the same context window as the attack and the model is optimized to be helpful. Structural mitigations, particularly keeping sensitive material out of context, hold up considerably better.
Does this test tool schemas as well as prompt text?
Yes. Tool and function schemas, retrieval configuration, routing logic, and guardrail rules are all extraction targets, and in practice they are frequently easier to extract than the prompt body.
How do I verify a fix actually worked?
Re-run the scan and compare. Scores and findings are comparable across runs, and running scans in CI means a prompt edit that reintroduces a previously fixed leak is caught at the pull request rather than after release.
Where does the probe library come from?
It is grounded in documented real-world prompt leaks and jailbreaks rather than synthetic test cases, drawing on the same body of research behind the widely referenced public collection of leaked system prompts maintained by the ZeroLeaks team.
Related AI security testing
Prompt Injection Testing for AI Systems
Test AI applications for prompt injection, instruction hijacking, tool abuse, and multi-turn attacks before they reach production.
AI Red Teaming for LLM Apps and AgentsAutomated AI red teaming for LLM applications, agents, system prompts, retrieval flows, and tool-calling workflows.
AI Agent Security TestingTest AI agents for prompt injection, unsafe tool calls, over-permissioned actions, secret exposure, and workflow boundary failures.
LLM Security Scanner for AI AppsRun automated LLM security scans for prompt injection, prompt leakage, tool abuse, model behavior regressions, and AI security reports.
