Least privilege for an AI-built app is granting it only the actions and data its job needs, and knowing whose account each of those actions spends before anyone else can run it.
Security reviews of an internal app usually start with who can open it. For an app that only displays numbers, that is most of the review. For an app with a button that creates a Salesforce record or posts to Slack, it is the smaller half.
The larger half is whose account the button uses. In Insulin the app’s ownership decides that, not whoever clicks, so every tier you grant a shared app is lent to everyone who can run it. How the builder writes and safety-checks the app itself is covered in building an internal dashboard with AI, no code.
Whose account does an AI-built app act as?
The account at the level that owns the app, never the account of whoever is running it. An organization app’s Salesforce and Slack calls resolve to the organization’s connected accounts; a personal app’s resolve to its owner’s.
A teammate you shared an organization app with at User therefore creates records through the organization’s Salesforce connection, and they land in Salesforce as that account, not as the teammate.
There is no fallback to the person running the app. If the organization has not connected an integration, the action fails with an “integration not connected” error instead of reaching for the runner’s own connection, which would change which Slack workspace an organization app posts into. That is the right failure: an app whose destination depends on who clicked cannot be reviewed once and trusted after.
Two things follow. Reads resolve the same way, so before sharing even a read-only app widely, decide whether everyone who can run it should see what the organization’s connection can query. And personal apps are the easy case: private to their creator and unshareable, so the runner and the account are the same person.
Agents follow the same shape, since an organization-level agent can use organization-level integrations only; see restricting which integrations an AI agent can access.
What can an AI-built app call at all?
From your connected systems, only Salesforce and Slack actions, and only in the tiers you tick. Anything else your organization has connected is used by agents and other surfaces, not by a Custom App.
A sensitivity tier is a class of actions within an integration: read reads data from the connected system, write creates or updates data in it, and outbound sends data or triggers outbound actions. The empty case does not mean what it looks like:
| The app’s configuration for an integration | What the app can call |
|---|---|
| Not in the list at all | Nothing, and the integration is dropped from the builder’s prompt too |
| In the list, with one or more tiers | Only the actions in those tiers |
| In the list, with no tier ticked | Nothing: an empty tier list grants no methods |
A newly added integration starts in that last row: no tier is ticked until you choose one, and saved that way it reaches nothing. The old reading, where empty meant “all”, was retired; apps saved under it were backfilled to the tiers they were actually using, so none lost access.
The grant worksheet
Tick the actions the app really calls, then grant the tiers of the ticked rows. In a personal app, every row runs on the owner’s own connection instead.
| Integration | Action | Tier | Runs as (organization app) | Needed? |
|---|---|---|---|---|
| Salesforce | Query many records | read | The organization’s connection | ☐ |
| Salesforce | Query one record | read | The organization’s connection | ☐ |
| Salesforce | Create a record | write | The organization’s connection | ☐ |
| Salesforce | Upload a document | write | The organization’s connection | ☐ |
| Slack | List channels | read | The organization’s connection | ☐ |
| Slack | Send a message to a channel | outbound | The organization’s connection | ☐ |
| Slack | Send a message to users | outbound | The organization’s connection | ☐ |
You grant tiers, not individual actions. Ticking write on Salesforce makes both Create a record and Upload a document callable, and ticking outbound on Slack enables both send actions. A read-only grant lets the app query Salesforce and list Slack channels, and neither create a record nor send a message.
Where the tier list is enforced
At runtime the tier list is absolute: an action in any other tier is not in the app’s runtime action list, and because the sandbox has no network access of its own, every fetch goes through a server procedure where grants are checked. The builder’s prompt is narrowed only for actions that carry a tier, so an untagged action could still be described to the builder, though never called. Every action Suger publishes carries a tier. Changing integrations on an organization app also requires organization administrator access on top of the app role.
What Suger data can an app read?
Read-only data, and only the namespaces you leave in scope. An app reads your Suger data (cloud-marketplace offers, buyers, entitlements, products, operations, analytics, org currencies and revenue records) through a fixed list of 11 read operations, none of which writes. One further operation lets it ask the model for an inference.
First-party data scope is the save-dialog setting that decides which of those namespaces an app may read; the browser bridge and the server host both enforce it. Unlike tiers, it starts open: an app reaches every first-party namespace unless you narrow it. Legacy: full access reads them all; Narrow reads only the ones you check, and checking none grants nothing.
| Namespace | What the app can read | In scope? |
|---|---|---|
offers | List offers, and fetch one by id | ☐ |
buyers | List buyers, and fetch one by id | ☐ |
entitlements | List entitlements, and fetch one by id | ☐ |
products | List products | ☐ |
operations | List operations | ☐ |
revenue | List revenue records | ☐ |
analytics | Run an analytics query, and list the organization’s currencies | ☐ |
ai | Ask the model for an inference, the one namespace that is not cloud-marketplace data | ☐ |
Apps saved before per-app data scope shipped stay on Legacy: full access until someone narrows them, so start there.
What does sharing an app hand over?
The use of its accounts, if it holds write or outbound grants. Sharing settles who can open an app, not whose credentials it spends once open: anyone who can run a shared organization app, User included, acts through the organization’s accounts.
Insulin flags it. Open an app you do not own that holds a write or outbound grant, and the run panel shows a banner naming whose accounts its actions run on and which integrations they reach. Read-only apps show no banner, which keeps the banner worth reading. Choosing roles, from view-only Viewer up to Owner, is covered in sharing an internal app with roles.
Before you share a write or outbound app
- Name the accounts the organization has connected for Salesforce and Slack; every record and message the app creates lands as them.
- Tick the fewest tiers. Each ticked tier grants every action in it.
- Remove integrations the app does not call, which also drops them from the builder’s prompt.
- Narrow the data scope to the namespaces the app reads.
- Grant Editor as if it were the tiers. An Editor can change the app’s code, and that code can call any action in the tiers the app holds. Everyone who only runs the app gets User.
Then have a teammate who does not own the app open it: the banner should name exactly the accounts and integrations you expect.
Frequently asked questions
Whose account does an AI-built app use?
The account at the level that owns the app. An organization app uses the organization’s connected Salesforce and Slack accounts, and a personal app uses its owner’s. It never uses the account of the person running it.
What happens if the organization has not connected the integration?
The action fails with an error saying the integration is not connected. The app does not fall back to the runner’s own connection, which would change which Slack workspace an organization app posts into.
Does an integration with no tier ticked grant everything?
No. An empty tier list grants nothing. A newly added integration starts with no tier ticked and reaches nothing until you tick the tiers its actions need. Apps saved under the old reading were moved to the tiers they were actually using.
Which integrations can an AI-built app call?
Two: Salesforce and Slack. Salesforce offers read and write actions, and Slack offers read and outbound actions. Other systems your organization has connected are used by agents and other surfaces, not by a Custom App.
Can an AI-built app change my Suger data?
No. An app reads Suger data through 11 read operations, and none of them writes. First-party data scope can narrow which namespaces a given app may read, and checking none grants nothing.
Takeaways
- Salesforce and Slack calls run on the account at the level that owns the app, never the runner’s, with no fallback.
- A newly added integration starts with no tier ticked, and an empty tier list grants nothing.
- You grant tiers, not actions, and each ticked tier enables every action in it.
- Suger data is read-only to an app; First-party data scope narrows it, and older apps sit on Legacy: full access until narrowed.
- Sharing a write or outbound app lends out the organization’s accounts.
Every grant above is set where the app is built. See what AI-built Custom Apps in Insulin can do with the narrowest grant that still does the job.
Sources
Primary sources for the platform rules cited above. Last verified September 19, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Custom Apps — Whose accounts an app's actions use (the level that owns the app, never the runner, no fallback, the write/outbound banner); the read, write and outbound tiers and what an empty tier list grants; the seven Salesforce and Slack actions; the 11 read operations; First-party data scope, its namespaces and its two positions; the sharing roles
- Suger Insulin docs: Getting Started — Roles and Permissions — Organization-level agents can use organization-level integrations only; organization-level Custom App integration changes require organization administrator privileges
Keep reading
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.