diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx
index d78b66eb1..602cb9307 100644
--- a/src/content/docs/factories/integrations/github.mdx
+++ b/src/content/docs/factories/integrations/github.mdx
@@ -126,6 +126,35 @@ Branches and pull requests the factory creates follow the repository's normal ru
 
 Runs authenticate with the GitHub App installation. Its repositories and permissions control access; [automation filters](/factories/automations/) only control when work starts.
 
+The [Warp Factories GitHub App](https://github.com/apps/warp-factories) requests the following permissions. Repository permissions apply to the repositories covered by the installation. A run doesn't necessarily use every grant.
+
+| Repository permission | Level | Granted access and use | Boundary |
+| --- | --- | --- | --- |
+| Actions (`actions`) | Write | Read CI logs and artifacts, and manage workflow runs | Broader than receiving workflow-completion events |
+| Administration (`administration`) | Read | Inspect repository settings, collaborators, and rules | Doesn't grant permission to change repository settings |
+| Checks (`checks`) | Write | Read check results and publish factory-definition checks | Separate from commit statuses |
+| Code scanning alerts (`security_events`) | Read | Inspect code-scanning findings for security work | Doesn't grant permission to change alerts |
+| Commit statuses (`statuses`) | Read | Inspect CI status on commits | Doesn't grant permission to publish commit statuses |
+| Contents (`contents`) | Write | Read code and create branches, commits, and repository changes | Repository rules and branch protection still apply |
+| Dependabot alerts (`vulnerability_alerts`) | Read | Inspect dependency vulnerability alerts for security work | Doesn't grant permission to change alerts |
+| Issues (`issues`) | Write | Read and update issues, comments, labels, and assignments | Broader than the issues matched by a trigger |
+| Metadata (`metadata`) | Read | Read basic repository information | Required by GitHub for installed apps |
+| Pull requests (`pull_requests`) | Write | Open and update pull requests, and post reviews and review comments | Required reviews and merge rules still apply |
+| Workflows (`workflows`) | Write | Update GitHub Actions workflow files | Separate from managing workflow runs |
+
+The app also requests permissions outside the repository:
+
+| Permission | Level | Granted access and use | Boundary |
+| --- | --- | --- | --- |
+| Organization members (`members`) | Read | Read organization membership, including checking an installer's organization role | Doesn't grant permission to manage membership |
+| Account email addresses (`emails`) | Read | Read a connected user's email addresses for account identification | Requires user authorization; isn't an installation-token grant |
+
+At installation, choose **All repositories** or **Only select repositories** to control repository access. Connecting a person's GitHub account is separate from installing the app. Repository selection doesn't narrow the organization or account permissions above.
+
+For example, a filter that starts work only on `main` doesn't restrict the installation token to `main`. Repository rules, including branch protection, still apply.
+
+To narrow access or uninstall the app, manage the installation in [GitHub's installation settings](https://github.com/settings/installations). Removing a trigger stops that route into the factory; it doesn't revoke the app's credentials.
+
 See [GitHub permissions and identity](/platform/integrations/github/#permissions-and-identity) for the full credential model.
 
 ## Factory-definition pull request checks
@@ -170,5 +199,6 @@ The check runs only for factories whose [definition is managed as code](/factori
 
 ## Related pages
 
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
 * [Factory automations](/factories/automations/) - Configure event matching
 * [Factory troubleshooting](/factories/troubleshooting/#work-isnt-starting) - Diagnose events that don't start work
diff --git a/src/content/docs/factories/integrations/gitlab.mdx b/src/content/docs/factories/integrations/gitlab.mdx
index cba70e83c..1010587c2 100644
--- a/src/content/docs/factories/integrations/gitlab.mdx
+++ b/src/content/docs/factories/integrations/gitlab.mdx
@@ -20,7 +20,7 @@ When you connect a factory to GitLab, project activity starts work in your facto
 
 Warp manages GitLab access through service accounts it creates in your connected group rather than a marketplace app:
 
-* **One manager account per workspace** - Created when you connect the group and granted the Owner role on it. Warp uses it to provision factory accounts, mint their run credentials, and maintain the group webhook; its provisioning token is valid for one year.
+* **One manager account per workspace** - Created when you connect the group and granted the Owner role on it. Warp uses it to provision factory accounts, mint their run credentials, and maintain the group webhook.
 * **One bot account per factory** - Each factory gets its own service account, named from the factory's alias plus a `-warp-` suffix and a short unique ID (for example, `acme-support-warp-01k2x3y4z5`). The bot holds the Developer role on exactly the projects you select for the factory. It is the factory's identity on GitLab. Runs authenticate as the bot, and its username is the handle you mention.
 
 The connected group's webhook delivers merge request and comment events to Warp, and matching automations turn them into factory work.
@@ -92,13 +92,28 @@ The factory never merges or approves a merge request; those decisions stay with
 
 ## Permissions
 
-Runs authenticate as the factory's bot account, not as the person whose activity triggered them:
+GitLab setup uses your OAuth authorization to provision service accounts. Factory runs then use the factory bot's credentials, not your OAuth token. Token scopes and GitLab membership roles are separate controls.
 
-* **The bot's project membership decides what runs can reach.** Each run gets a short-lived token scoped to the bot's Developer role on the factory's selected projects. Selecting projects for a factory or tightening automation filters changes when work starts, not what a running agent can access. To change access, change the factory's projects.
+Warp requires `api` and `read_user` on your setup authorization. The service-account scopes and roles below are assigned during provisioning. Review GitLab's consent screen for the complete set requested by the setup application.
+
+{/* VERIFY: Confirm whether the production GitLab OAuth authorization requests scopes beyond the required api and read_user; the persisted provider scope list and authorization parameters are not available in this checkout. */}
+
+| Permission or scope | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `api` on the connecting user's OAuth grant | Full API read and write access within that user's GitLab authority | Discover groups and projects, and provision the manager account | Not limited to the projects later selected for a factory |
+| `read_user` on the OAuth grant | Read the authenticated user's profile | Identify the connected GitLab user | A profile scope, not a project role |
+| `api` on the manager token; Owner role on the connected group | Group-wide API authority under the manager's role | Provision factory accounts and their tokens, and maintain the group webhook | Broader than a factory bot's selected-project access; the provisioning token expires after one year |
+| `api` on factory bot tokens; Developer role on selected projects | API read and write access under the bot's project memberships | Read code, push branches, and create merge requests, notes, and reviews | Protected-branch and project rules still apply; token expiry is date-granular, about 24 to 48 hours after minting |
+
+GitLab's [`api` scope](https://docs.gitlab.com/integration/oauth_provider/#view-all-authorized-applications) is broader than Git operations alone.
+
+* **The bot's project membership decides what runs can reach.** Change the factory's selected projects to change that membership. A trigger's project filter only changes when work starts; it doesn't narrow a run's credentials.
 * **Anyone who can create matching activity can start work.** The commenter doesn't need to be a Warp team member. Use project, action, and base-branch filters to control what starts runs.
 
 Disconnecting GitLab from the workspace retires the manager and every factory bot it provisioned.
 
+Revoking your personal [GitLab OAuth authorization](https://docs.gitlab.com/integration/oauth_provider/#view-all-authorized-applications) is separate from retiring those service accounts. Review both the connection and service-account access when withdrawing approval.
+
 ## Definitions as code
 
 If the factory's [definition is managed as code](/factories/factory-as-code/), declare GitLab triggers in an automation file:
@@ -142,4 +157,7 @@ Confirm the target project is one of the factory's selected projects and the ope
 
 Only top-level groups you own appear, and a group already connected to another Warp workspace can't be connected again. If you don't own the group, ask an owner to establish the connection in Warp.
 
-For the other ways to route work into a factory, see [Connect your factory](/factories/connect-your-factory/).
+## Related pages
+
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
+* [Connect your factory](/factories/connect-your-factory/)
diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx
index e069a2d90..983b266ac 100644
--- a/src/content/docs/factories/integrations/jira.mdx
+++ b/src/content/docs/factories/integrations/jira.mdx
@@ -81,6 +81,21 @@ When the run finishes, the result appears in the agent session. The agent doesn'
 
 ## Permissions
 
+Jira requests Forge scopes at installation, separately from linking your account to Warp.
+
+The [Warp Marketplace listing](https://marketplace.atlassian.com/apps/2476990014/warp?hosting=cloud&tab=privacy-and-security) declares the following permissions. A site's installed app version and Jira access rules determine its effective access.
+
+| Scope | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `read:jira-work` | Read project and issue data, including associated objects | Read work item context, comments, and workflow information | Declared for offline user impersonation; the user's Jira access still applies |
+| `read:jira-user` | Read accessible user profiles, including email addresses and avatars | Identify users and retrieve user context | Declared for offline user impersonation; not permission to manage users |
+| `write:jira-work` | Create, edit, and delete issues, post comments, and create worklogs | Update work items, comments, labels, assignments, and status | The provider grant is broader than the actions described for a run |
+| `read:permission:jira` | Read Jira permissions | Check the requesting user's project and issue permissions before writes | Doesn't grant the permissions being inspected |
+| `read:app-system-token` | Let Forge supply an app system token to the remote backend | Make Jira calls as the app bot | Separate from a human user's token |
+| `read:app-user-token` | Let Forge supply the viewing user's token to the remote backend | Verify the account being linked during setup | Separate from site-wide app installation |
+
+[Jira scopes](https://developer.atlassian.com/platform/forge/manifest-reference/scopes-product-jira/) don't override Jira permissions or issue-security rules.
+
 * **A connected Jira user becomes the run's creator, not its agent** - [Connect your Jira account to Warp](/platform/integrations/jira/#connecting-your-jira-account-to-warp) so a session you start is attributed to you; an unconnected account gets a prompt to connect instead of a run starting. Either way, the run executes as the agent selected by the automation, not as that Jira user.
 * **Jira access doesn't include code access** - Connecting Jira lets agents read and update Jira work items, nothing more. Repository access comes from the factory itself.
 
@@ -88,6 +103,8 @@ When the run finishes, the result appears in the agent session. The agent doesn'
 Warp's built-in Jira tools read Jira as the person who created the run; that person must link their Atlassian account to Warp in Jira under **profile** > **Personal settings** > **Warp**. To interact with Jira in runs without a human creator, such as scheduled runs or runs created by a service account or API key, add the Atlassian MCP server as a [managed MCP install](/platform/mcp/) instead.
 :::
 
+To withdraw the app's site access, a site admin manages or uninstalls it in [Atlassian's connected-app administration](https://support.atlassian.com/organization-administration/docs/managing-an-installed-app/). Removing a factory automation or unlinking a personal account is not the same as uninstalling the Jira app.
+
 ## Troubleshooting
 
 * **Warp is unavailable in Jira** - Confirm the Warp app is installed on the Jira Cloud site. On the app's **Configure** page, click **Connect to Warp** if the installation isn't connected to a workspace. If someone else is completing setup, confirm that their setup link is still active.
@@ -98,5 +115,6 @@ Warp's built-in Jira tools read Jira as the person who created the run; that per
 
 ## Related pages
 
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
 * [Connect your factory](/factories/connect-your-factory/)
 * [Factory troubleshooting](/factories/troubleshooting/#work-isnt-starting)
diff --git a/src/content/docs/factories/integrations/linear.mdx b/src/content/docs/factories/integrations/linear.mdx
index 341ab9235..ceb31166a 100644
--- a/src/content/docs/factories/integrations/linear.mdx
+++ b/src/content/docs/factories/integrations/linear.mdx
@@ -20,6 +20,25 @@ When the factory needs an answer, reply in Linear, or open the live run to steer
 
 For workspace-level installation, reconnection, and removal steps, see the [Linear integration setup guide](/platform/integrations/linear/).
 
+## Permissions
+
+Linear app authorization is separate from linking a teammate's Warp account. In Linear's `actor=app` authorization model, a workspace admin installs the app, and updates are attributed to the app rather than the installer.
+
+The table describes the scopes in Warp's development configuration. The production authorization request hasn't been confirmed; review Linear's consent screen before approving workspace access.
+
+{/* VERIFY: Confirm the production Linear OAuth scope list and actor parameter from the persisted provider record or a live authorization URL; the public directory listing exposes neither, and Warp login blocks the connection flow. */}
+
+| Scope to confirm | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `app:assignable` | Let the app be delegated issues and made a project member | Delegate work to the factory | Doesn't grant repository access |
+| `app:mentionable` | Let the app be mentioned in issues, documents, and other editor surfaces | Start an agent session with a mention | Not itself a grant to edit those resources |
+| `comments:create` | Create issue comments | Acknowledge requests and post results | Narrower than the separately listed `write` scope |
+| `issues:create` | Create and update issues, and create their attachments | Create or update tracked work | Despite its name, this scope isn't create-only |
+| `read` | Read data available to the app | Retrieve issue context and workspace metadata | Subject to the app's team access in Linear |
+| `write` | Broad write access available to the app | Update issues, workflow state, and delegation | Broader than comment creation; trigger filters don't narrow this grant |
+
+These scope meanings follow [Linear's OAuth reference](https://linear.app/developers/oauth-2-0-authentication) and [app authentication model](https://linear.app/developers/agents#actor-and-scopes). A workspace admin can change or revoke the app's team access in Linear. Selecting teams for a factory's automations controls routing, not the underlying OAuth grant.
+
 ## Connect Linear
 
 You connect Linear either while creating a factory, at the **Connect your issue trackers** step, or afterward from the factory's **Settings**. Either way you do the same two things:
@@ -84,3 +103,8 @@ Connecting Linear doesn't grant repository access. Branches and pull requests us
 * **An event doesn't start work** - Confirm the automation is enabled, the event type matches, and every filter matches the issue's current values or the state change.
 * **One action starts multiple runs** - Look for overlapping agent-session and comment triggers, then narrow or remove one.
 * **No pull request appears** - Check the factory's code-host credentials and repository access. Linear authorization alone doesn't allow code changes.
+
+## Related pages
+
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
+* [Linear integration](/platform/integrations/linear/) - Install or remove the workspace app
diff --git a/src/content/docs/factories/integrations/permissions.mdx b/src/content/docs/factories/integrations/permissions.mdx
new file mode 100644
index 000000000..ffe722d35
--- /dev/null
+++ b/src/content/docs/factories/integrations/permissions.mdx
@@ -0,0 +1,43 @@
+---
+title: Permissions for factory integrations
+description: >-
+  Review permission scopes, credential types, and access boundaries for GitHub,
+  GitLab, Linear, Jira, Slack, and Microsoft Teams integrations.
+---
+
+Factory integrations grant access to your code, issues, and conversations. Use the integration-specific tables to review the requested scopes separately from the actions a factory performs and the events that start work.
+
+## Permissions by integration
+
+Each integration page lists its declared grants and access boundaries. An installation's approved version, resource selection, and provider policies determine its effective access.
+
+| Integration | Authorization model | Inventory status and details |
+| --- | --- | --- |
+| [GitHub](/factories/integrations/github/#permissions) | GitHub App installation token; account linking identifies the requester separately | Registered repository, organization, and account permissions with read or write levels |
+| [GitLab](/factories/integrations/gitlab/#permissions) | User OAuth for setup; manager and factory service-account tokens with separate membership roles | Required setup scopes and provisioned service-account access; additional production OAuth scopes haven't been confirmed |
+| [Linear](/factories/integrations/linear/#permissions) | Workspace app authorization, separate from a teammate's Warp account link | Development scope list; production scopes and actor parameter haven't been confirmed |
+| [Jira](/factories/integrations/jira/#permissions) | Forge app scopes with distinct app and user token paths | Marketplace-declared permissions, read impersonation, and checks of user permissions before writes |
+| [Slack](/factories/integrations/slack/#permissions) | Per-factory bot token plus manager authorization for app provisioning | Per-factory bot and setup-user scopes; the separate workspace manager bot inventory hasn't been confirmed |
+| [Microsoft Teams](/factories/integrations/teams/#permissions) | Identity linking separate from a team-scoped bot and application resource-specific consent | Declared app permissions and team-scoped RSC grants; deployed app, additional Entra permissions, and installed grants need confirmation |
+
+## Grants, actions, and event filters
+
+**Provider grants** define what a credential authorizes. A scope can grant more than the specific actions Warp currently exposes: Jira's `write:jira-work`, for example, includes deleting issues even though a factory workflow might only post comments.
+
+**User and service-account roles** further constrain operations. A GitLab factory bot has its own project memberships; it doesn't inherit the triggering person's permissions. Jira reads made on behalf of a user still follow that user's Jira access.
+
+**Automation filters** decide when work starts. A branch, keyword, project, or channel filter isn't a substitute for narrowing the provider's authorization. A connected integration can also supply tools to runs that started elsewhere.
+
+## Access review before installation
+
+Compare the app's actual consent with its table before granting access. For example, to pilot a factory on one GitHub repository, select that repository in the app installation rather than relying on a repository filter in an automation.
+
+Record the approved repositories, projects, teams, or conversations alongside the granted scopes. Check whether approval covers an app installation, a human OAuth grant, or a service-account role; some integrations need more than one.
+
+To withdraw access, use the provider's app or token controls linked from each integration page. Disabling an automation stops that trigger, not the underlying grant. Review separately configured [MCP servers](/platform/mcp/) and [secrets](/factories/secrets/) too; they can supply other credentials.
+
+## Related pages
+
+* [Connect your factory](/factories/connect-your-factory/) - Choose how work reaches a factory
+* [Factory automations](/factories/automations/) - Configure triggers without confusing routing with access
+* [About infrastructure and security](/factories/infrastructure-and-security/) - Review execution and security boundaries
diff --git a/src/content/docs/factories/integrations/slack.mdx b/src/content/docs/factories/integrations/slack.mdx
index 9f9c23384..d025a0edb 100644
--- a/src/content/docs/factories/integrations/slack.mdx
+++ b/src/content/docs/factories/integrations/slack.mdx
@@ -16,6 +16,56 @@ Each factory appears in Slack as its own app with the factory's name and avatar.
 * Permission to install Slack apps in the target workspace.
 * Permission to update the factory's configuration.
 
+## Permissions
+
+Each factory's Slack app uses a bot token. Managed setup also requests separate permissions from the person authorizing app provisioning.
+
+Warp requests the factory bot scopes below when creating and installing each factory app, and the manager-user scopes when authorizing managed setup. Review Slack's consent screen and workspace app policy for the access approved in your workspace.
+
+### Factory app bot scopes
+
+The scope meanings follow [Slack's scope reference](https://docs.slack.dev/reference/scopes/). These grants aren't limited to messages that start a run.
+
+| Scope | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `app_mentions:read` | Read messages that mention the app | Receive mention requests | Conversations the app belongs to |
+| `assistant:write` | Act as a Slack app agent | Support Slack's agent experience | Not a workspace administration grant |
+| `channels:history` | Read public-channel messages and content | Supply channel and thread context | Public channels the app has joined |
+| `channels:manage` | Manage joined public channels and create channels | Provision channels for factory work | Broader than reading or posting messages |
+| `channels:read` | Read public-channel metadata | Resolve channel names and choices | Metadata access isn't message-history access |
+| `chat:write` | Send messages as the app | Post progress and results | Uses the bot's identity and conversation access |
+| `chat:write.customize` | Customize the sender name and avatar | Present factory-branded messages | Doesn't grant access to another user's account |
+| `files:read` | Read accessible shared files | Include supported attachments as context | Files visible to the app |
+| `files:write` | Upload, edit, and delete files as the app | Share output artifacts | Broader than downloading attachments |
+| `groups:history` | Read private-channel messages and content | Supply private-channel context | Private channels the app has joined |
+| `groups:read` | Read private-channel metadata | Resolve accessible private channels | Requires channel membership |
+| `im:history` | Read direct-message content | Supply direct-message context | Direct messages involving the app |
+| `im:read` | Read direct-message metadata | Identify direct-message conversations | Not other people's private conversations |
+| `im:write` | Start direct messages | Send messages to people as the app | Distinct from reading existing messages |
+| `mpim:history` | Read group direct-message content | Supply group-conversation context | Conversations the app has joined |
+| `mpim:read` | Read group direct-message metadata | Identify accessible group conversations | Not all group conversations in the workspace |
+| `reactions:read` | Read reactions and associated content | Match reaction-based automations | Accessible conversations |
+| `reactions:write` | Add and edit reactions | Acknowledge requests | Actions as the app |
+| `usergroups:read` | Read user groups | Resolve group membership | Workspace directory data |
+| `users:read` | Read workspace member profiles | Resolve people and user names | Directory access isn't limited to a trigger's author |
+| `users:read.email` | Read member email addresses | Match accounts and look up people | Email access is separate from `users:read` |
+
+### Managed setup user scopes
+
+These scopes authorize app management, not factory access to your personal message history.
+
+| Scope | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `app_configurations:read` | Read configurations of apps created by the manager app | Inspect factory app configuration | Limited by Slack to that manager's apps |
+| `app_configurations:write` | Create apps and change their configuration | Create and update factory apps | Limited by Slack to that manager's apps |
+| `managed_apps:install` | Install managed child apps | Install each factory's Slack app | Subject to your workspace's app policy |
+
+The workspace manager app also has its own bot grant, separate from the factory apps and the setup user's grant. Its bot scope inventory hasn't been confirmed here; the factory bot table doesn't describe that grant.
+
+{/* VERIFY: Confirm the production Slack workspace manager app's bot scope list from its registration or persisted base provider; factory bot scopes and manager user scopes are independently established. */}
+
+Channel invitations constrain bot access. Automation filters constrain which events start work, not what an authorized bot token can read. For example, a keyword filter doesn't remove the app's history access to other messages in a joined channel. See [disconnecting Slack](#troubleshooting-and-reconnection) to remove the factory app; review the manager authorization separately when withdrawing setup permissions.
+
 ## Connect the factory
 
 1. **Select Slack while creating a factory**, or connect it later from the factory's **Settings**. Warp installs its Slack app for you.
@@ -129,9 +179,10 @@ To route work into the factory from other tools, see [Connect your factory](/fac
 
 ## Privacy
 
-The factory's app reads messages only where it's mentioned, directly messaged, or subscribed by an automation you configured. Message content and supported attachments are used to run the factory's work, and your Slack profile email is used to map you to your Warp account. Data is handled per the [Warp Privacy Policy](https://www.warp.dev/privacy).
+The factory uses message content and supported attachments for its work, and your Slack profile email to map you to your Warp account. Its [bot scopes](#factory-app-bot-scopes) also authorize reading history in conversations the app has joined, including through [integration-provided tools](#use-integration-provided-tools); mentions and automation filters aren't a message-level access boundary. Data is handled per the [Warp Privacy Policy](https://www.warp.dev/privacy).
 
 ## Related pages
 
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
 * [Factory automations](/factories/automations/)
 * [Factory troubleshooting](/factories/troubleshooting/#work-isnt-starting)
diff --git a/src/content/docs/factories/integrations/teams.mdx b/src/content/docs/factories/integrations/teams.mdx
index 3e0caaff9..14020236c 100644
--- a/src/content/docs/factories/integrations/teams.mdx
+++ b/src/content/docs/factories/integrations/teams.mdx
@@ -20,6 +20,28 @@ Connect a factory to Microsoft Teams so mentions in standard and shared channels
 The integration supports standard and shared channels. Private channels and direct messages are not supported.
 :::
 
+## Permissions
+
+Microsoft account linking and Teams app installation are separate authorizations. The account-linking flow requests OpenID Connect identity scopes; it doesn't describe the bot's Microsoft Graph access.
+
+**Production consent still needs verification:** compare the installed app's permissions with this inventory and review any additional Microsoft Entra API permissions and tenant grants.
+
+{/* VERIFY: Confirm the deployed Teams app requests the permissions below, and compare its installed resource-specific consent and any additional Entra delegated or application permissions with tenant grants. */}
+
+| Scope or permission surface | Granted access | Function in Warp | Boundary |
+| --- | --- | --- | --- |
+| `openid` in account linking | Authenticate the Microsoft user with an ID token | Verify the Microsoft account being linked | Doesn't authorize reading Teams messages |
+| `profile` in account linking | Basic identity claims, including the user's object ID | Match the user and Microsoft organization to Warp | The linking request doesn't include `offline_access` |
+| `identity` in manifest `permissions` | Legacy declaration for user identity | Declare the app's identity capability | Not an OpenID Connect or Microsoft Graph scope |
+| `messageTeamMembers` in manifest `permissions` | Legacy declaration for messaging team members | Declare the app's messaging capability | Doesn't mean Warp exposes direct-message tools |
+| `team` in `bots[].scopes` | Bot installation context, not an API permission | Receive activity and send bot replies in teams | No `personal` or `groupChat` bot scope is declared; `supportsFiles` is `false` |
+| `ChannelMessage.Read.Group` | Application resource-specific consent (RSC): read the installed team's channel messages without a signed-in user | Receive channel activity and retrieve thread history | Includes messages without an **@Warp** mention; limited to the team where consent is granted, not the entire tenant |
+| `ChannelSettings.Read.Group` | Application RSC: read the installed team's channel names, descriptions, and settings | Resolve channel metadata when retrieving context | Read-only; limited to the team where consent is granted |
+
+The two RSC permissions are declared as `Application`, not `Delegated`, under `authorization.permissions.resourceSpecific`. [RSC](https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent) is granted during installation or upgrade in a specific team. Non-RSC Graph permissions are [managed separately in Microsoft Entra ID](https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/app-permissions/teams-app-permissions) and aren't established by this manifest. Microsoft [deprecates the top-level `permissions` field](https://learn.microsoft.com/en-us/microsoft-365/extensibility/schema/root?view=m365-app-1.25#permissions); its legacy entries aren't additional Graph grants.
+
+Warp's [shared-channel rules](#use-shared-channels) and [tool limitations](#what-agents-can-do-in-teams) describe runtime restrictions, not the full authority granted to the installed app. To withdraw access, review the Teams installation and Entra grants as well as [disconnecting Microsoft Teams in Warp](#disconnect-microsoft-teams). Signing out unlinks your account; it doesn't uninstall the bot.
+
 ## Set up Microsoft Teams
 
 1. **Enable Microsoft Teams for the Warp workspace.** A workspace admin opens **Integrations** in the <a href={VARS.FACTORY_WEB_APP_URL}>{VARS.FACTORY_WEB_APP}</a>. If **Microsoft Teams** is unavailable, <a href={VARS.CONTACT_SALES_URL}>contact sales</a>.
@@ -139,6 +161,7 @@ The factory's app uses message content and supported attachments from the channe
 
 ## Related pages
 
+* [Permissions for factory integrations](/factories/integrations/permissions/) - Compare grants and review status across providers
 * [**Connect your factory**](/factories/connect-your-factory/) - Choose the sources that route work into the factory.
 * [**Factory automations**](/factories/automations/) - Edit trigger filters and avoid overlapping Teams triggers.
 * [**Factory definition**](/factories/factory-as-code/) - Declare `microsoft-teams` and `teams` triggers as code.
diff --git a/src/sidebar.ts b/src/sidebar.ts
index 539e2216b..c94839b11 100644
--- a/src/sidebar.ts
+++ b/src/sidebar.ts
@@ -496,6 +496,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [
 					label: 'Integrations',
 					items: [
 						{ slug: 'factories/connect-your-factory', label: 'Connect your factory' },
+						{ slug: 'factories/integrations/permissions' },
 						{ slug: 'factories/integrations/slack', label: 'Slack' },
 						{ slug: 'factories/integrations/teams', label: 'Microsoft Teams' },
 						{ slug: 'factories/integrations/linear', label: 'Linear' },