Tools and permissions

Lesson 1 ended with the model locked in an office, passing slips of paper through a slot. This lesson is about the slips. What can be written on them (tools), who decides whether they get acted on (permissions), and why the second question is the one that keeps you out of trouble.

What a tool actually is

A tool is a function the model is allowed to request. "Function" here just means a named action with inputs, the way a form has fields. Search the web for X. Read the file at this path. Send an email to this address with this text. Run this program. The harness hands the model a menu of these at the start of a conversation, each with a short description of what it does and what it needs.

When the model decides it needs one, it does not do anything. It writes a structured request in its reply, something like "call send_email with to: customer, subject: Your quote, body: ..." The harness reads that, runs the real email code, and pastes the result back into the conversation as if a coworker had answered. The model reads the result and decides what to do next. That is the loop from lesson 1, and tools are what it loops over.

This design has a consequence worth sitting with: the model's ability to affect the world is exactly the list of tools it was given, and not one thing more. A model with only a "read file" tool cannot send email no matter how clever it is or how hard someone tries to trick it. It has no slot for that request to go through. Everything about agent safety follows from this.

Read, write, pay

Tools sort into three piles, and the piles matter more than the individual tools. Ask of every tool: if this goes wrong, can I undo it?

• Read tools look at things: search, open a file, list the inbox, check the calendar. If a read goes wrong, the model got bad information. Nothing outside the chat changed. Fully reversible, because there is nothing to reverse.
• Write tools change things: save a file, send an email, book a slot, post to Facebook, delete a record. Some writes are cheap to undo (a file you can restore), some are impossible (an email that was sent, a text that was read). The word to keep in mind is blast radius: how many people see the mistake and how fast.
• Pay tools move money: pay an invoice, issue a refund, buy ad credit, place an order. These are writes where the undo requires another human, a phone call, and sometimes a lawyer. Treat them as their own category, because they are.

A tint shop in St. George thinking about an agent for its inbox would list: read inbox (read), read the price sheet (read), save a draft (write, easy undo), send a reply (write, no undo), issue a deposit refund through the card processor (pay). Same agent, same model, five tools across three piles. The decision of which piles to turn on is not a technical one. It is the same decision you make about a new hire.

Permissions: the dial that matters

A permission is a rule the harness applies when the model asks for a tool. Allow it silently. Block it. Or stop and ask the human. Every serious agent product ships with some version of this dial, and the levels are more alike than the marketing suggests. As of September 2026, Claude Code names its modes Manual (reads run freely, edits and commands prompt), Plan (look before touching), Auto (a second model reviews actions and pauses on risky ones), and a bypass mode its docs reserve for walled-off machines. OpenAI's Codex CLI offers Ask for approval, Approve for me, Full access, and a Custom preset. Different labels, same dial.

Tap through the four levels below and watch what the same agent, with the same brain and the same request, is able to do at each one.

Notice that the model's quality never came up. Whether it is the smartest model on earth or a mediocre one, the read-only agent cannot send an email and the full-access agent can. Permissions are not a feature layered on top of the AI. They are the boundary of what the AI is.

The approval prompt

The middle setting on the dial, act with approval, is where most people should live for a long time, so it deserves a closer look. When the model requests a tool that is set to "ask," the harness shows you what it wants to do and waits. You read it. You tap yes or no. Sometimes you can add a note ("not that customer, they already paid"), and the model gets your note as its next piece of information.

Two things make approval prompts work, and both are on you. First, the prompt has to show the actual action, not a summary. A prompt that says "send reply?" is useless; one that shows the recipient and the full text is a real checkpoint. Good tools do this. Second, you have to keep reading them. The known failure mode is prompt fatigue: forty approvals in, you are tapping yes on rhythm. That is why lesson 5 recommends fewer, higher-stakes prompts rather than a prompt on everything, and why makers are building the second-model review that Claude Code's Auto mode describes. A reviewer that never gets tired of reading is worth having. It is still not a replacement for you on the actions that cannot be undone.

Why permissions are the whole safety story

People ask two questions about agent safety: is the model trustworthy, and is the setup trustworthy. The first question has no clean answer and never will, because "trustworthy" depends on what it was asked, what it read, and what mood the dice were in. The second question has a clean answer, because a setup is a list of tools and the rules on each one, and you can read that list.

So the discipline is: decide what the worst outcome is, then set permissions so that outcome needs a human tap. Not "set permissions so the model behaves." The model's behavior is a probability. The permission is a wall. Read tools on, write tools behind a prompt, pay tools off, and a log of everything it did that it cannot edit. Do that, and the question "what if the AI does something crazy?" has a boring answer: it asks first, and you say no.

This is also why the vendors' own documentation is the most honest marketing you will read. Anthropic and OpenAI both put the walled-off, no-prompts mode behind warnings, because they know exactly what a model with full access and a bad instruction can do. When the maker tells you to use a fence, use the fence.

Try this yourself

Before you ever turn on an agent, write its permission sheet. It takes ten minutes and it is the single most useful document in this module. Paste this into any AI app and fill in the blanks about your own business.

I run a [type of business] in [St. George / Hurricane / Washington]. I am considering letting an AI agent help with [the job, e.g. answering quote requests by email].

List every tool it would need, one per line. For each one, label it READ, WRITE, or PAY. For each WRITE, say whether the action can be undone and how many people would see a mistake. Then recommend a permission for each tool: allow silently, ask me first, or off. Assume I want the safest setup that still saves me real time. Be blunt about which tools I should not turn on this year.

Keep the result. When you get to lesson 5, that sheet becomes rung one of your rollout ladder. And if you want to see where the harness that enforces these rules actually lives, that is lesson 4.