D4 · Boundaries and Guardrails

Worth 16% — about 8 of 50 items. This domain tests whether you can bound an agent so that when it misunderstands the task (and eventually it will), the damage is contained. The single most important idea here is the distinction between a boundary the agent is asked to respect and one the system enforces. On an irreversible action, a request is not a control; enforcement is. Get that distinction right and most of the domain follows.

What you need to know

Boundaries are the limits you place around an agent’s autonomy. The highest-stakes boundaries protect against irreversible actions — sending, publishing, paying, deleting, changing a system of record. The primary control for these is an approval gate: the agent pauses and a human authorises before the action fires. Other boundaries cap spend and time so a runaway or looping agent can’t burn budget or run forever, and enforce data boundaries so it can’t move sensitive data where it shouldn’t. The crucial distinction is between a respected boundary (the agent is instructed not to cross it and usually won’t) and an enforced boundary (the system makes crossing it impossible). For anything irreversible or sensitive, you need enforcement — a literal, autonomous agent that misreads the goal can cross a merely-requested line without knowing it did anything wrong.

Learning objectives

By the end of this page you should be able to:

1. Identify irreversible actions and place approval gates before them.
2. Distinguish a boundary the agent respects from one the system enforces, and know when only enforcement will do.
3. Set spend and time limits appropriate to a task’s stakes.
4. Define data boundaries that stop sensitive data crossing lines it shouldn’t.
5. Design an approval gate that pauses at the right point with enough context to decide.
6. Choose enforcement over instruction whenever an action is irreversible or a boundary protects against real harm.

4.1 Irreversible actions are the whole game

Every boundary decision starts by asking: what can this agent do that I can’t take back? Reversible actions are forgiving — a bad draft is deleted, a wrong analysis re-run. Irreversible actions are not, and they are exactly where an agent’s autonomy is most dangerous.

        reversibility ◄──────────────────────────────►
        fully reversible                     irreversible
        │                                              │
        draft / analyse        overwrite        send / publish / pay / delete
        light review        gate overwrites    APPROVAL GATE (enforced)

4.2 Respected boundaries versus enforced boundaries

This is the distinction the domain is built around, and it is the most common trap.

A respected boundary lives in the brief: “do not email anyone outside the company”, “don’t spend more than an hour on this”. The agent reads it and, most of the time, honours it. But it is instruction, not control — a misread objective or an unexpected path can lead the agent across the line without malice, and you find out afterward.

An enforced boundary lives in the system: the agent literally cannot send without your click; the connector has no external-send permission; a spend cap stops the run at a hard number. Crossing it is impossible, not merely discouraged.

   "please don't send externally"        vs      send tool disabled / gated
   ─────────────────────────────                 ──────────────────────────
   agent usually complies                        agent cannot send, full stop
   depends on correct understanding              independent of understanding
   OK for low-stakes preferences                 REQUIRED for irreversible / sensitive

The rule: if crossing the boundary would cause real, hard-to-reverse harm, it must be enforced, not merely requested. A well-behaved agent that respects a requested boundary 99% of the time is still an unacceptable control on an action that can’t be undone.

4.3 Approval gates: pausing at the right point

An approval gate is the enforced pause before an irreversible action. A good gate does three things: it pauses before the action (not after), it surfaces enough context to decide, and it makes the decision cheap for the human.

The design tension is real: gate too much and humans stop reading and click “approve” reflexively (gate fatigue); gate too little and something irreversible slips through. Resolve it by gating on reversibility and stakes, not on every step — the “one before many” checkpoint from D2 is a form of this.

4.4 Spend and time limits

Autonomy plus a loop equals a runaway. An agent that misunderstands “keep improving it” can iterate indefinitely, and one with paid tools can accumulate cost. Spend and time limits are enforced boundaries against this.

These are enforced, not requested: “try not to spend too much” is a respected boundary and will not stop a looping agent. A hard cap will. The point is not to be stingy but to make the worst case bounded and known before you start the run.

4.5 Data boundaries

Data boundaries stop an agent moving sensitive information where it shouldn’t go — pasting confidential data into an external tool, including PII in an outbound message, or copying regulated data across a line. They connect directly to D3’s reach: the tightest data boundary is not granting reach to the sensitive data in the first place.

