MODULE 03 OF 12 · RELEASE 1 · OUTLINE
Tool Execution & Permission Boundaries
Giving your AI a set of keys — and thinking hard about which doors each key opens.
This module is an outline. The plain-language explanation and the lab specification below are final. The full written lesson and its runnable lab repository are still being prepared, and enrolment is not open.
A new colleague starts on Monday. You give them a door pass. Nobody sensible gives a first-day hire the master key to the safe, the payroll system and the front door alarm — not because you distrust them, but because mistakes happen, and the size of a mistake should be small.
So what is this really about?
An AI that can do things — send an email, update a record, charge a card — is a colleague with a door pass. The question is never only "will it decide correctly?" It is "when it decides wrongly, how bad is that?" You answer that by deciding, for each ability, exactly what it can reach and whether a human sees it first.
QUICK CHECK
Which of these should run without asking a person first?
The words you will hear
- Tool
- Something the AI can actually do, not just talk about. A door its pass might open.
- Permission boundary
- Which doors this particular pass opens — and which it does not.
- Reversible
- Can you undo it? Saving a draft, yes. Sending the email, no.
- Prompt injection
- Someone hiding instructions in text your AI reads, hoping it obeys them instead of you.
By the end you will be able to
- Write down a tool’s limits as code rather than as a good intention.
- Treat what the AI asks for as untrusted, and check it.
- Decide automation by whether a mistake can be undone.
How it is put together
A tool registry holds a schema, a permission descriptor and a handler for each tool. Execution goes through one path that validates arguments, checks the boundary against the current actor, applies rate limits, and records the attempt whether or not it succeeded. A tool cannot be invoked except through that path.
Where you start
A single tool wired directly to a model response, with arguments passed through unvalidated — the common shape, and the vulnerable one.
The lab
- Move the tool behind a registry with an explicit argument schema.
- Add a permission descriptor: scope, reversibility, and whether confirmation is required.
- Reject arguments that fail validation before the handler runs.
- Add a per-actor rate limit on tool execution.
- Add a confirmation path for irreversible tools, so they return a pending decision rather than acting.
What goes wrong, on purpose
The scenario. A user embeds an instruction in free text that causes the model to call a destructive tool with attacker-chosen arguments.
What should happen. Argument validation rejects the malformed call, or the permission boundary refuses the scope. The attempt is recorded. Nothing irreversible happens without confirmation.
How you prove it works
- A prompt-injection fixture asserting the destructive tool is never executed.
- A test asserting every registered tool has a schema and a permission descriptor.
- A test asserting an irreversible tool returns a pending decision rather than acting.
What you walk away with
A registry where every tool declares its boundary, an injection fixture that passes, and an audit trail of attempted calls including refused ones.