System Prompt Leak Prevention

Design prompts as visible guidance

A system prompt can define tone, role, constraints, and task framing. It should not contain credentials, API keys, hidden allow-lists, private customer data, unreleased business logic, or the only copy of a security policy. Treat it like configuration that might be inspected, logged, or quoted.

This posture changes the question from "how do we make the prompt impossible to reveal?" to "what happens if a user sees it?" A well-designed system has a boring answer: they learn how the assistant is supposed to behave, but they do not receive secrets or new authority.

Remove high-impact material

• Secrets and tokens: keep them in secret management and server-side code.
• Hidden policy logic: enforce user permissions, tool access, and content policy outside the model.
• Sensitive architecture details: describe behavior without exposing internal systems that do not need to be prompt-visible.
• Bypass instructions: avoid writing a map of what the assistant should never disclose if ordinary code can enforce the rule.

Harden what remains

Good prompt guidance names trust boundaries. Tell the assistant which content is user intent, which content is untrusted data, and which outputs require application validation. Give it a safe fallback when data is missing. Require structured output where the application expects structure. Require confirmation before high-impact actions, then make the product UI enforce that confirmation.

Use the system prompt linter to catch common gaps, then use the risk checklist to review the application controls around the prompt. A prompt can ask for safe behavior; the application has to make unsafe behavior hard to execute.

System prompt leak FAQ