Stop sequences are defined strings that tell a language model to stop generating text when they appear in the output. They are used to bound responses, separate turns or prevent the model from continuing into unwanted formats, and they work by matching generated tokens against the configured sequence.
How stop sequences work
Stop sequences are output-boundary rules, not model instructions in the reasoning sense. The generation loop keeps producing tokens until the configured text matches one of the stop strings, then truncates the response at that boundary.
That makes them especially useful when a system needs to end cleanly at a delimiter, such as before a second turn, before a JSON footer, or before a templated section that should not be emitted. Because matching happens on generated text, the boundary can be exact or approximate depending on the tokenisation and the surrounding prompt design.
Why stop sequences matter in structured generation
In practice, stop sequences help control format drift. They reduce the chance that a model keeps speaking past the intended answer, leaks into the next message block, or appends extra commentary after a structured payload.
They are most effective when the output contract is explicit and the stop string is chosen to be unlikely to appear naturally inside normal content. If the stop string is too common, too short, or ambiguous, the model may halt too early and produce an incomplete answer.
They are also only one layer of output control. A stop sequence can bound the text, but it does not by itself validate schema correctness, stop a model from omitting required fields, or guarantee that the content before the boundary is safe or accurate.
Common failure modes
Stop sequences fail most often through poor boundary design. A delimiter that can appear in ordinary prose, code, or quoted text may terminate generation unexpectedly, while a delimiter that is too weak may be ignored by downstream parsing if the application continues to accept text after truncation.
They also interact with streaming and multi-part responses. If the application assembles output incrementally, a stop condition has to be enforced consistently at the service layer, otherwise later chunks can overwrite the intended boundary or reintroduce text that should have been cut off.
Another failure mode is treating stop sequences as a security control. They are a formatting mechanism, not an access control, sanitisation, or data-loss prevention feature, so they should not be relied on to prevent disclosure of sensitive prompts, secrets, or internal instructions.
Where they fit in LLM application design
Stop sequences belong in the generation contract between the application and the model. They work best when paired with clear prompt structure, explicit output schemas, and post-generation validation so the application can detect truncation, malformed payloads, or missing terminators.
For developers, the important design question is whether the stop boundary matches the real parsing boundary of the consumer. If the application expects machine-readable output, the stop string should align with the parser’s expectations, not with a human-readable convenience marker that can drift over time.
Used well, stop sequences are a simple and valuable control for shaping model output. Used loosely, they create a false sense of precision because the model may stop at the wrong place or continue in an unexpected format before the boundary is reached.
Risk and Threat Considerations
Stop sequences can create security and reliability issues when they are used as the only guardrail around model output. An attacker who can influence the prompt or the surrounding content may try to trigger an early stop, suppress required fields, or force the model to emit a partial response that breaks downstream logic.
Failure mechanism: The application trusts a textual boundary more than it trusts structured validation, so a crafted sequence can truncate the response, corrupt parsing, or bypass a format that downstream systems assume is complete.
Impact: The result can be malformed records, incomplete tool arguments, broken workflows, or hidden content loss that is hard to detect if the application does not verify the full output contract.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Stop sequences shape application output contracts and parsing boundaries. |
| Recommendation — Validate model output boundaries and reject partial responses before consuming them. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Stop-sequence handling depends on validating that generated output is complete and parseable. |
| AU-3 — Content of Audit Records | Structured generation controls affect what is captured, preserved, and traceable in logs and records. | |
| Recommendation — Validate model outputs before downstream processing to catch truncation and malformed content. Record generation boundaries and truncation events so output loss can be investigated. | ||
Practitioner Guidance
What to watch for: Choose stop strings that are unlikely to occur naturally in the content you expect the model to produce, and verify that the consumer can detect truncation rather than silently accepting partial output. If the output has security or business significance, treat stop sequences as a formatting aid and not as a control boundary.
Practitioner takeaway: A good stop sequence should make generation easier to parse, not make the system easier to fool.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org