In Insulin you scope an agent by allowlisting the integrations it may use. That allowlist is the boundary: an agent — and any job built on it — can only touch the connected systems you grant, and cannot reach data outside its job.
An agent that can answer questions is useful. An agent that can act — update a record, send a message, move money — is useful and consequential, because now the question is not only “what does it know” but “what can it reach.”
The document side of that question has its own answer: which agents see which documents is about knowledge bases. This post is about the other half — the connected systems an agent can operate, not the files it can read. That boundary is the integration allowlist, and it is the single most important thing to get right before you let an agent do anything on your behalf.
What scoping an agent to its integrations means
Scoping an agent to its integrations means granting it access only to the connected systems its job requires, so it cannot reach anything else. The Insulin agents page states the rule directly: “Grant access only to the connected systems the agent needs. Scope is the boundary, so an agent cannot reach data outside its job.”
Read that as a boundary, not a preference. An agent does not have access to every integration your organization has connected. It has access to the ones you selected for it when you configured it — you allowlist the integrations it may use, and everything you did not add is unreachable.
The practical effect: a deal-desk agent you scoped to your CRM and offer systems cannot touch billing, cannot touch your data warehouse, cannot open a support queue — not because you told it not to, but because those tools are not on its list. There is nothing for it to call.
Why the allowlist is a safety boundary, not a convenience
The allowlist is a safety boundary because it constrains what is possible, not merely what is instructed. A system prompt telling an agent to stay in its lane is guidance; it can be misread, argued around, or defeated by a cleverly worded request. An integration it was never granted is simply absent from what it can do.
That distinction matters most when the agent runs without you watching. An interactive answer gets read by a person who might notice something is off. But the same agent can be handed to a scheduled or event-driven job that fires unattended, and a job inherits the agent’s scope. Whatever the agent could reach, the job can reach — at 4 a.m., with no one in the loop.
So the allowlist is doing double duty. It bounds the interactive agent, and it bounds every job built on that agent, in exactly the same way. Scope the agent narrowly and you have scoped every automation you will ever build on it. Scope it broadly “to be safe,” and you have widened the blast radius of every unattended run at the same time.
The rule of thumb is the one you would apply to a new hire’s system access: grant the narrowest set that lets the work happen, and add the next integration only when a real task needs it.
User-level and org-level scope
Insulin narrows integration access a second way, by ownership level. A user-level agent uses only the user-level integrations selected for it — the connections that belong to you. An org-level agent can use org-level integrations only; it cannot borrow a personal connection from whoever happens to run it.
That second constraint is easy to overlook and worth stating plainly: an organization agent is scoped to organization connections, so its behavior does not change depending on who is chatting with it. A shared agent that quietly picked up each user’s personal integrations would be unpredictable by design — the same request would reach different systems for different people. Scoping org agents to org integrations is what keeps a shared agent’s reach stable no matter who invokes it.
Agents can tell you what they can reach
An agent can introspect its own access before it acts. As of a July 2026 changelog entry, Insulin added integration-introspection tools, so an agent can list the integrations available to it, inspect one, and check its connection before acting — and the docs note that “an agent can inspect the connections it has been given, so you can ask about them in plain language.”
This turns scope from something you have to remember into something you can simply ask about. Before trusting an agent with a job, ask it what it can reach. It will tell you the integrations on its list, and it can check whether each connection is live rather than merely configured — the difference between “not connected” and “connected but failing.” So when an agent says it cannot do something, you can ask why, and get a straight answer: the integration is not on its allowlist, or it is on the list but the connection is down.
That introspection is also how you verify a scope without leaving chat. You do not have to open a settings panel to confirm a finance agent cannot see your CRM. You ask it, and a correctly scoped agent will tell you the CRM is not among its integrations.
How to scope an agent in practice
Do it in this order, and the boundary stays tight:
- Start from the job, not the tool list. Write down the one task the agent owns before you grant anything. The task determines the integrations; the integrations do not determine the task.
- Grant the minimum, then stop. Add only the connected systems that task needs. Resist adding a system “in case it comes up later” — later, a real task will tell you, and you can add it then.
- Prefer org scope for shared agents, user scope for personal ones. A shared agent should run on org-level integrations so its reach does not change per user. A personal agent uses your own connections.
- Verify by asking. Once configured, ask the agent to list its integrations. Confirm the sensitive systems you meant to exclude are genuinely absent, not merely un-mentioned.
- Re-check before you automate. A job runs with the agent’s scope, unattended. Before you put an agent on a schedule, confirm its allowlist is the reach you are comfortable running with nobody watching.
Scope is not a one-time setup. It is the thing to re-open every time the agent’s job grows — because the moment the job grows is the moment someone is tempted to grant “just one more” integration without asking whether the job actually needs it.
Frequently asked questions
How do I restrict which integrations an AI agent can access? When you configure an Insulin agent, you allowlist the integrations it may use. It can reach only the connected systems you select; everything you do not add is unreachable, so the agent cannot touch data outside its job.
Does an agent get access to every integration my organization has connected? No. An agent uses only the integrations selected for it. Access is an allowlist, not a default. A system your organization connected but did not grant to the agent is simply not available to it.
Does a job inherit the agent’s integration scope? Yes. A job runs with the agent’s scope, so whatever the agent can reach, an unattended run of it can reach too. Scope the agent narrowly before you put it on a schedule.
What is the difference between user-level and org-level integration scope? A user-level agent uses your own user-level integrations. An org-level agent can use org-level integrations only, so a shared agent’s reach stays the same no matter who invokes it.
Can an agent tell me which integrations it can access? Yes. An agent can inspect the connections it has been given, list the integrations available to it, and check whether each connection is live before acting — so you can confirm its scope by asking in plain language.
Takeaways
- Scoping an agent to its integrations means granting access only to the connected systems its job needs — the allowlist is the boundary, and everything off it is unreachable.
- The allowlist constrains what is possible, not just what is instructed, which is why it holds even when an agent runs unattended.
- A job inherits the agent’s scope, so scoping the agent narrowly scopes every automation built on it.
- Org-level agents use org-level integrations only, keeping a shared agent’s reach stable regardless of who invokes it.
- An agent can introspect its own access — ask it what it can reach, and verify the boundary without leaving chat.
Scope is the safety boundary that makes an agent safe to trust with real work. See how agents are scoped to the systems they need, then hand one to a scheduled job knowing its reach is already bounded, or read the Insulin agents documentation for the full integration model.
Sources
Primary sources for the platform rules cited above. Last verified August 18, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Agents — That an agent uses only the integrations selected for it, that org-level agents can use org-level integrations only, and that an agent can inspect the connections it has been given.
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.