A Practical Guide to Scoped Settings for AI

Tuesday morning, a founder asks an AI coworker in Slack to process a $400 refund for a churned customer. The coworker reaches Stripe, completes the refund, then updates the customer in HubSpot to Closed Lost and reassigns the deal owner.

Nobody hacked the account. Every API call was authenticated. The problem was that the AI had permission to do more than the task required.

A finance record changed, the CRM pipeline was rewritten, and a sales rep lost visibility into a renewal conversation. The useful question isn't only whether the coworker had access. It's which actions it was authorized to take, for which user, against which resource, and for how long.

That's the purpose of scoped settings. They draw a practical line between what an AI coworker may read, what it may change, and what requires a human decision before anything destructive happens.

Table of Contents

• The Moment Scoping Actually Matters
  • The three questions to ask before granting access
• What Scoped Settings Actually Are
  • A bounded rectangle, not a master key
• Per-User, Team, and App-Level Scopes Compared
  • Choosing the owner deliberately
• Common Scopes Inside Supercenter
  • Data access is not action access
  • Connector identity changes the risk
• Binding Scopes to the Task, Not the App
  • Split retrieve from act
  • Add time and elevation
• Why Static Scopes Quietly Fail
  • Three failure modes to watch
• A Founder's Scoping Checklist for AI Coworkers
  • Start narrow
  • Log every meaningful action
  • Review and revoke

The Moment Scoping Actually Matters

The refund request sounds simple because the human intent is simple. “Refund this customer” appears to describe one action, but an AI coworker often needs to retrieve customer details, inspect payment history, identify the relevant subscription, issue the refund, and possibly update internal records.

Those steps touch different systems and carry different consequences. Reading a Stripe receipt isn't equivalent to issuing a refund. Finding a HubSpot contact isn't equivalent to changing the lifecycle stage, moving ownership, or merging records.

Practical rule: If a task crosses tools, scope each action separately. Don't let one broad connector permission stand in for the whole workflow.

The failure becomes easier to see when you separate authentication from authorization. Authentication proves that the request came through a recognized identity. Authorization decides what that identity may do. In the Tuesday morning example, the AI was authenticated correctly, but its authorization boundary included unrelated CRM mutations.

That distinction matters because broad permissions create blast radius. A coworker that can read support history, update CRM records, send external email, and modify payments may complete a task successfully while also making changes nobody intended.

The three questions to ask before granting access

For every AI action, ask:

• What data must it retrieve? A refund workflow may need the customer record, invoice, and payment status.
• What may it change? Issuing a refund is materially different from adding an internal note.
• What needs approval? Financial changes, external messages, deletions, and ownership changes deserve a deliberate confirmation step.

OAuth 2.0 formalized scoped access in 2012, defining scopes as a way for third-party applications to obtain limited access to an HTTP service instead of full account control. Scopes are requested as space-delimited strings during authorization and enforced by the resource server before serving requests, as documented in the OAuth scope specification.

The rest of the problem is operational. You need to bind those permissions to the task, the requesting person, the relevant resource, and a limited time window. Without those boundaries, “the AI can process refunds” can become “the AI can manage everything connected to the finance and revenue stack.”

What Scoped Settings Actually Are

A scope is easiest to understand as a bounded permission. It answers what an actor can do, not merely who that actor is. “Read contacts” is a capability. “Frida,” “the finance team,” or “the workspace integration” describes the owner or identity attached to that capability.

Four attributes make the model concrete.

First, capability. A permission should name an operation, such as reading a contact, drafting a message, creating a ticket, or issuing a refund. OAuth providers use this model broadly. Microsoft describes scopes as permission sets, while GitHub explains that scopes limit OAuth token access. GitHub's special (no scope) value grants only read-only access to public information, illustrating how the permission set itself defines the boundary.

Second, owner. Every grant needs an accountable owner. That owner may be a person, a team, or an application. If an AI acts on behalf of a person, that person's authority should constrain the action. If a shared support workflow owns the permission, the team must own its review and revocation.