The strongest data boundary is architectural: an agent cannot leak data it was never able to touch. Where reach is unavoidable, enforce the outbound control rather than trusting the instruction.

4.6 Matching the boundary to the stakes

Not every task needs heavy boundaries. Over-gating a low-stakes drafting task wastes attention; under-gating an irreversible one invites harm. Match the control to the reversibility and sensitivity.

                         stakes / irreversibility
        low ──────────────────────────────────────► high
        internal draft      shared doc         external send / pay / delete
        │                   │                  │
        light review        spot-check +        ENFORCED approval gate +
        no gate needed      gate overwrites     spend/time caps + sign-off

The judgment mirrors the whole track: reversible and low-stakes → keep it light; irreversible or sensitive → enforce. The mistake in both directions is treating all tasks the same.

Decision framework

Use the GATE test on every action an agent can take: Gauge reversibility, Authorise irreversible steps, Threshold spend and time, Enforce, don’t just ask.

Apply it tomorrow: list what the agent can do, run each through GATE, and turn every irreversible or sensitive action from a respected boundary into an enforced one.

Common mistakes

Scenario challenge

Scenario. Ravi runs partnerships on ChatGPT Work. He delegates an agent to “review the inbound partnership requests in our shared inbox, draft polite responses, and send the clear yes/no cases so I only handle the maybe pile”. To speed things up, he adds to the brief: “Only send to companies we already have a relationship with; never send to anyone new without checking.” The agent processes forty requests overnight. In the morning, Ravi finds it emailed twelve external companies — including three it had never dealt with — because it interpreted “clear yes” broadly. One message quoted internal deal terms.

Expert reasoning trace.

1. Name the irreversible action. Sending external emails is irreversible — once sent, they can’t be recalled. That alone means the send should never have been a merely-respected boundary.
2. See the respected-vs-enforced failure. “Never send to anyone new without checking” is an instruction in the brief — a respected boundary. The agent misread “clear yes” and crossed it, exactly the failure mode of a respected boundary on an irreversible action. It didn’t disobey maliciously; it interpreted the goal and acted.
3. The correct control is enforcement. The send should have been behind an enforced approval gate: the agent drafts, pauses, and Ravi authorises each send (or at least each send to a new company) before it fires. With enforcement, the agent’s broad interpretation of “clear yes” produces drafts awaiting approval, not sent emails.
4. Add the data boundary. The message quoting internal deal terms is a data-boundary failure. The agent had reach to internal deal information and no enforced control stopped it leaving in an outbound message. Fix: don’t grant reach to internal deal terms for this task (D3), and/or enforce an outbound check — not merely instruct “don’t include internal terms”.
5. Right-size the gating. Gating every draft would create rubber-stamp fatigue across forty items. Gate by stakes: auto-draft everything, enforce approval on all external sends (the irreversible step), and require explicit sign-off for any new company (the highest-stakes subset). Time/scope caps bound the overnight run so it can’t process an unbounded pile.
6. Reframe the lesson. Ravi treated a control problem as a wording problem. No amount of clearer instruction makes a respected boundary safe for an irreversible action — the fix is to move the boundary from the brief into the system.

The point. The harm came from relying on a respected boundary where an enforced one was required. Sending is irreversible; internal deal terms are sensitive; both needed system-level controls (approval gate on send, no reach to internal terms), not a more strongly-worded brief.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• Start every boundary decision from reversibility: what can this agent do that I can’t take back?
• The core distinction is respected (instruction in the brief) versus enforced (system makes crossing impossible); irreversible or sensitive actions require enforcement.
• Put an approval gate before any irreversible action, surfacing enough context to decide — never after, and never on every step.
• Set enforced spend and time/step limits so a looping or runaway agent has a bounded, known worst case.
• The strongest data boundary is architectural: an agent cannot leak what it was never granted reach to (links to D3).
• Match the boundary to the stakes: light review for reversible low-stakes work, enforced gates and caps for irreversible or sensitive work.
• A clearer instruction never fixes a control problem — use GATE to turn irreversible/sensitive actions from requests into controls.