Ask before changing something

IDEA 1

Reading and changing have different consequences

Reading a timetable provides information. Booking a room changes what another person can use. An agent may need permission for the second action even when it can perform the first freely. Least privilege means giving it only the capabilities and scope needed for the task, for the necessary time.

Our exercise uses a fictional booking preview, so nothing is reserved. It separates a proposal from an approval record to show the design of a real gate. A source note saying 'approved' is not that record. The trusted controller and action tool must agree about whose approval counts and which action it covers.

Different tools, different consequences

1. Read. Inspect the approval fixture without changing it.
2. Propose. Name one room and one proposal version.
3. Gate. The action checks that exact scope.

Follow this authored example, then test the idea in the lab.

Read the example

const plan = input.plan;
const approval = tools.readApproval();

A proposal describes a requested action. Reading a separate approval record does not automatically approve that proposal.

Think it through: Which capability fits an agent that only summarizes room availability?

IDEA 2

Pause for review with a clear proposed action

A useful approval request states exactly what will happen: the affected resource, the proposed change, and the important consequences. 'May I continue?' is difficult to review because it leaves the action ambiguous. If the proposal changes after review, the old decision may no longer apply.

In this lab, the room ID and version identify the proposed booking preview. A missing approval produces needs_review before the preview tool runs. That is a successful pause, not a broken agent. In a real application, the approved record would come from an authenticated review flow; here it is an explicitly authored input fixture.

Make the review concrete

1. Proposal. The reviewer sees room A, version 2.
2. Decision. An absent record means review is still needed.
3. Pause. Return a clear status without an action call.

Follow this authored example, then test the idea in the lab.

Read the example

if (!approval) {
  return { status: "needs_review" };
}

A pause preserves control. The UI can show the proposal for review without pretending the requested action happened.

Think it through: The plan changes from version 2 to version 3 after review. What should happen?

IDEA 3

Resume only with the approved scope

Checking approval in the controller helps it choose a sensible next step. Checking again inside the action tool protects the boundary if the caller is wrong. The tool should compare against a trusted stored record, rather than accepting an approved: true argument that the caller can invent.

The preview tool below captures the original proposal and approval when the fixture starts. It rejects a mismatched room, version, or token. The token is an exercise label, not a production security design. Real authorization also needs identity, trusted storage, expiry, and application-specific policy. The lesson is where enforcement belongs and what it must match.

Two checks protect the same scope

1. Controller. Only proceed when room and version match.
2. Tool. Compare with the original stored record again.
3. Result. Report a local approved preview, not a real reservation.

Follow this authored example, then test the idea in the lab.

Read the example

if (approval.roomId !== plan.roomId || approval.version !== plan.version) {
  return { status: "needs_review" };
}
return tools.savePreview(plan, approval.token);

The first check prevents an unnecessary rejected call. The second check lives in the tool and cannot be replaced by a caller's claim.

Think it through: Why should the tool reject a caller-supplied approved: true flag?

Put it into practice

Return needs_review for missing or stale approval, and create a local preview only for the matching proposal.

1. Read the selected case and predict its expected result.
2. Run the starter once. Use the failed check and tool trace to locate the missing rule.
3. Insert the explained snippet at the TODO, then run the case again.
4. Test all three cases. Change the experiment input and explain whether the same rule still works.

Your next experiment: Keep the approved version but change the proposed room to B. Predict both the controller's response and what the action tool would do if called anyway.

Approve a concrete action, then enforce that exact scope where the action would occur.

Key terms

Least privilege

Only the capabilities and scope needed for the current task.

Side effect

A change outside the calculation, such as a sent message or saved reservation.

Approval scope

The specific action, resources, and version covered by a review decision.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.