quiz · 4 min

Guardrails & Safety Check

Why does lesson 34 recommend allow-listing tools rather than deny-listing them?
Deny-listing is equally robust - you just enumerate every dangerous formAnything not explicitly permitted is blocked, so a new tool cannot accidentally become available without an explicit decisionThe policy should self-restrict to only safe tools, making a list unnecessaryOutput validation alone is sufficient if the policy is well-prompted
According to lesson 34, where in the pipeline does input validation belong?
Before the policy sees the data, normalising all inputs at the boundaryAfter the policy runs, so the guardrail sees the model's full contextOnly on user messages -- retrieved content from a document store is trustedInside the policy function itself, which is best placed to detect anomalies
In the guardrail layer built in lesson 35, what happens when an action is blocked?
The guardrail raises an exception to halt the agent loop immediatelyThe tool runs in a sandbox and its output is silently discardedThe policy is re-prompted with a stronger system message and retriesA defined result such as ('blocked', reason) is returned; the loop handles it without an exception
Lesson 36 identifies three main prompt-injection vectors. Which set is correct?
System prompt, model weights, and output tokensOnly user messages -- tool results are structured objects and therefore safeRetrieved content, tool return values, and direct user inputEnvironment variables, API keys, and log files
For high-impact actions such as deleting data or spending money, what does lesson 36 require?
Authorisation outside the model -- a human-in-the-loop step or a cryptographic approval token -- so the model alone cannot trigger the actionThe policy should self-audit by reviewing its previous output before actingProvide the model with a read-only copy of the tool to inspect before decidingUse a deny-list of high-impact tool names in the guardrail layer