Put it to workMiddleLesson 604 min read

The pre-flight checklist

Everything in this guide, compressed into things you can tick off before an agent touches anything real. Print it. Use it.

🧪 Lab · 30 min📝 Lesson test
Lesson in motion

In 60 seconds

The pre-flight checklist

Everything in this guide, compressed into things you can tick off before an agent touches anything real. Print it. Use it.

1/4
In simple words
Pilots read a list out loud before every flight, even after a thousand flights. Not because they forgot how to fly — because lists catch the thing you were sure about.

1 · Know what you are building

  • Written in one sentence: what this agent is for.
  • Written down: the three worst things it could plausibly do.
  • A named human owner. Not a team — a person.
  • An autonomy level chosen deliberately, from the table in Module 13.

2 · Cut the trifecta

  • Listed: what private data it can reach.
  • Listed: every path untrusted content can take to reach it.
  • Listed: every way information can leave — including image loading and search queries.
  • At least one leg deliberately cut, and written down which one and how.

3 · Least privilege

  • Every tool has a written reason to exist.
  • Every read is scoped to the narrowest set of rows or files that works.
  • Every write tool is on a specific list, and each one has an approval rule.
  • It has its own identity and its own short-lived credentials.
  • The end user's identity travels with every action, attached by your code.
  • No secret ever appears in the context window.

4 · Contain it

  • Runs in a sandbox with no host filesystem access.
  • Network egress is deny-by-default with an allow-list, DNS included.
  • Hard caps: steps per run, spend per run, wall-clock time.
  • The environment is ephemeral — destroyed and rebuilt each run.

5 · Keep a human where it counts

  • Every irreversible action requires approval.
  • The approval dialog shows real values, built from tool arguments by your code.
  • The dialog says whether it can be undone, and flags what is unusual.
  • Approval volume is low enough that people still read them.

6 · Watch it

  • Every tool call logged with arguments and the source that influenced it.
  • One correlation ID per run, across every agent involved.
  • Alerts: first use of a tool, volume spikes, unknown destinations, secret-shaped output, refused approvals.
  • You can replay any past run step by step.
  • Logs are redacted, access-controlled and have a retention policy.

7 · Attack it

  • The Module 23 grid has been run against a staging copy.
  • Every successful attack is now an automated regression test.
  • Attack success rate is tracked over time and reviewed.
  • Re-run scheduled for every capability change.

8 · Plan for the bad day

  • A global stop that works in one action, and has been tested this quarter.
  • Per-agent and per-tool disable, without a deploy.
  • Token revocation that takes effect everywhere immediately.
  • A written incident runbook, and someone who has actually read it.
  • Circuit breakers on spend, volume and error rate.

The five-minute version

No time for the full list? These five catch most of it:
  1. 1

    Cut one leg of the trifecta

    Private data, untrusted content, or a way out. Remove one and most attacks have nowhere to go.
  2. 2

    Delete a tool

    Look at the tool list and remove the most dangerous one it does not truly need. This is the only defence that cannot be argued around.
  3. 3

    Put a human on the irreversible

    With real values in the dialog, not "allow action?".
  4. 4

    Turn on logging with sources

    Especially what the agent read just before each action.
  5. 5

    Test the stop button

    Today. Not in theory.
Real example
The whole guide in one line: assume the model will be fooled, and design so that a fooled model cannot do anything you could not live with.

Watch and read more

Securing AI agents in productionYouTube searchOWASP Top 10 for LLM Applicationsgenai.owasp.org · reading

Lab

The pre-flight checklist applied to something you actually run.

~30 min

The problem

Run all eight sections of Module 60's checklist against a real system. For every unticked box: owner, date, or a written accepted-risk. Then do the five-minute version today.

You are done when

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1You have one afternoon and a production agent with 12 tools, DB write access and no approval gates. Order your work and justify the first item.Reveal
First: turn on logging with the influencing source, because you cannot assess or prioritise anything else without knowing what it actually does — and it is the only item that gets more valuable the longer it runs. Then remove the most dangerous tool that the logs show unused. Then an approval gate on the single most irreversible remaining action. Then egress allow-listing. Then test the stop button. Logging first is counterintuitive because it fixes nothing, and it is right because every other decision that afternoon is a guess without it.

Please sign in to continue.

Questions people ask

This is a lot for a small team. Where do I start?

The five-minute version, honestly. Cut a trifecta leg, remove one tool, add one approval gate, turn on logging, test the stop. That is an afternoon and it removes the majority of realistic damage.

We already shipped without any of this. Now what?

Logging first — you cannot assess exposure without it. Run a week, see what the agent actually uses, then remove every permission that went untouched. That step alone is usually dramatic, and it is low risk.

How do I convince my manager to spend time on this?

Skip the abstractions. Write the three worst plausible outcomes for your agent in concrete terms — "it can email any customer", "it can delete production rows" — and show how many of the eight sections above are currently blank. Specifics move budgets.

Does this apply to agents I buy rather than build?

Every word. Ask the vendor: what permissions does it need, what can it reach, how do we stop it, what do the logs contain, and has it been red-teamed? A vendor without good answers is telling you something useful.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Sign in with your phone number to take the test and save your progress