Third, resource. “Read” isn't a universal permission. It should attach to a defined resource, such as HubSpot contacts, Stripe invoices, a specific Gmail inbox, or a particular project. Microsoft Azure RBAC defines scope as the set of resources to which access applies, which makes the boundary explicit rather than implied.

Fourth, time. A grant should have a useful lifetime. A permission issued to complete one refund shouldn't remain valid indefinitely. Short-lived access, automatic revocation, and renewed consent keep a completed task from becoming permanent delegated authority. Guidance on governing least privilege across SaaS, cloud, and non-human identities emphasizes this shift toward time-bounded access and continuous re-evaluation.

A bounded rectangle, not a master key

Full account access gives an integration a large trust perimeter. One administrator token may reach every record, endpoint, and operation available to the account. Scoped settings create a labeled rectangle inside that perimeter, for example:

• Actor: the requesting support manager
• Capability: read customer and ticket history
• Resource: the assigned support workspace
• Time: the current task window
• Approval: required before external communication or financial changes

That structure makes audit records easier to interpret. Instead of seeing that “the AI used Stripe,” you can determine which user authorized the action, which capability was granted, which resource was touched, and whether the action was read-only or mutating.

For a practical OAuth walkthrough, see OAuth examples for connected applications. The important lesson is simple: scoping doesn't remove useful access. It removes access that the task never needed.

Per-User, Team, and App-Level Scopes Compared

The owner of a scope determines accountability and suitability. A per-user grant follows one person. A team grant represents shared operational authority. An app-level grant belongs to the workspace or integration itself.

Dimension	Per-User Scope	Team Scope	App-Level Scope
Accountability	One named person owns the delegated action	A defined team owns the permission	The workspace or application owner is accountable
When someone leaves	Revoke that person's grant	Review team membership and shared access	Review the integration independently of employee accounts
Auditability	Strong connection between requester and action	Useful for shared workflows, but requires clear team ownership	Requires careful logs because no individual may be the obvious operator
Best suited for	Personal delegation and user-specific work	Shared queues, support pods, and team processes	Non-sensitive infrastructure and shared reporting
Supercenter-style example	An executive assistant drafts replies from the executive's mailbox	A support coworker updates tickets assigned to the support team	A workspace integration posts status updates to a shared channel

A per-user scope is the safest starting point when an AI coworker acts as someone's delegate. An executive assistant may read the requesting executive's calendar and draft mailbox replies, but it shouldn't inherit another employee's private messages merely because both accounts exist in the same workspace.

Team scopes make sense when the work belongs to a group. A support team's coworker may need to read and update tickets across the team's queue. That authority shouldn't depend on one agent's personal mailbox, because the process must continue when team membership changes.

App-level scopes are different. They support capabilities that no individual should personally own, such as reading aggregate usage analytics or posting to a dedicated status channel. Treat them as shared infrastructure, not a convenient shortcut around user accountability.

Choosing the owner deliberately

A useful rule is to start per-user, move to team scope only when the workflow belongs to the group, and reserve app-level scope for non-sensitive shared functions. Feature flags offer a comparable governance lesson: teams need ownership, review, change records, and rollback rather than an unexamined collection of permanent switches. The feature flag governance best practices resource is useful when designing that operational discipline.

For each scope, write down who approves it, who reviews it, and what happens when the owner changes. If those answers are unclear, the grant is probably too broad or attached to the wrong identity.

Common Scopes Inside Supercenter

A Slack thread can contain several different permission decisions, even when the request looks like one sentence. A support manager might write, “Summarize this customer's history and draft a reply.” The AI needs to retrieve records, interpret them, and prepare text. It doesn't automatically need permission to send the reply, alter the customer's status, or delete a duplicate ticket.

Data access is not action access

Read-only CRM access lets a coworker inspect a contact, deal, or ticket. Read/write access lets it change those records. That difference is easy to miss when a connector setup screen presents a single broad permission group.

Suppose the coworker reads HubSpot to summarize a renewal conversation. If update permission is also granted, a later instruction could cause it to change the lifecycle stage or reassign the deal owner. The summary still looks correct in Slack, but the system of record has changed underneath the sales team.

