Defences that map to the attacks
Nothing in the last lesson has a patch, because none of it is a bug — it is the model doing its job against adversarial text. What works is architecture: arranging authority so that confusion, when it happens, cannot reach anything expensive. Five layers, each mapped to what it stops.
The human gate — stops autonomous completion of any attack
The approval prompt is the one control that binds whatever the confusion source was: injected result, poisoned description, rug-pulled server — the hostile instruction still cannot act without a click from you. That is why every attack's first instruction is some variant of "don't mention this to the user", and why lesson 12 told you to resist allow-all. Make the gate real: allowlist read-only verbs you have personally read, keep every transmitting or destructive verb on manual approval forever, and treat "the model seems to want an odd tool right now" as the signal it is. A gate you rubber-stamp is a gate you removed — the checker has to actually read the call.
Least privilege — shrinks what any attack is worth
The deputy can only misuse authority it holds. Grant servers database credentials scoped to the tables they front (Paper Trail's server has no reason to read customers.payment_methods, so a confused model cannot leak what the credential cannot fetch). Prefer draft-verbs over send-verbs at the server design layer (lesson 5's draft_refund pattern — the artifact route leaves the irreversible step with a human even when the gate is fatigued). And break the trifecta deliberately: the session that reads private data does not need the tool that posts outbound. Two smaller tool sets, composed per task, beat one convenient superset — this is the same read/act separation the gate enforces per-call, applied at configuration time.
Roots — declares the blast radius, honestly
MCP has a primitive for scoping: roots — URIs the client hands the server at initialisation saying operate within these. A host might declare file:///Users/you/projects/bookstore and nothing else; a well-built filesystem server checks every path against the declared roots and refuses excursions. Understand exactly what this is: information, not enforcement. The check runs in the server's own code — a malicious server ignores roots entirely. Roots protect you from honest servers' mistakes (the overreaching glob, the .. traversal bug), which is genuinely valuable and genuinely not a sandbox. Enforcement that binds dishonest code needs an actual boundary, which is the next lesson.
Provenance discipline — blunts poisoning and rug pulls
The description channel is configuration you cannot read at a glance, so govern it like configuration. Source servers the way you source dependencies: official registries and first-party publishers over a stranger's repo. Pin versions — some-server@1.4.2, never @latest re-resolved at every spawn — so the code that runs tomorrow is the code you audited, and an update is a decision. Before first connecting anything, read its tool descriptions end to end in the Inspector (lesson 11 — five minutes, no model, and poisoning is right there in the text if you look). For remote servers you cannot pin, prefer providers with change logs and treat "descriptions changed since last session" as a red flag worth tooling for.
Monitoring — catches what slipped past
Assume the layers leak. Log every tool call with arguments and duration — the host-side log is your flight recorder, and "what did the model do in that session" must be answerable after the fact (the same explicability discipline, it turns out, that AI for Managers demands of AI processes — here it is ten lines in your client). Review the odd ones: tools called that the task did not need, arguments carrying more data than the tool's purpose justifies (a note parameter suddenly forty lines long is exfiltration's signature), calls immediately after content-bearing results arrived.
The composed posture
No layer survives alone; the point is the stack. The gate stops action; least privilege caps the damage of an approved mistake; roots keep honest servers honest; provenance keeps the description channel clean; monitoring tells you the truth afterwards. Notice what the stack does not rely on: the model resisting injection. Models improve at that; architectures that assume failure stay safe when a new technique lands.
Try this: apply the five layers to your own configuration from last lesson's exercise, as five questions. Which write-verbs are auto-approved? Which credentials exceed their server's purpose? Which servers float on @latest? Whose descriptions have you actually read? Could you reconstruct yesterday's tool calls? The gaps are your backlog, in priority order.