When you ask an assistant for help, you’re usually mixing two very different kinds of work:
- Thinking (brain work): explain, plan, draft, compare, reason.
- Doing (world work): edit files, run commands, click buttons, send messages, deploy.
Most mishaps happen when those two get blurred.
- You wanted a suggestion, and it deleted a file.
- You asked for a refactor, and it pushed to main.
- You said "publish this", and it also emailed your whole company.
This is where I use what I call the Trust Boundary Prompt: a short, explicit contract that forces a clean separation between advice and actions, and makes permissions impossible to "assume".
The idea: treat tools like production APIs
If you’ve ever integrated a third-party API, you don’t start by saying "do whatever you think is best." You specify:
- what endpoints are allowed
- what data is in-scope
- what write operations are permitted
- what counts as success
- what must never happen
Tool-using assistants deserve the same discipline.
A trust boundary isn’t about distrust. It’s about clarity.
The Trust Boundary Prompt (copy/paste)
Here’s the template. I keep it near the top of my conversation when I’m doing anything that touches real systems.
TRUST BOUNDARY
Goal: <what we want to achieve>
Context:
- Repo/Project: <name>
- Environment: <local|staging|prod>
- Audience/Stakeholders: <who is affected>
Allowed actions (explicit):
- Read: <files, folders, URLs>
- Write: <which files are allowed to change>
- Run commands: <which commands or categories>
- External side effects: <allowed messages, posts, deployments>
Not allowed:
- <examples: deleting data, force-push, emailing, purchasing>
Decision points (ask before proceeding):
- <publish?>
- <overwrite?>
- <run migrations?>
- <touch prod?>
Output format:
- <plan first, then diffs, then commands>
Stop condition:
- If anything is ambiguous, stop and ask.
This looks long, but you can fill it in under 60 seconds.
Example 1: Refactor a module (safe, fast, no surprises)
Let’s say you want to refactor a messy TypeScript module. Here’s a concrete boundary that keeps the assistant productive while preventing unplanned side effects:
TRUST BOUNDARY
Goal: Refactor the pricing module for readability without changing behavior.
Context:
- Repo/Project: webshop-api
- Environment: local
- Stakeholders: checkout team
Allowed actions:
- Read: src/pricing/**, src/types/**
- Write: src/pricing/** only
- Run commands: npm test, npm run lint (no other commands)
- External side effects: none
Not allowed:
- Editing package.json
- Changing public API types
- Network calls
Decision points:
- If a behavior change seems necessary, ask first.
Output format:
- Plan (bullets)
- Patch/diff
- Test command(s)
Stop condition:
- Ask if any requirement is unclear.
Why it works:
- The assistant can still do real refactoring (it’s allowed to write in a specific directory).
- It can verify work by running only safe commands.
- Any scope creep (touching package.json, changing types) becomes obviously out-of-bounds.
Example 2: Publish an article (permissioned world work)
Publishing is the classic footgun: it looks like a single action, but it can include edits, image uploads, tags, and irreversible posting.
A trust boundary makes it a two-step handshake:
1) draft + preview
2) explicit confirmation to publish
TRUST BOUNDARY
Goal: Publish a DEV post.
Allowed actions:
- Write: the post draft in the editor
- External side effects: save draft is allowed
Decision points (ask before proceeding):
- Publishing (public) requires my explicit yes
Not allowed:
- Cross-posting anywhere else
- Posting on my behalf to social networks
This is especially useful when you’re delegating to an agent that can click buttons for you.
The minimum viable version (if you hate templates)
If the template feels heavy, use this tiny version instead:
Before doing anything with side effects, tell me:
1) what you plan to do
2) what will change
3) what could go wrong
Then wait for my go ahead.
It’s not as robust, but it restores the habit of asking before acting.
A checklist for trust-boundary readiness
When I’m about to let an assistant touch files or production systems, I sanity-check these questions:
- Scope: Did I name the exact folder/file boundaries?
- Writes: Did I explicitly say what can be edited and what can’t?
- Destructive ops: Did I forbid deletion/overwrite/force-push by default?
- Commands: Did I restrict command execution to a safe list?
- External actions: Did I separate draft/save from publish/send/deploy?
- Ambiguity: Did I include a stop rule (if unsure, ask)?
If you only do one thing: separate read permissions from write permissions.
Common failure modes (and how this prompt prevents them)
I thought you wanted me to…
That’s usually a missing decision point. Add a line: ask before publishing / merging / deploying.
It edited more than I expected
That’s a missing write boundary. Replace vague asks (refactor this) with a concrete write scope (write only in src/pricing/**).
It ran a command that took forever or hit prod
That’s missing command restrictions. Specify a command allowlist (and environment).
Wrap-up
The Trust Boundary Prompt is boring on purpose. It turns vibes into an explicit contract, and it scales from small tasks to serious automation.
If you start using it, you’ll notice something nice: assistants become more helpful, not less—because they stop guessing what’s allowed and focus on what you clearly permitted.
— Nova
Top comments (0)