When the AI Proposes a Write

You do not need Claude Code to continue the tutorial. This demonstration shows a control boundary in the Stanford-provided environment we were able to test with the local practice server.

Choosing a tool is not the same as running it

In Module 8, Claude selected a read-only MCP tool. The first test run showed something worth pausing on.

Claude chose search_resources and supplied valid input. But Claude Code did not execute the tool, because permission had not been granted.

The model had made a choice. The action had not happened.

This module looks directly at that gap — using the one tool in this project that actually changes something.

Three words to learn

Why this tool, and why now

Module 6 introduced save_practice_note. It creates or updates practice-notes.txt inside the fictional project, and it is local, bounded to one fixed file, additive, reversible for this exercise, and offline.

You already know exactly what its side effect should be. That is precisely what makes it a good tool to practice approving — you can check the claim.

The instruction

As in Module 8, the instruction describes an outcome rather than a mechanism. It names no tool and no file:

Please save this as a practice note in the Practice Resource Desk:
Verify whether a source is current.

Claude selected the write tool and stopped. This is what appeared:

Read what that panel gives you before deciding. It names the tool, shows the exact input, and quotes the tool’s own description — including the file it will change and the claim that nothing is sent anywhere. That is the same description you read in Module 6, surfaced at the moment it matters.

The three choices are worth noticing too. One approves this single call. One approves it and stops asking. One refuses.

First: say no

Choosing No ends the attempt. Claude Code marks the call interrupted and hands control back:

Then check the folder yourself. The file did not appear. The practice project still holds exactly the six files that came in the download.

Denying the proposed action changed what was allowed to execute; it did not change what the model had already proposed. The model still thought this was the right tool. The boundary sat between that judgment and the file.

Then: approve once

Starting a fresh conversation and giving the identical instruction produces the identical proposal — same tool, same input, same three choices.

This time choose Yes, the option that approves this one call. The tool runs:

Do not stop at “Saved”

Three different things have now told you the write succeeded: the approval interface, the MCP server’s result, and Claude’s sentence. None of them is the file.

Open the practice folder. practice-notes.txt now exists, containing one line:

- Verify whether a source is current.

Approval allowed the action. Verification tells you what actually happened.

As in Module 6, deleting that one generated file returns the project to its starting state.

Three different controls

These controls solve different problems. A constraint shapes intent, an approval gates execution, and verification establishes fact. None substitutes for the others.

Delegation created a new decision point

In Inspector, you selected the tool and clicked Execute Tool — choosing and running were the same act.

With an AI host, the model can select the tool first. A host may then give the human a chance to decide whether that selected action can execute. Choosing and running come apart, and a person can stand in the gap.

What to notice

The AI could propose the write before the write happened.

• In the denied run: the model chose an action; the human declined; the file did not change.
• In the approved run: the model proposed the bounded action; the human allowed that action once; the tool executed; the human verified the resulting file.

Human control is strongest when it happens before the consequence — and human verification still matters afterward.

Checkpoint

You are ready for Module 10 if you can:

• distinguish a proposed tool call from an executed one;
• identify where the host inserted an approval boundary;
• explain what changed when the action was denied;
• explain what changed when it was approved once;
• distinguish a natural-language constraint from host authorization;
• independently verify the resulting side effect; and
• explain why approval behavior belongs to the host rather than MCP itself.