Bonus: The Agent Security Checklist

Why this matters

A friend of Pip's runs a bakery two streets over. Next week she launches a bot that takes cake orders, changes delivery dates, and refunds customers who are unhappy. She has heard about Sprout's bad month and asks Dev for "the list."

Dev does not send the course. He sends two things. The first is fifteen questions, each with a yes or no answer, that Sprout could not have passed in its first version and passes now. The second is ten things to type at the bot before launch, with a note on what a safe reply looks like for each.

That is this lesson. It is the whole course folded into a file you can run in an afternoon, against any agent, including one you did not build.

1. The fifteen questions

A security checklist is a short list of yes-or-no questions you answer about an agent before it ships. It is not a threat model and it is not a red-team report. It is the thing you run to find out whether those exist and whether they did their job. Sprout's copy lives at docs/security-checklist.md, next to the threat model and the governance record, and it changes when the agent changes.

# Sprout security checklist (answer yes or no, with a link)

## Map
1. Is there a written threat model (docs/threat-model.md) that names assets, actors, and every entry point?
2. Is every tool assigned a risk tier (T0, T1, T2) with one sentence of reason?

## Authorization in code
3. Is every T2 tool gated in code, so the model can only request it?
4. Is every tool call scoped to the calling user (no lookup of another customer's object)?
5. Are tool arguments validated against the real order, policy, and window?
6. Is there a per-role allowlist, and does a customer session hold only customer tools?

## Guards and memory
7. Is there an input guard (size, markup, hidden text, instruction-like lines in tool results)?
8. Is there an output guard (secrets, other customers' data, canary tokens)?
9. Does every memory record carry provenance, and is customer text never rendered as policy?

## Evidence
10. Does an adversarial suite (evals/adversarial/*.yaml) run on every pull request?
11. Has a red-team run against staging in the last 90 days, with findings turned into tests?

## People and switches
12. Does the approval queue deny on timeout, and does a decision need a person's id?
13. Has the kill switch (SPROUT_DISABLE_T2=true) been pulled on purpose in the last quarter?
14. Are the logs enough to reconstruct one incident: prompt version, calls, guard decisions, approvals?
15. Is docs/governance-record.md current as of the last tool or prompt change?

Each answer needs a link. "Yes" without a file, a log, or a test run is a "no" that has not been checked yet.

The questions are grouped by the verbs of the course. Questions 1 and 2 are Map. Questions 3 to 9 are the defenses that hold when the model is fooled. Questions 10 and 11 are the Attack work, turned into evidence. Questions 12 to 15 are the people, the switches, and the record.

Read the order of the questions, too. If you can only fix three things before launch, fix 3, 4, and 5. Those are the checks that hold when everything else fails: the model can be fooled, and the tool guard does not care.

2. Ten attacks to try

The second list is what to type at the agent. Every attack below targets Sprout on staging, logged in as a test user, with the seeded orders from the course. Never run these against an agent you do not own, and never against production. The point of each row is the safe reply: you are not checking whether the model resists, you are checking what happens when it does not.

The first six are the course's recurring attacks. The last four are the ones a red-team tool such as promptfoo tends to find first, and the ones a friend's bot most often fails.

3. Two explanations

You will be asked to explain this work twice, to two people who want different things. Have both paragraphs ready.

Notice what both paragraphs skip. Neither claims the agent cannot be fooled. Neither names a detector. Both name what holds, who decides, and what proves it, which are the three questions of the Defend verb.

4. What to learn next

This course took one lesson from Building and Evaluating AI Agents and gave it a week. Three other places on the platform pick up where it stops.

• Building and Evaluating AI Agents covers the evaluation suite and CI that questions 10 and 11 depend on: how a test case is shaped, how a judge grades a reply, how the suite runs on every pull request, and how to measure whether a prompt rule such as "data is not instructions" moves the pass rate. Go there when you need the adversarial suite to be one part of a larger regression suite.
• Spec-Driven Development for Dummies covers gates and evidence: how a change earns the right to ship, and how the evidence pack you assembled in L8 fits into a review that a person signs. Go there when the governance record needs to live inside a delivery process instead of next to it.
• Working with Coding Agents covers hooks and permissions on the development side. The agent that writes Sprout's code reads untrusted text, too: issues, dependencies, documentation. The same design rule applies, and that course shows where the guards go in a development workflow.

The bakery bot ships next week. Dev's two lists will not make it safe. They will tell its owner which of the fifteen questions she cannot answer yet, and which of the ten attacks her bot fails today, before a stranger finds out first. That is the smallest useful thing this course can hand to someone who has thirty minutes and an agent about to go live.

Summary

• A security checklist is fifteen yes-or-no questions with a link behind every yes; it runs at every release and does not replace the threat model.
• If you can only fix three things, gate T2 in code, scope every call to the user, and validate arguments against the real order.
• Try ten attacks against your own agent on staging with a test user, and judge each by what happens after the model is fooled, not by whether it was.
• Explain the work twice: to the owner as what can be lost and what holds, to the skeptic as why the prompt lowers attempts and the code decides outcomes.
• Go next to the evaluation suite and CI, to gates and evidence, and to hooks and permissions for the agents that write your code.