Action capabilities deserve their own boundaries:

• Draft message: prepare content without sending it.
• Send message: deliver content to an internal or external recipient.
• Create record: add a ticket, contact, invoice, or task.
• Update record: modify an existing object or field.
• Delete record: remove data or trigger downstream deletion behavior.

Delete permissions should rarely be available for unprompted AI work. A coworker can identify likely duplicates and present them for review without receiving permission to erase records.

Connector identity changes the risk

A Gmail connector scoped to a shared support inbox is not equivalent to one scoped to a finance alias. The connected identity determines whose messages the coworker can retrieve and which identity appears to send them.

The same principle applies to Stripe, Salesforce, Google Drive, Linear, and custom business systems. Always inspect the connector identity and the resource boundary together. “Gmail access” is too vague to approve.

Scope Category	Example Scope	What It Allows	Risk If Over-Granted	Typical Scenario
Data	Read HubSpot contacts	View customer profile fields	Sensitive customer data becomes broadly visible	Build a renewal summary
Data	Update support tickets	Change status, assignment, or notes	Workflow ownership changes silently	Route a ticket after approval
Action	Draft message	Prepare a response without delivery	Usually limited, though drafts can contain sensitive content	Create a reply for review
Action	Send external email	Deliver a message outside the company	An incorrect or unauthorized message reaches a customer	Send an approved refund explanation
Connector identity	Shared support Gmail	Work from a defined inbox	Messages or replies use the wrong organizational identity	Respond to a support thread
Scope tag	support-tier	Bundle approved support permissions	A tag can widen access if assigned carelessly	Delegate ticket work to a support group

Scope tags make bundles manageable, but they don't make them safe by default. Microsoft Intune documents scope tags as a way to filter permission checks within a defined tag context, allowing administrative reach to be separated by region, business unit, or device group. Use the same discipline for AI work: name tags after an operational boundary and review what each tag contains.

Binding Scopes to the Task, Not the App

The most useful mental shift is this: the application isn't the right boundary for AI permissions. The task is.

An AI coworker may use Stripe for several unrelated jobs. Pulling a refund receipt requires retrieval. Issuing the refund creates a financial side effect. Those actions may use the same application, but they should not share the same authority.

Split retrieve from act

Retrieval usually helps the AI understand context without changing the source system. A coworker can read a HubSpot contact, inspect ticket history, and search relevant documents to prepare an answer. Acting requires a narrower grant tied to the current task, resource, and operation.

Use this split in configuration:

1. Grant retrieval needed for context. Allow the coworker to find the customer, ticket, or document relevant to the request.
2. Keep mutations separate. Treat refund, send, update, merge, and delete as distinct capabilities.
3. Limit the target. A permission to update one ticket or one invoice is safer than permission to update every object in the workspace.
4. Require fresh approval for high-impact actions. Don't turn a standing read grant into standing financial or external-send authority.

The same logic applies to AI coding environments. Teams evaluating prompt context controls for coding AI should separate the context an assistant can inspect from the changes it can commit, merge, or deploy.

A Supercenter-style on-behalf-of model applies the requesting user's permissions to low-risk retrieval, then asks for a narrower action-level grant when the task crosses into a side effect. That approach keeps the coworker from reaching resources the requester couldn't reach while still allowing the AI to complete work across connected tools. You can explore the broader model in context-aware AI workflows.

Add time and elevation

A token for “process this refund” should exist only for the active task window, not as a permanent invitation to issue refunds. Just-in-time elevation creates a better approval moment: the coworker presents the proposed action, the human confirms it, and the system issues a short-lived permission limited to that operation.

The approval prompt should identify the target, operation, and consequence. “Issue refund to this customer in Stripe” is reviewable. “Grant finance access” is too broad to be meaningful.

<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/-pwsCYtnOk4" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

Why Static Scopes Quietly Fail

A scope that never expires, never gets recertified, and never appears in a per-action log becomes permanent delegated authority. The label may still say “limited,” but the practical permission has expanded as the business, connectors, records, and team membership changed around it.

