A system prompt cannot be made unbreakable, but it can be designed so that breaking it, through leaking or manipulation, causes as little damage as possible. That is the right goal for secure system prompt design: not perfect resistance, which is not achievable, but a prompt whose exposure or manipulation does not translate into a serious consequence.
Never put secrets in the prompt
Credentials, API keys, internal URLs meant to stay private, and any other genuine secret should never be pasted into a system prompt template. This happens more often than it should, usually during rapid prototyping, where a developer includes a real credential to get a demo working and forgets to remove it before the prompt template moves toward production. Secrets belong in a secure configuration store the application code reads directly and uses to authenticate its own calls, never in text the model itself processes, since a leaked prompt is always a possibility worth designing around.
Keep enforceable rules out of the prompt where possible
Rules with a real consequence, transaction limits, data access boundaries, anything a compliance requirement depends on, should be enforced in code independent of the model, not solely described in the system prompt. Where a rule must be referenced in the prompt for the model to reason about it correctly, treat that reference as informational context, not as the actual enforcement mechanism, and confirm there is a code-level check that holds even if the prompt-level description is ignored or overridden.
Separate instructions from data with clear, consistent structure
Use explicit, consistent delimiters to separate your own instructions from content the model should treat as data: user input, retrieved documents, tool responses. Label these sections explicitly so both the model and any future engineer reading the prompt template can immediately see which parts are instructions and which are content to be processed rather than obeyed. Consistency across your prompt templates matters here, since a structure that varies from one integration to the next is harder to reason about and harder to test systematically.
Avoid embedding detailed reasoning about sensitive rules
Where the prompt needs to reference a business rule, prefer stating the outcome the model should produce over explaining in detail why the rule exists or what specific conditions trigger exceptions. A prompt that leaks minimal detail about the reasoning behind a rule gives an attacker less useful information for figuring out how to work around it, compared to a prompt that spells out every threshold and edge case explicitly.
Design for eventual partial exposure
Assume that a sufficiently motivated attacker may eventually see some portion of your system prompt, through leaking, reformatting requests, or some future technique not yet known. Design the prompt's content with this assumption in mind: nothing in it should cause meaningful damage if it becomes visible, because the actual protection for sensitive logic lives in code-level enforcement, not in the prompt staying hidden.
Version and review prompt changes like code
System prompts that encode meaningful business logic deserve the same review discipline as code changes: version control, a review process before changes reach production, and a way to trace which version of the prompt was active for a given incident during an investigation. Treating prompt changes as casual text edits, made without review because "it's just wording," is how sensitive content or a broken safety instruction ends up in production without anyone catching it first.
Test prompt structure against known manipulation techniques
Periodically test whether your prompt structure still resists a current set of known injection and leaking techniques, since model updates and newly published attack techniques can both change how well a given structure holds up over time. Treat this as an ongoing practice rather than a one-time validation done when the prompt was first written.
Where TELEON fits
TELEON's privacy vault tokenization reduces what sensitive values, if any, need to appear in a prompt at all, substituting a reference the application can resolve separately. Its policy enforcement at the tool-call boundary, applied through the gateway or supported middleware, provides the code-level backstop for rules that should not depend solely on the prompt holding.
Structuring the prompt itself, deciding what content it should and should not contain, and reviewing changes to it, remains work the team building the application has to own directly.
A short checklist
- Never place secrets or credentials in a system prompt.
- Move enforceable rules with real consequences into code, not just the
prompt.
- Use clear, consistent delimiters separating instructions from data.
- Avoid embedding detailed reasoning about sensitive rules in the prompt
text.
- Design assuming eventual partial exposure of the prompt is possible.
- Version and review prompt changes with the same rigor as code changes.
- Re-test prompt structure against current manipulation techniques
periodically.
Secure system prompt design accepts that the prompt itself cannot be a perfect boundary and focuses instead on making sure nothing catastrophic depends on it being one.