Two defenses run through this course, and they are not the same kind of defense. Careful tool descriptions, tight input schemas, and instructions that steer a model away from reading a file it doesn't need — all of that is prompt-level mitigation. It works by shaping what the model asks for, and it genuinely reduces how often something goes wrong: a well-scoped tool description gets misused less often than a vague one. But it is a probabilistic defense. It bends the odds; it does not enforce a boundary.
Least privilege is the other defense, and it operates on a completely different axis. Instead of trying to make a bad request less likely, it makes a bad request unable to do damage even when it happens. A tool that only has read permission on a directory it doesn't control can be asked to delete a file a thousand different ways — badly worded prompts, an adversarial tool result, an outright bug in the agent's planning loop — and the deletion still won't happen, because the permission to delete was never granted at the layer that actually executes code.
The two are not substitutes. Prompt-level mitigation lowers the frequency of a mistake; least privilege bounds its consequence. Lesson 22 built this idea for credentials specifically — scope a token down to `crm:read` and a compromised session can only read, never write, no matter what the model was tricked into asking for. This lesson generalizes the same principle from the credential a tool holds to the entire execution surface around the tool: the filesystem it can touch, the time and output it's allowed to consume, the hosts it can reach, and the point past which a human has to say yes. When the first defense fails — and across enough calls, it eventually does — the second one is the only thing still standing.