You’ve built something that works. This is about making sure it can only do the job you built it for.
The moment your build reaches out to another system, it does so through a connector, and that connector carries permissions. The habit worth building is a simple one: give each connector exactly the access it needs to do its job, and not one power more. That’s least privilege, and it’s less a rule to memorize than a question to ask yourself every single time you connect something. What’s the smallest amount of access this actually needs?
It helps to know where 3B meets you here. 3B keeps a connector’s secrets completely out of the view of your workflows, steps, and code, and injects them into network requests only when they’re needed, so they’re only ever used where they should be and never revealed. That takes one whole category of worry, the secrets themselves leaking, largely off your plate. What 3B leaves in your hands are the decisions least privilege is really about, and there are three of them. Two live right in the connector’s settings: which URLs it’s allowed to reach, and who’s allowed to use it. The third, how much the token can actually do, you set when you create it on the service’s own side. 3B keeps the secrets safe; you decide how many doors the connector opens, and who gets to use it.
Why the smallest scope is the right default
A connector is a bundle of powers you’re handing to a build. If the build only reads records, a read-only token covers everything it needs. Set it up with one that can also delete and update, and you’ve stacked up powers the build never touches but that are now sitting there, available, if anything goes sideways: a bug, an unexpected prompt, a step that misfires. Least privilege keeps the gap between what a build can do and what it needs to do as narrow as possible, so there’s simply less to think about when something behaves in a way you didn’t plan for.
How to apply it
When you set up a connector, it’s worth walking through this before you wire it into a build:
-
Scope the token when you create it. Most services let you choose what a token can do when you generate it. Grant only the permissions the build needs, read-only if it only reads, rather than reaching for a full-access key.
-
Restrict where it can go. In the connector’s settings, set the allowed URL pattern so it can only ever be sent to the service it’s meant for, and nowhere else.
-
Restrict who can use it. In the Access tab, keep the connector to just you, or the specific people and spaces that actually need it, rather than opening it up to everyone.
-
Set up, then verify. Confirm the build works on the narrow setup. If it does, you’re done. If it needs more, widen it deliberately, one step at a time.
What over-scoping costs
Broad access is tempting for a simple reason: it never gets in your way. Set up a connector with full permissions once and you’ll never see an access error again, which feels like a win right up until it isn’t. The catch is that a connector that can do anything can also do anything by mistake, whether the cause is a bug, a stray prompt, or a step firing when it shouldn’t. So when a narrow setup occasionally stops you to ask for one more permission, that’s not the tool being difficult. It’s doing exactly what you told it to.
Scoping well costs you a few extra minutes when you set a connector up. It’s some of the highest-return time you’ll spend, because the alternative is finding out the true cost of broad access at the worst imaginable moment.
Next up: Understanding blast radius, a way to think through what could actually happen if a connector is misused.