Common mistakes with delimiter defence include assuming separators alone can stop prompt injection, using weak or predictable markers, and failing to validate content outside the delimiter. Attackers can still bury instructions in surrounding text or encoded payloads. Use delimiters as one signal only, and combine them with content filtering, structured parsing and privilege limits.
Why delimiter defence fails in practice
delimiter defence is easy to overestimate because separators help humans and models distinguish regions of text, but they do not create a trust boundary. Prompt injection can still work when instructions are wrapped in markup, hidden in adjacent prose, split across chunks, or encoded in a way the parser later normalises. The real mistake is treating the delimiter as a security control instead of a parsing aid.
A second failure mode is using the wrong threat model. Delimiters can reduce accidental instruction bleed, but they do not reliably defeat malicious content that is deliberately crafted to look like data. That is why the core mitigation is layered, not symbolic: validate structure, constrain interpretation, and assume hostile content may appear both inside and outside the marked region.
Where weak delimiter schemes break down
Weak markers are often predictable, reusable, or too easy to spoof. If the separator is a common token such as triple backticks, XML-like tags, or a simple phrase, attackers can mimic the same pattern or place competing instructions near it. When the system does not verify that the delimiter actually encloses the intended payload, the boundary becomes a suggestion rather than a rule.
Problems also appear when teams rely on delimiter placement alone and skip content inspection. For example, a prompt may be cleanly segmented yet still contain instructions in metadata, comments, surrounding context, image captions, or encoded fragments. The Prompt Injection Guide is useful here because delimiter defence is only one layer in a broader prompt-injection defence strategy, not a standalone answer.
Another common gap is scope creep. Teams often assume that if the model respects a delimiter in one workflow, it will do so everywhere. In reality, delimiter handling differs across parsers, toolchains, and downstream components. If one stage strips whitespace, decodes entities, or rewrites formatting, the original boundary can be weakened before the model ever sees the text.
How to make delimiter defence more reliable
Use delimiters to support structured parsing, not to replace it. The strongest pattern is to pair clear separators with schema validation, explicit field typing, and strict handling of anything outside the expected structure. That way, the system does not merely notice boundaries, it enforces them.
Privilege limits matter just as much. Even a well-delimited prompt should not be allowed to trigger high-impact actions without additional checks. If the model or downstream tool can read, send, purchase, delete, or disclose, then delimiter defence needs to sit inside an access-control design, not outside it. The NIST Zero Trust Architecture guidance and MITRE D3FEND both reinforce the broader point that trust should be verified through layered controls, not inferred from formatting alone.
When the content may influence tools or agents, the safer design is to separate parsing from execution. One component should classify and normalise the input, another should enforce policy, and only a tightly scoped executor should act on approved output. That reduces the chance that a clever payload can turn a delimiter into a bypass.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Delimiter parsing and boundary enforcement are configuration-sensitive input controls. |
| Recommendation — Harden parsing rules so delimiters cannot be bypassed by malformed or rewritten input. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Delimiter defence depends on validating and rejecting hostile or malformed input content. |
| AC-6 — Least Privilege | Delimiter failures matter most when downstream actions exceed necessary privilege. | |
| Recommendation — Validate input structure before processing any content around the delimiter. Restrict tool and action privileges so injected text cannot trigger broad impact. | ||
| MITRE ATT&CK | T1055 — Process Injection | Prompt injection is an instruction-abuse pattern, and adversarial techniques focus on manipulating trusted execution paths. |
| Recommendation — Map injection-style abuse to trusted execution flows and monitor for instruction hijacking. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Delimiter defence relies on protecting and handling content safely across processing stages. |
| Recommendation — Protect content handling paths so untrusted text cannot alter processing outcomes. | ||
Practitioner Guidance
What to verify: Confirm that your delimiter is enforced by parsing logic, not just by prompt instructions. If the boundary can be bypassed by encoding, whitespace changes, or downstream normalisation, it is not a reliable control.
Common mistake: Treating delimiter defence as a prompt-engineering trick rather than a control layered with validation and privilege constraints. If the surrounding workflow can still execute high-risk actions, the separator has not solved the real problem.
What good looks like: The system rejects malformed structure, ignores content outside the approved schema, and limits any action the model can trigger until policy checks pass. Delimiters then become one signal among several, not the final gate.
Practitioner takeaway: Delimiters reduce ambiguity, but they do not establish trust, so the practical question is whether your pipeline can still resist hostile content after the separator is bypassed or imitated.
Related resources from NHI Mgmt Group
- What are the most common mistakes organisations make when launching green banking or telecom initiatives?
- What are the most common mistakes organizations make in a NIST SP 800-171 self-assessment?
- What are the most common mistakes teams make when implementing two-factor authentication for accounts?
- What are the most common mistakes teams make when hardening access to a cloud warehouse?