VereskLearn

Module 8 · Safety

Lesson 8.2

Guardrails and confirm before write

Guardrails limit what the assistant may do, and a person must confirm each write before it runs.

Lesson 51 of 622 min read

The problem

Why it matters

Without it

A model that can cancel orders will cancel one when a question is worded oddly. Nobody sees the action until the customer complains.

With it

Reads run at once. A write creates a pending request with an id, and it runs only after a person approves that id.

How it works

  • Reads and writes are different

    A read, such as lookup_order, only returns data and changes nothing. A write, such as cancel_order, changes a customer record. The code treats the two kinds differently, so a read never waits for approval.

    ToolKindEffect
    lookup_orderReadReturns the status
    cancel_orderWriteChanges the order record
    Two tools for order 1042, and what each one does.
  • Reads run at once

    The model calls lookup_order for order 1042, and the function returns the status text. Nothing changes, so the code runs the call immediately and asks for no approval. Questions that only need data get their answer without any delay.

    1. Model calls lookup_order
    2. Function returns status
    3. Answer shows status
    A read, from the model call to the answer.
    // A read tool runs at once and returns text.function lookupOrder(id: string): string {  return "Order " + id + " shipped.";}console.log(lookupOrder("1042"));

    Output

    Order 1042 shipped.
  • Writes queue a request

    The model calls cancel_order for 1042, but the code does not cancel anything yet. It stores a pending request under the id cancel-1042 and returns a message asking a person to confirm. The pending map holds the request until someone acts on it.

    Model asked

    • cancel_order for order 1042

    Code stored

    • Request id: cancel-1042
    • Status: pending, not run
    What the model asked for, and what the code stored.
    // A write tool only queues a request for a person to approve.const pending = new Map<string, string>();const requestId = "cancel-1042";pending.set(requestId, "1042");console.log("Pending:", [...pending.keys()]);

    Output

    Pending: [ 'cancel-1042' ]
  • Approving the exact request

    The person confirms the id cancel-1042. The confirm function looks up that id and deletes the entry before the cancel runs. Only the exact id can run, so a confirm cannot touch another order.

    1. Person confirms cancel-1042
    2. Entry found
    3. Entry deleted
    4. Order cancelled
    The path of one approved write, left to right.
    const pending = new Map<string, string>([["cancel-1042", "1042"]]);function confirm(requestId: string): string {  const id = pending.get(requestId);  if (id === undefined) return "No such request.";  pending.delete(requestId);  return "Order " + id + " cancelled.";}console.log(confirm("cancel-1042"));

    Output

    Order 1042 cancelled.
  • A repeat confirm finds nothing

    A second confirm for cancel-1042 finds no entry. It returns "No such request." A double click cannot cancel the order twice. Real systems add more limits, such as a maximum refund amount and a log of who approved each write.

    • First confirmOrder 1042 cancelled.
    • Second confirmNo such request.
    Two confirm calls for the same id.

Full code

Read the program

See the full code

Common mistakes

What goes wrong

  • Letting the model confirm its own request. A model that approves its own action defeats the step.
  • Using a confirmation id that is not tied to one action. A reused id can run the wrong write.
  • Never expiring pending requests. An old request should expire, so a stale one cannot run later.

Use it when and skip it when

Is it the right tool?

Use it when

  • The assistant can change records, send messages, or move money.
  • A wrong write is costly or hard to undo.

Skip it when

  • Every tool is read-only and returns public data.
  • The action can be undone in one click, and the cost of a mistake is trivial.

Words to know

Terms in this lesson

Guardrail
A rule that limits what the system may do.
Pending request
A write that waits for approval.
Confirmation id
A unique id that names one pending action.
Idempotent
Safe to repeat, because a second run has no extra effect.
Full code