What this prompt does
This prompt asks the model to act as a senior AI safety engineer and specify a guardrail system tightly enough to implement, returning concrete checks and code stubs rather than principles. You provide the [stack], the allowed topic [scope], the data [sensitivity] level, and the [log_sink], and it returns a layered architecture with a code stub for each layer: input moderation, scope enforcement, output moderation, rate limits, logging, and a kill-switch.
The structure works because it layers checks around the model instead of trusting the system prompt alone. Input moderation catches prompt injection, PII, and toxicity before the model sees text; scope enforcement keeps replies inside [scope] and deflects the rest; output moderation catches hallucination, unsafe content, and leaked instructions. Rate limits are sized to [sensitivity], logs go to [log_sink], and a global kill-switch can disable generation instantly. Because the prompt asks for concrete checks and a code stub per layer rather than principles, each defense is a starting implementation you can drop into your [stack] and harden, not an abstract guideline.
When to use it
- You're launching a public-facing bot where injection attempts arrive within hours.
- You need input and output checks around the model, not just a trusting system prompt.
- You must keep replies inside an allowed
[scope]and deflect everything else. - You handle sensitive data and need rate limits sized to that risk.
- You need structured logs to
[log_sink]for human review and audits. - You want a global kill-switch to stop generation instantly across the fleet.
- You want defense in depth so one bypassed layer doesn't expose the whole bot.
Example output
Expect a layered architecture description followed by a code stub per layer: input moderation, topical scope enforcement for [scope], output moderation, per-session and per-IP rate limits sized to [sensitivity], structured logging to [log_sink], and the global kill-switch. Each layer is concrete enough to wire into your [stack], so you're getting an implementable defense-in-depth design rather than a list of safety principles.
Pro tips
- Build the kill-switch (step 6) first — being able to disable generation instantly is what lets you launch without holding your breath.
- Define
[scope]narrowly and concretely; a fuzzy scope makes the enforcement layer leak off-topic and unsafe replies. - Size rate limits to
[sensitivity]honestly — a bot touching customer PII deserves tighter per-IP limits than a public FAQ bot. - Layer input and output checks; trusting the system prompt alone is exactly what the first injection attempt defeats.
- Point
[log_sink]at something with real retention (e.g. CloudWatch, 90 days) so audits and incident review have data to work from. - Ask for code stubs, not principles, so each layer is a starting implementation you can flesh out.
