You’ve got the principle and the mental models. This is least privilege applied to the kinds of tasks you’ll build.
Least privilege is one of those principles everyone nods along to and then promptly skips when they’re mid-build and just want the thing to work. The way to make it stick is to carry a default for the common cases, so scoping becomes a quick match instead of a fresh decision every time. The rule underneath all of them is the same: match the connector’s scope to the task’s scope, and no wider.
Read tasks get read access
If a build only pulls data (fetching records, reading a channel, checking a status) it needs read access and nothing more. This is the single most common place broad connectors sneak in, because a full-access token reads perfectly well and never once throws an error to tip you off. A read-only connector does the exact same job with none of the extra reach, which makes it the right default any time a build isn’t changing anything.
Single-project work gets single-project scope
When a build only touches one project, one repository, or one channel, scope its connector to that one thing rather than the whole account. A build that manages one project’s requests has no need to reach into every other project. Narrowing it to the specific resource means a mistake, or a misuse, stays boxed into the one place the build was ever meant to operate in.
Write and delete tasks get narrow, deliberate scope
Builds that change or remove data need write access, and that’s exactly where scope matters most. Grant the specific write the task requires, to the specific place it works, and nothing beyond that. A build that adds requests to a list needs to add requests; it doesn’t need to delete them. Keeping those separate stops an “add” task from ever accidentally sliding into a “delete”.
When a task spans systems, scope each one on its own
A build that reads from one service and writes to another needs a connector for each, and each should be scoped to its own half of the job: read-only on the source, narrow write on the destination. Scoping them independently keeps one connector’s reach from creeping into the other’s.
Worth keeping in mind as you go: 3B’s guardrails (keeping connector secrets out of your builds and running each one in isolation) limit how far a mistake can travel, but they don’t decide how much access a task should have in the first place. That decision is the one sitting in front of you every time you connect something, and matching scope to task is how you make those guardrails count. Look at what the task does, grant exactly that, and let anything it doesn’t need stay well out of reach. Do it enough times and it stops being a step you remember to take and just becomes the way you build.
Scoping, blast radius, and risky prompts all come back to the same instinct: give a build what its job needs and no more. It’s the last habit in a chain that starts well before the build does, with knowing exactly what you’re building. If that part ever feels shaky, Your first prompt matters most is a good place to start again.