Guardrails, secrets and key management

Two sub-skills in one lesson: Guardrails and Safe Deployment (2.3%) and Identity, Secrets and Key Management (1.6%). They are small, they are dry, so let us be quick and exact.

Secrets: two hard rules

Never put a secret in a prompt. Never put a secret in a sandbox.

Both of those are stated plainly in the guidance and both get violated constantly, for sympathetic reasons.

Why not a prompt. Anything in the context is reachable by the model, and anything reachable by the model can come back out in the output. Extraction is not exotic: it is the entire point of the prompt-leak literature. Worse, prompt content flows into your logs, your traces, your evaluation datasets, and any transcript you keep for debugging. One credential in a system prompt becomes a credential in a hundred places you were not thinking about, some of them lower-trust than the original.

That fan-out is the part to hold on to. It is the same shape as a secret committed to a repository: the moment it is in there, remediation is not "delete the line", it is rotation, because you have lost track of every copy. A system prompt is a string that gets logged, sampled, replayed into evals and pasted into bug reports.

Why not a sandbox. This one is almost funny when you say it out loud. The sandbox exists to contain code you do not trust. Putting a credential inside it hands the credential to the thing you were containing. If sandboxed code needs to reach a paid API, the key lives outside and the sandboxed side calls a broker that holds it.

Guardrails: encouraged versus enforced

The distinction the exam is testing is simple and people blur it.

A prompt instruction is encouragement. "Refuse requests for medical advice" genuinely changes behaviour and genuinely helps. It is also inside the context, competing with everything else in the context, including anything an attacker put there.

A guardrail is enforcement. It sits outside the model, inspects the input or the output, and can block the action regardless of what the model decided. Classifying an input before it reaches the model, validating an output before it reaches the user, gating a tool call behind a policy check: those are boundaries because the model does not get a vote.

Use both. Just do not confuse which one is load-bearing. When a question offers you a well-written system-prompt rule and an external check, the external check is the guardrail.

Safe deployment is about what you can do afterwards

The instinct is to make deployment safe by reviewing harder before launch. That does not work here, and the reason is specific: a natural-language interface has an unenumerable input space. You cannot list the failure modes in advance, so completeness of pre-launch review is the wrong target.

What actually helps is posture after launch.

Ship narrow. Limited audience, limited scope, limited tool access. Expand once you have real traffic telling you what people actually do with it, which is never what you predicted.

Monitor behaviour, not errors. Your logs will be full of successful requests. The failures you care about here are 200s that did the wrong thing. An error rate dashboard is blind to the entire category.

Be able to turn it off. The single most useful property of an LLM deployment is a fast rollback, because your response time to a discovered failure is the thing you actually control.

// A
const systemPrompt = `You can call the pricing API directly.
Use this key in the Authorization header: ${process.env.PRICING_API_KEY}`

// B
const systemPrompt = `Call POST /broker/pricing to look up a price.
The broker attaches credentials. You never see them.`