That's why onboarding is only the beginning. A founder may approve read access for a support workflow, then add write access to solve an urgent routing problem. Later, someone connects a new CRM object or promotes the coworker during an incident. Each change seems reasonable in isolation. Together, they create an access pattern nobody deliberately designed.

Three failure modes to watch

Scope creep starts when new connectors or capabilities get added without reviewing existing grants. The original task might have required ticket access, but the coworker now also sees revenue records because the connector's permission bundle grew.

Zombie scopes remain attached to people, tokens, or service identities after the original relationship ends. A former employee's delegated access may continue to validate unless the team revokes it explicitly.

Privilege inheritance appears during emergencies. A workspace owner promotes an AI to administrator to resolve an incident, then forgets to restore the narrower role. The exceptional permission becomes the new baseline.

Palantir's documentation shows why visibility boundaries deserve the same attention as action boundaries. Its automation history supports project scope, user-scoped mode, and shared trigger history. In user-scoped mode, only the owner can access run history, while project scope makes history visible to users who satisfy the markings on a run. Scope therefore governs not only what an automation does, but who can inspect what happened.

Microsoft Azure RBAC also treats scope as a resource boundary and documents retention of activity logs for RBAC changes over the past 90 days. The operational lesson is clear: access changes need an audit trail that helps a reviewer reconstruct who changed the boundary and what resources it covered.

A scope is only as trustworthy as its expiration, review, and evidence.

Treat scopes like credentials. Rotate them, review them, revoke them, and record the reason for each privileged action. The objective isn't to create an impressive number of permission labels. It's to create short-lived, observable permissions that follow the task.

A Founder's Scoping Checklist for AI Coworkers

A founder can establish a sensible baseline without designing a full enterprise identity program. Start with permissions that let the coworker understand work and prepare outputs, then delay anything that changes money, ownership, records, or external communication.

Start narrow

At launch, give the coworker only the access needed to retrieve context and draft work:

• Read CRM contacts: View customer profiles without changing lifecycle stages or ownership.
• Read ticket history: Inspect prior support interactions and current status.
• Draft messages: Create replies for a human to review, without sending them.
• Suggest tags: Propose categories or routing labels without applying them automatically.
• Require approval: Ask a human to confirm any external action or destructive change.

Defer permissions such as creating invoices, closing deals, deleting records, and sending external email until the workflow has earned them through observed use. A Shopify team considering AI-assisted merchandising can apply the same boundary to an app for Shopify SEO: let the assistant inspect product context and prepare recommendations before granting permission to publish or alter the catalog.

Log every meaningful action

Your audit record should let a reviewer answer five questions without guessing:

1. Actor: Which person, team, or application initiated the request?
2. Scope: Which capability was active?
3. Target resource: Which customer, ticket, invoice, message, or project was touched?
4. Before and after state: What changed, represented with a before/after hash or equivalent integrity record?
5. Timestamp: When did the action occur?

Keep read and write events distinguishable. A log that says “AI accessed HubSpot” doesn't tell you whether it viewed a contact or changed a deal owner.

Review and revoke

Create a recurring review meeting and pull the full list of granted scopes. Ask whether the last 90 days justified each permission, using the Azure RBAC activity-log documentation as a reference for why access changes need durable evidence. Revoke unused grants, remove departed users, and inspect every scope tag after team membership changes.

Set one rule that doesn't bend: destructive or external actions require explicit human confirmation even when the technical permission exists. Never give a personal account token to a shared workspace, rotate connector credentials when people leave, and treat any scope touching payments as a red-zone permission until someone reviews it.

For a broader implementation view, see AI access control for connected work. The right configuration is not the one with the fewest clicks. It's the one that makes every allowed action understandable, bounded, and reversible.

---

Supercenter provides AI coworkers that work inside Slack and Microsoft Teams, connect to business tools through OAuth, act on behalf of the requesting teammate, and keep actions in a replayable audit trail. Visit Supercenter to see how task-level delegation, revocable permissions, and approval boundaries can fit into your team's day-to-day workflows.