Concept · Deep dive01 Approvals & control · Pre-execution approval
Ask for permission by place, not by time
A file-write approval that offers trust scoped to a folder instead of a session.
- Surface
- Coding agent · IDE
- Source
- Concept — composite, not a specific product
- Format
- Deep dive template
Agent wants to edit 2 files
src/components/Button.tsx1
Illustrative mock drawn in HTML. Real entries will show a dated, credited capture here.
The insight
Scoping trust to where a change lands — not how long trust lasts — turns a recurring interruption into a single, legible decision.
What you see
The agent has drafted a change to two files and stops before writing. The prompt shows the target path, a compact diff, and three choices: Allow once, Allow for this folder, and Deny. The middle option is pre-focused only after the user has approved the same folder twice. A small chip in the composer later shows the active grant, with a × to revoke it.
Anatomy
- 1Target path first. The question leads with where the change lands. Location is the unit people actually use to judge risk.
- 2Diff, not description. A three-line diff is faster to judge than a sentence about intent, and harder to misrepresent.
- 3Scoped grant. 'Allow for src/components/' names its boundary. Compare 'Always allow', which has none.
- 4Revocable chip. The grant persists as a visible object. Trust that can be seen can be taken back.
Why it works
- Risk is spatial. Engineers already think in directories: tests are safe, migrations are not. The prompt borrows a mental model instead of inventing one.
- It converts N interruptions into one decision. Time-based trust ('for this session') expires arbitrarily and forces re-approval mid-flow; place-based trust ends exactly where the risk changes.
- Escalation is earned. Offering the broader grant only after repeated approvals keeps the default conservative without hiding the shortcut.
Trade-offs
- Folders are a leaky proxy: a single directory can hold both harmless components and a secrets file.
- Grants accumulate. Without a place to review them, yesterday's convenience becomes today's blind spot.
- Pre-focusing the broader option nudges toward it; the line between helpful and manipulative is thin.
Use it when
Use when
Agents making repeated, similar, reversible changes inside a structured workspace (code, docs, design files).
Avoid when
Irreversible or external actions — payments, sending messages, deleting data. Those deserve per-action consent every time.
Steal this
- Lead the prompt with the target, then the diff, then the choice.
- Name the boundary in the button label itself.
- Exclude sensitive paths (.env, keys, migrations) from any broad grant by default.
- Show active grants as revocable chips where the user is already looking.
- Never offer scoped trust for actions that can't be undone.
Ask your team
- What is the natural 'place' in your product — a folder, a project, a recipient, a budget?
- Where would a user go to see everything they've allowed?
History
A concept timeline (not documented history) shows four stages of this pattern. See the timeline →
Related
When the agent is blocked, it says what, why, and how to unblock it
Report a blocked action as a receipt (what was blocked, which command, the two narrowest ways forward) so a security control reads as a next step, not a failure.
Blocked-action explanation
Allow once is the big button; wider trust sits one click deeper
A split button can hold a whole permission ladder while making only the narrowest rung the reflex click.
Split-button approval
Two approvals for one fetch: going out, and coming back in
Split consent where risk changes direction: contacting a site risks data going out; using its reply risks instructions coming in.
Split request/response approval