Module 06
The Executive Playbook
Everything so far, assembled into one practical posture: no single wall, layered defenses, and an owner who's accountable when it matters.
By the end of this module you'll be able to
- Explain why "defense in depth," not one perfect fix, is the only honest way to secure AI.
- Name the layers you should expect in any serious AI deployment, and where each one fits.
- Put a name to who owns AI risk, and what happens the day something goes wrong.
Explainer · the mindset that ties it together
No single wall, only layers
By now the pattern is unmistakable. The AI can't tell instructions from data (Module 01). The attacks are made of words and top every risk list (Module 02). You can't filter them out reliably (Module 03). And the moment AI can act, the stakes turn financial and legal (Module 04). There is no one fix that makes all of this go away. Anyone who sells you that fix is selling the risk.
So serious teams stop looking for a wall and start building layers, the security discipline called defense in depth. Each layer assumes the one before it will eventually fail, and exists to contain the damage when it does. A filter might catch the lazy attacks; if one slips through, least-privilege limits what it can reach; if it reaches something, a human gate stops the irreversible action; if something still happens, monitoring catches it and governance owns the response. No layer is perfect. The stack is what keeps you safe.
This isn't pessimism; it's the standard every other part of your business already meets. Why insist on it here? Because of a hard truth about security math:
"In application security, 99% is a failing grade."
Simon Willison, who coined the term "prompt injection"A spam filter that misses 1% is a minor annoyance. A security control that fails 1% of the time is a disaster, because an attacker simply tries a hundred times. That's why you can never rest the whole defense on a single probabilistic check: a filter, a clever prompt rule, "the model is well-behaved." Each is a useful layer and a terrible foundation. You design so that being wrong 1% of the time is survivable, not catastrophic.
Explainer · the playbook itself
The layers to expect, and demand
Here is the whole guide as a single picture. Read it from the threat at the top down to what you're protecting at the bottom. Each band is a layer you should expect in any serious deployment, and each maps to one of the questions you've been carrying since the introduction.
Defense in depth: every layer assumes the one above it can fail. The threat has to beat all of them; you only need most of them to hold.
Notice what this does to the vendor conversation. Instead of asking the unanswerable "is it safe?", you can ask "show me your layers." A serious answer walks down this stack. A weak answer names one band, usually the filter, and stops. The number of layers a vendor can describe is a fast, reliable read on how seriously they've thought about your risk. Not every deployment needs every layer at full depth (a read-only internal helper isn't a payments agent) but any credible vendor should be able to speak to access control, change management, and what happens after an incident, not just content filtering.
One caution about the stack: layers help only when they fail independently. Two content filters running the same underlying model are barely two layers: the prompt that fools one tends to fool the other, so they fail together. The controls worth adding are the ones that fail in a different way from what you already have: a human approval, network segmentation, a separate enforcement service. When you count a vendor's layers, or your own, count the diverse ones, not repeats of the same idea.
Explainer · the gold-standard layer
Separation of trust: never let the dangerous input drive the powerful hand
One layer deserves a closer look, because it's the most direct answer to the lethal trifecta. The idea, sometimes called the dual-LLM or "separation of trust" pattern, is to split the work between two AIs that don't trust each other.
One AI is powerful but sheltered: it can use tools and touch private data, but it never reads raw untrusted content directly. The other is exposed but powerless: it handles the messy outside content, the emails, documents, web pages, but has no tools and no access to anything sensitive. The two communicate only through a narrow, controlled channel. A poisoned document can hijack the powerless reader all it likes; that reader has nothing worth stealing and no buttons to press.
The analogy. Think of bomb disposal. One specialist examines the suspicious package from behind shielding and relays only careful, structured observations. The operator with the tools acts on those observations but never touches the package directly. Neither person alone can be both tricked and dangerous. That separation is the whole point.
You don't need to build this yourself. You need to recognize it as the strongest structural defense available, and to ask any vendor a pointed version of it: "When your AI reads untrusted content, what stops that content from directly driving the parts that have access and can take action?" A thoughtful answer describes some form of separation. A blank stare tells you the trifecta is wide open.
Two cautions before you treat this as a finish line. The separation only holds if the boundary between the two AIs is carefully designed: if the powerful, sheltered side acts on a summary that still carries the attacker's instructions, the injection simply rides across the channel. That's why the interface between them matters as much as the split itself: structured, validated, tightly defined messages rather than free-flowing text. And in real systems untrusted content can sneak into privileged places through side doors, logs, debug output, a monitoring dashboard someone reads. Making sure the powerful side truly never touches raw outside data takes deliberate threat modeling, not just two boxes on a diagram.
Your P&L
Someone has to own the day it goes wrong
Layers are technical; ownership is not. The most common failure in AI risk isn't a missing filter; it's that no one is accountable for the system as a whole. The model is the vendor's, the data is IT's, the use case is a business unit's, and when something breaks, everyone points sideways. The fix costs nothing but a decision: name a person who owns AI risk, give them the authority to say "not yet," and make sure there's a written plan for the day an AI sends the wrong thing or invents the wrong fact. In a larger organization that "person" can be a role or a small governance council rather than one individual; what matters is that they hold real authority over deployment decisions and a mandate to coordinate security, evaluation, and incident response.
This is also where the cheapest-insurance argument peaks. Governance, a clear policy on what data and actions AI may touch, a vendor contract that includes the right to see evaluations, and a simple incident playbook, is a few meetings. The alternative is improvising those answers in public, after the incident, with a customer or a regulator watching. Match the weight to the risk: a small, low-stakes deployment can run on a one-page policy and a checklist, while a regulated or high-impact use earns formal review, audits, and board-level visibility. Build the boring layer now.
Evidence file
The people building these systems say there's no silver bullet
When the vendors themselves concede the point
You don't have to take a consultant's word that prompt injection can't be fully solved. In late 2025, as AI assistants gained the ability to browse and act on the open web, OpenAI stated plainly that prompt injection is unlikely to ever be completely eliminated, comparing it to scams and social engineering, which we manage but never "solve." Around the same time, the UK's national cyber agency warned that these attacks against generative AI may never be fully mitigated. Permanent, though, is not the same as unmanageable: better architectures, tooling, and monitoring can drive the risk down a great deal. The message is realism about a residual that never quite reaches zero, not fatalism.
This is the strongest possible support for everything in this module. When the companies with the most to gain from claiming "we fixed it" instead tell you the problem is permanent, the conclusion is clear: stop waiting for the fix, and build for containment. Reducing and managing the risk, with layers, separation, human gates, and governance, isn't the cautious option. It's the only honest one.
Sources: OpenAI public statements on prompt injection and the ChatGPT "agent mode" browser, December 2025 (reported by Fortune and others); UK National Cyber Security Centre guidance on prompt injection, 2025. The "99% is a failing grade" standard: Simon Willison.
Labs · run these yourself
Build your stack, name your owner
These three labs turn the playbook into something you can actually hand to a team. Do them on a real or planned AI deployment.
Build your defense stack
~8 minutes · a real or planned AI tool
Walk down the layers from the diagram. For each, write "have it," "partial," or "missing":
- Limit what it can see: does it reach only the data its job needs?
- Limit what it can do: read-only where possible; no unused powers?
- Isolate untrusted input: is outside content kept away from privileged action?
- Human-in-the-loop: is a person required for the irreversible actions?
- Filters / guardrails: present, but treated as a speed bump, not the wall?
- Monitoring & logging: can you see later what it saw and did?
- Continuous measurement: are quality and groundedness tracked over time?
- Governance: named owner, data/action policy, incident plan?
Find your single point of failure
~3 minutes · no tools needed
List everything your AI plan is relying on alone to keep it safe: a vendor's filter, a system prompt that says "never do X," the belief that "our model is well-behaved." For each one, apply the 99% standard: assume it fails once in a hundred times. What's the next layer that catches it? If your honest answer for any item is "nothing," you've just found the most important thing to fix before launch, and it's almost always cheaper to add the layer than to survive the failure.
Name the owner
~5 minutes · keep this one
Answer these five out loud with your team. Blank answers are the deliverable; they're your to-do list:
- Who owns AI risk here, by name, with authority to pause a launch?
- What is our written policy on what data and actions AI may touch?
- What happens in the first hour after an AI does something wrong?
- What do our vendor contracts say about evaluations and liability?
- Which decisions or outputs always get a human's eyes before they go out?
Your four questions, completed
The framework you've carried since the introduction is now a working system. What it can see, whose instructions reach it, what it can do, where a human approves, each maps to a layer in the stack, wrapped in measurement and governance. Those four axes are the backbone, not the whole of the job (evaluation quality, logging, and compliance still sit across the top of them) but they're the stable structure every other concern hangs from. You can walk into any AI conversation and run it. Module 07 makes it concrete one last time: a short self-assessment that scores a real deployment and points you to your safe next step.
Plain-language glossary
The terms from this module
- Defense in depth
- Multiple independent layers of protection, so a failure in one is caught by the next. The core security posture for AI.
- Single point of failure
- Anything you're relying on alone. If it fails, nothing else catches it, the thing to hunt down and back up.
- Separation of trust (dual-LLM)
- Splitting work so the AI exposed to untrusted content has no power, and the AI with power never reads untrusted content directly.
- Trust boundary
- The line between content you control and content you don't. Crossing it is where injection happens.
- Governance
- The human layer: a named owner, a policy for what AI may touch, vendor accountability, and an incident plan.
- Incident response
- Your pre-written plan for the first hour after an AI does something wrong. Cheaper to write than to improvise.
Check · lock in the one thing that matters
Three quick questions
Pick an answer for each, then check the key below.
-
What does "defense in depth" mean for an AI system?
- Using the single most advanced AI model available.
- Stacking multiple independent layers, each assuming the one before it can fail, so no single failure reaches your data.
- Hiding the AI deep inside your network.
-
Why is a 99%-effective security control considered a failing grade?
- Because 99% is a low score in school.
- Because an attacker simply retries; a 1% gap is reliably exploitable, so no single probabilistic check can be the whole defense.
- Because customers expect 100% uptime.
-
The "separation of trust" (dual-LLM) pattern works by...
- running two copies of the same AI for speed.
- keeping the AI that reads untrusted content powerless, and the AI with tools and data access away from raw untrusted content, so nothing is both trickable and dangerous.
- asking the user to approve every message twice.
1. Answer: B. There's no perfect wall. You combine least data, least privilege, human gates, monitoring, measurement, and governance so the damage is contained when any one layer fails.
2. Answer: B. Attackers aren't limited to one try. That's why you never rest the defense on a single filter or prompt rule, and instead design so a 1% failure is survivable, not catastrophic.
3. Answer: B. A poisoned input can hijack the powerless reader, but that reader can't reach data or take actions. It's the most direct structural answer to the lethal trifecta.
The one line to remember
There's no single fix; its makers say so. Stack independent layers, keep dangerous input away from real power, and name the person who owns the day it goes wrong.