Recognizing risky prompts

Scope limits what a build can do. This is about noticing, in the moment, when you’re asking it to do something bigger than you meant.


Most risky prompts don’t look risky. They look like perfectly ordinary requests with one small phrase that accidentally widens their reach past what you had in mind. Learning to catch that phrase before you hit send is skill worth having, because reconsidering a prompt is a great deal easier than undoing what it set in motion.

Watch for words that scale

The clearest tell is language that turns a specific action into a sweeping one. “Delete the test records” is bounded. “Clean up the records” is not, and now 3B has to guess what “clean up” includes. Words like all, every, clean up, reset, and sync everything can widen a task’s footprint before you’ve noticed it happening. When one turns up in your prompt, it’s worth a beat to ask whether you mean it literally, because 3B will take you at your word.

Notice irreversible actions

Some actions simply can’t be walked back: deleting, overwriting, emailing people, changing production data. These earn a second read before you send, because the cost of getting them wrong is permanent. A handy instinct: if an action can’t be undone, spell out exactly what it should touch and, just as importantly, what it shouldn’t.

  • Risky: “Remove the old entries.” (Which ones? Says who? How far back?)
  • Clearer: “Delete entries flagged as test and created before January 1. Leave everything else alone.”

Match the ask to the scope

A prompt is also risky when it asks for more than the build’s job calls for. If a build exists to read and summarize, a prompt that tells it to update records is a mismatch you should catch, and a good moment to ask whether the task actually changed or the prompt just drifted. When the ask and the scope line up, even a broad-sounding instruction can’t do much harm, which is exactly why scoping and prompting back each other up.

3B remembers, but you decide

3B does give you a safety net here: 3B keeps a record of where your connectors get used, so a prompt that reached further than you intended leaves a trail you can follow and trace back. That’s useful when you need to understand what happened, but it works after the fact. The record tells you where a prompt went wide; it doesn’t stop the prompt from going there in the first place. Catching the over-broad instruction before you send it is still cheaper than reading back through a log to find where things went sideways.

So the habit is a short pause on anything that deletes, overwrites, or reaches broadly: read the prompt back and check it says what you mean, and nothing wider. That half-second is usually all it takes.


What’s next: Scoping for different use cases, what least privilege looks like when you apply it to everyday tasks.

1 Like