From ae424ae69cd5ac3bba71d0241011957af52af2ee Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 29 Oct 2026 17:46:58 +0000 Subject: [PATCH 1/5] docs: prototype integration permissions for security review Add source-backed scope tables and distinguish production app-consent gaps from capabilities, account roles, and routing filters. Co-Authored-By: Oz --- .../docs/factories/integrations/github.mdx | 15 ++++++ .../docs/factories/integrations/gitlab.mdx | 26 ++++++++-- .../docs/factories/integrations/jira.mdx | 20 ++++++++ .../docs/factories/integrations/linear.mdx | 24 +++++++++ .../factories/integrations/permissions.mdx | 47 +++++++++++++++++ .../docs/factories/integrations/slack.mdx | 51 ++++++++++++++++++- .../docs/factories/integrations/teams.mdx | 20 ++++++++ src/sidebar.ts | 1 + 8 files changed, 199 insertions(+), 5 deletions(-) create mode 100644 src/content/docs/factories/integrations/permissions.mdx diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx index d78b66eb1..0fbb74a2f 100644 --- a/src/content/docs/factories/integrations/github.mdx +++ b/src/content/docs/factories/integrations/github.mdx @@ -126,6 +126,20 @@ 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. +**Permission inventory pending verification.** The [Warp Factories GitHub App](https://github.com/apps/warp-factories) requests permissions in its app registration, separately from connecting a person's GitHub account. The exact permission names and read or write levels still need confirmation from the production app's installation consent screen. The table separates that missing inventory from known access boundaries. + +{/* VERIFY: GitHub production app registration and installation consent must supply every repository, organization, and account permission with its access level and purpose; API usage is not an inventory. */} + +| Permission or grant | Granted access | Function in Warp | Boundary | +| --- | --- | --- | --- | +| Repository permissions: exact names and levels unverified | The repository operations authorized at installation | Read code and context, push branches, open pull requests, and post results | These functions are not a complete list of requested permissions | +| Organization and account permissions: inventory unverified | Not established by this draft | Engineering must confirm any additional grants and why each is requested | Don't treat repository selection as proof that no other grants exist | +| Installation repository selection | All repositories or the repositories selected at installation | Make repositories available to factory runs | A factory's repository list and trigger filters do not replace installation authorization | + +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 +184,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..ea0dac207 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. +**Consent verification pending.** The scopes below are defined by the connection and token-provisioning paths. Confirm the production OAuth application's requested scopes and the resulting service-account memberships before using this draft for approval. + +{/* VERIFY: Confirm GitLab production OAuth registration requests api and read_user, and confirm provisioned manager and factory token scopes and memberships match this table. */} + +| 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..4cd7498ec 100644 --- a/src/content/docs/factories/integrations/jira.mdx +++ b/src/content/docs/factories/integrations/jira.mdx @@ -81,6 +81,23 @@ When the run finishes, the result appears in the agent session. The agent doesn' ## Permissions +The Jira app requests Forge scopes at installation, separately from linking your Jira account to Warp. + +**Deployed consent verification pending.** Engineering must compare these manifest scopes and offline user-impersonation settings with the production app's consent. + +{/* VERIFY: Confirm all six Jira Forge scopes and read-scope allowImpersonation settings against the deployed production app version and consent screen, and confirm why read:permission:jira is requested. */} + +| 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 | Purpose requires engineering confirmation | 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 +105,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 +117,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..78a77cec7 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. + +**Production scope inventory pending verification.** The table lists the scopes in Warp's development provider configuration, not a confirmed export of the production registration or consent screen. Engineering must compare the deployed request with this list, including any additional grants. + +{/* VERIFY: Confirm the complete production Linear OAuth scope list and actor=app setting against the app registration and authorization request; the six scopes below come from development provider configuration only. */} + +| 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..9b8abd03e --- /dev/null +++ b/src/content/docs/factories/integrations/permissions.mdx @@ -0,0 +1,47 @@ +--- +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. + +:::caution +This permissions reference is a draft for security review, not a complete production permission inventory. App-registration and installed-consent checks are outstanding as listed below; resolve them before using it to approve an integration. +::: + +## Permissions by integration + +Each integration page owns its scope details. “Source-defined” means a scope list is declared in configuration, not that an installed production app's consent has been checked. + +| Integration | Authorization model | Inventory status and details | +| --- | --- | --- | +| [GitHub](/factories/integrations/github/#permissions) | GitHub App installation token; account linking identifies the requester separately | Exact repository, organization, and account permission names and levels need an app-registration export | +| [GitLab](/factories/integrations/gitlab/#permissions) | User OAuth for setup; manager and factory service-account tokens with separate membership roles | Source-defined scopes and roles; production OAuth consent and provisioned access need confirmation | +| [Linear](/factories/integrations/linear/#permissions) | Workspace app authorization, separate from a teammate's Warp account link | Candidate scope list from development configuration; production registration and requested scopes need confirmation | +| [Jira](/factories/integrations/jira/#permissions) | Forge app scopes with distinct app and user token paths | Source-defined manifest scopes; deployed app version, consent, and impersonation settings need confirmation | +| [Slack](/factories/integrations/slack/#permissions) | Per-factory bot token plus manager authorization for app provisioning | Source-defined bot and manager-user scopes; production manager bot inventory and installed grants need confirmation | +| [Microsoft Teams](/factories/integrations/teams/#permissions) | Identity-linking scopes separate from bot and Microsoft Graph authorization | Identity scopes verified in the linking path; app package, Entra permissions, and tenant grants still needed | + +## 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..188880614 100644 --- a/src/content/docs/factories/integrations/slack.mdx +++ b/src/content/docs/factories/integrations/slack.mdx @@ -16,6 +16,54 @@ 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. + +**Installed-grant verification pending.** The bot and manager-user scopes below are defined in Warp's app-generation and authorization paths. Confirm the production manager app's own bot scopes and each installed factory app's consent before approval; those grants can differ from the generated defaults. + +{/* VERIFY: Confirm the production Slack manager app bot and user scope inventories and installed factory bot scopes against registration, generated manifest, and consent; reconcile any differences from these source-defined defaults. */} + +### 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 | + +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 +177,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..ce6b3052d 100644 --- a/src/content/docs/factories/integrations/teams.mdx +++ b/src/content/docs/factories/integrations/teams.mdx @@ -20,6 +20,25 @@ 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. + +**App permission inventory pending verification.** The production Teams app package and Microsoft Entra registration must establish the bot and Graph permissions. This draft doesn't infer those grants from API calls or from the actions exposed by Warp's tools. + +{/* VERIFY: Obtain the production Teams app manifest, Entra API permission export, and tenant consent grants; enumerate bot permissions and Graph delegated, application, and resource-specific grants with exact names and access boundaries. */} + +| 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` | +| Teams bot permissions: exact inventory unverified | To be confirmed from the app package and consent | Receive activity and send bot replies | App approval, team installation, and Warp routing are separate steps | +| Microsoft Graph permissions: exact inventory unverified | To be confirmed from Entra and the app manifest, including any resource-specific consent | Retrieve channel history and associated context | Don't assume team-scoped access instead of tenant-wide access without checking the actual grants | + +[Resource-specific consent](https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent) grants access to a particular team, chat, or user. It differs from tenant-wide application permission. Engineering must identify which model each production grant uses before this inventory is complete. + +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 {VARS.FACTORY_WEB_APP}. If **Microsoft Teams** is unavailable, contact sales. @@ -139,6 +158,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' }, From 564ea872965f75a8a6fd97a3001d1617c0d4e8e1 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 29 Oct 2026 17:49:27 +0000 Subject: [PATCH 2/5] docs: tighten Jira permission introduction Co-Authored-By: Oz --- src/content/docs/factories/integrations/jira.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx index 4cd7498ec..43e7d6289 100644 --- a/src/content/docs/factories/integrations/jira.mdx +++ b/src/content/docs/factories/integrations/jira.mdx @@ -81,7 +81,7 @@ When the run finishes, the result appears in the agent session. The agent doesn' ## Permissions -The Jira app requests Forge scopes at installation, separately from linking your Jira account to Warp. +Jira requests Forge scopes at installation, separately from linking your account to Warp. **Deployed consent verification pending.** Engineering must compare these manifest scopes and offline user-impersonation settings with the production app's consent. From 54587cab276c5ac85b7ca1cd8856fea0a97f632d Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 29 Oct 2026 21:02:11 +0000 Subject: [PATCH 3/5] docs: document Teams manifest permission inventory Replace unknown Teams bot and Graph inventory with bundled manifest declarations, distinguish team-scoped application RSC from identity linking and Entra grants, and narrow remaining verification to deployment and consent. Co-Authored-By: Oz --- .../docs/factories/integrations/permissions.mdx | 2 +- src/content/docs/factories/integrations/teams.mdx | 13 ++++++++----- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/src/content/docs/factories/integrations/permissions.mdx b/src/content/docs/factories/integrations/permissions.mdx index 9b8abd03e..fbe71cf46 100644 --- a/src/content/docs/factories/integrations/permissions.mdx +++ b/src/content/docs/factories/integrations/permissions.mdx @@ -22,7 +22,7 @@ Each integration page owns its scope details. “Source-defined” means a scope | [Linear](/factories/integrations/linear/#permissions) | Workspace app authorization, separate from a teammate's Warp account link | Candidate scope list from development configuration; production registration and requested scopes need confirmation | | [Jira](/factories/integrations/jira/#permissions) | Forge app scopes with distinct app and user token paths | Source-defined manifest scopes; deployed app version, consent, and impersonation settings need confirmation | | [Slack](/factories/integrations/slack/#permissions) | Per-factory bot token plus manager authorization for app provisioning | Source-defined bot and manager-user scopes; production manager bot inventory and installed grants need confirmation | -| [Microsoft Teams](/factories/integrations/teams/#permissions) | Identity-linking scopes separate from bot and Microsoft Graph authorization | Identity scopes verified in the linking path; app package, Entra permissions, and tenant grants still needed | +| [Microsoft Teams](/factories/integrations/teams/#permissions) | Identity linking separate from a team-scoped bot and application resource-specific consent | Source-defined manifest permissions and team-scoped RSC grants; deployed package, additional Entra permissions, and installed grants need confirmation | ## Grants, actions, and event filters diff --git a/src/content/docs/factories/integrations/teams.mdx b/src/content/docs/factories/integrations/teams.mdx index ce6b3052d..f1136e5a9 100644 --- a/src/content/docs/factories/integrations/teams.mdx +++ b/src/content/docs/factories/integrations/teams.mdx @@ -24,18 +24,21 @@ The integration supports standard and shared channels. Private channels and dire 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. -**App permission inventory pending verification.** The production Teams app package and Microsoft Entra registration must establish the bot and Graph permissions. This draft doesn't infer those grants from API calls or from the actions exposed by Warp's tools. +The `manifest.json` in `warp-microsoft-teams-app.zip` declares the app permissions below. **Production consent still needs verification:** compare the installed package with this inventory and review any additional Microsoft Entra API permissions and tenant grants. -{/* VERIFY: Obtain the production Teams app manifest, Entra API permission export, and tenant consent grants; enumerate bot permissions and Graph delegated, application, and resource-specific grants with exact names and access boundaries. */} +{/* VERIFY: Confirm the deployed Teams package matches the bundled manifest declarations 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` | -| Teams bot permissions: exact inventory unverified | To be confirmed from the app package and consent | Receive activity and send bot replies | App approval, team installation, and Warp routing are separate steps | -| Microsoft Graph permissions: exact inventory unverified | To be confirmed from Entra and the app manifest, including any resource-specific consent | Retrieve channel history and associated context | Don't assume team-scoped access instead of tenant-wide access without checking the actual grants | +| `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 | -[Resource-specific consent](https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent) grants access to a particular team, chat, or user. It differs from tenant-wide application permission. Engineering must identify which model each production grant uses before this inventory is complete. +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. From 68bf2bfe7ab6559b216d49013522de03610ca246 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 29 Oct 2026 21:19:59 +0000 Subject: [PATCH 4/5] docs: keep Teams permissions prose reader-facing Remove ZIP provenance from the permissions introduction and use app-focused consent wording in the central reference without changing declared permissions or access boundaries. Co-Authored-By: Oz --- src/content/docs/factories/integrations/permissions.mdx | 2 +- src/content/docs/factories/integrations/teams.mdx | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/docs/factories/integrations/permissions.mdx b/src/content/docs/factories/integrations/permissions.mdx index fbe71cf46..c43e242b9 100644 --- a/src/content/docs/factories/integrations/permissions.mdx +++ b/src/content/docs/factories/integrations/permissions.mdx @@ -22,7 +22,7 @@ Each integration page owns its scope details. “Source-defined” means a scope | [Linear](/factories/integrations/linear/#permissions) | Workspace app authorization, separate from a teammate's Warp account link | Candidate scope list from development configuration; production registration and requested scopes need confirmation | | [Jira](/factories/integrations/jira/#permissions) | Forge app scopes with distinct app and user token paths | Source-defined manifest scopes; deployed app version, consent, and impersonation settings need confirmation | | [Slack](/factories/integrations/slack/#permissions) | Per-factory bot token plus manager authorization for app provisioning | Source-defined bot and manager-user scopes; production manager bot inventory and installed grants need confirmation | -| [Microsoft Teams](/factories/integrations/teams/#permissions) | Identity linking separate from a team-scoped bot and application resource-specific consent | Source-defined manifest permissions and team-scoped RSC grants; deployed package, additional Entra permissions, and installed grants need confirmation | +| [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 diff --git a/src/content/docs/factories/integrations/teams.mdx b/src/content/docs/factories/integrations/teams.mdx index f1136e5a9..14020236c 100644 --- a/src/content/docs/factories/integrations/teams.mdx +++ b/src/content/docs/factories/integrations/teams.mdx @@ -24,9 +24,9 @@ The integration supports standard and shared channels. Private channels and dire 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. -The `manifest.json` in `warp-microsoft-teams-app.zip` declares the app permissions below. **Production consent still needs verification:** compare the installed package with this inventory and review any additional Microsoft Entra API permissions and tenant grants. +**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 package matches the bundled manifest declarations below, and compare its installed resource-specific consent and any additional Entra delegated or application permissions with 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 | | --- | --- | --- | --- | From 3d2def1015d7c89111091467fd6f10cd3c0b1528 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Thu, 29 Oct 2026 22:28:03 +0000 Subject: [PATCH 5/5] docs: verify declared integration permissions Replace GitHub placeholders with the public app registration inventory, corroborate Jira permissions against Marketplace, and narrow remaining OAuth configuration gaps. Co-Authored-By: Oz --- .../docs/factories/integrations/github.mdx | 29 ++++++++++++++----- .../docs/factories/integrations/gitlab.mdx | 4 +-- .../docs/factories/integrations/jira.mdx | 6 ++-- .../docs/factories/integrations/linear.mdx | 4 +-- .../factories/integrations/permissions.mdx | 16 ++++------ .../docs/factories/integrations/slack.mdx | 8 +++-- 6 files changed, 39 insertions(+), 28 deletions(-) diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx index 0fbb74a2f..602cb9307 100644 --- a/src/content/docs/factories/integrations/github.mdx +++ b/src/content/docs/factories/integrations/github.mdx @@ -126,15 +126,30 @@ 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. -**Permission inventory pending verification.** The [Warp Factories GitHub App](https://github.com/apps/warp-factories) requests permissions in its app registration, separately from connecting a person's GitHub account. The exact permission names and read or write levels still need confirmation from the production app's installation consent screen. The table separates that missing inventory from known access boundaries. +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. -{/* VERIFY: GitHub production app registration and installation consent must supply every repository, organization, and account permission with its access level and purpose; API usage is not an inventory. */} - -| Permission or grant | Granted access | Function in Warp | Boundary | +| 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 | | --- | --- | --- | --- | -| Repository permissions: exact names and levels unverified | The repository operations authorized at installation | Read code and context, push branches, open pull requests, and post results | These functions are not a complete list of requested permissions | -| Organization and account permissions: inventory unverified | Not established by this draft | Engineering must confirm any additional grants and why each is requested | Don't treat repository selection as proof that no other grants exist | -| Installation repository selection | All repositories or the repositories selected at installation | Make repositories available to factory runs | A factory's repository list and trigger filters do not replace installation authorization | +| 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. diff --git a/src/content/docs/factories/integrations/gitlab.mdx b/src/content/docs/factories/integrations/gitlab.mdx index ea0dac207..1010587c2 100644 --- a/src/content/docs/factories/integrations/gitlab.mdx +++ b/src/content/docs/factories/integrations/gitlab.mdx @@ -94,9 +94,9 @@ The factory never merges or approves a merge request; those decisions stay with 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. -**Consent verification pending.** The scopes below are defined by the connection and token-provisioning paths. Confirm the production OAuth application's requested scopes and the resulting service-account memberships before using this draft for approval. +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 GitLab production OAuth registration requests api and read_user, and confirm provisioned manager and factory token scopes and memberships match this table. */} +{/* 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 | | --- | --- | --- | --- | diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx index 43e7d6289..983b266ac 100644 --- a/src/content/docs/factories/integrations/jira.mdx +++ b/src/content/docs/factories/integrations/jira.mdx @@ -83,16 +83,14 @@ When the run finishes, the result appears in the agent session. The agent doesn' Jira requests Forge scopes at installation, separately from linking your account to Warp. -**Deployed consent verification pending.** Engineering must compare these manifest scopes and offline user-impersonation settings with the production app's consent. - -{/* VERIFY: Confirm all six Jira Forge scopes and read-scope allowImpersonation settings against the deployed production app version and consent screen, and confirm why read:permission:jira is requested. */} +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 | Purpose requires engineering confirmation | Doesn't grant the permissions being inspected | +| `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 | diff --git a/src/content/docs/factories/integrations/linear.mdx b/src/content/docs/factories/integrations/linear.mdx index 78a77cec7..ceb31166a 100644 --- a/src/content/docs/factories/integrations/linear.mdx +++ b/src/content/docs/factories/integrations/linear.mdx @@ -24,9 +24,9 @@ For workspace-level installation, reconnection, and removal steps, see the [Line 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. -**Production scope inventory pending verification.** The table lists the scopes in Warp's development provider configuration, not a confirmed export of the production registration or consent screen. Engineering must compare the deployed request with this list, including any additional grants. +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 complete production Linear OAuth scope list and actor=app setting against the app registration and authorization request; the six scopes below come from development provider configuration only. */} +{/* 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 | | --- | --- | --- | --- | diff --git a/src/content/docs/factories/integrations/permissions.mdx b/src/content/docs/factories/integrations/permissions.mdx index c43e242b9..ffe722d35 100644 --- a/src/content/docs/factories/integrations/permissions.mdx +++ b/src/content/docs/factories/integrations/permissions.mdx @@ -7,21 +7,17 @@ description: >- 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. -:::caution -This permissions reference is a draft for security review, not a complete production permission inventory. App-registration and installed-consent checks are outstanding as listed below; resolve them before using it to approve an integration. -::: - ## Permissions by integration -Each integration page owns its scope details. “Source-defined” means a scope list is declared in configuration, not that an installed production app's consent has been checked. +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 | Exact repository, organization, and account permission names and levels need an app-registration export | -| [GitLab](/factories/integrations/gitlab/#permissions) | User OAuth for setup; manager and factory service-account tokens with separate membership roles | Source-defined scopes and roles; production OAuth consent and provisioned access need confirmation | -| [Linear](/factories/integrations/linear/#permissions) | Workspace app authorization, separate from a teammate's Warp account link | Candidate scope list from development configuration; production registration and requested scopes need confirmation | -| [Jira](/factories/integrations/jira/#permissions) | Forge app scopes with distinct app and user token paths | Source-defined manifest scopes; deployed app version, consent, and impersonation settings need confirmation | -| [Slack](/factories/integrations/slack/#permissions) | Per-factory bot token plus manager authorization for app provisioning | Source-defined bot and manager-user scopes; production manager bot inventory and installed grants need confirmation | +| [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 diff --git a/src/content/docs/factories/integrations/slack.mdx b/src/content/docs/factories/integrations/slack.mdx index 188880614..d025a0edb 100644 --- a/src/content/docs/factories/integrations/slack.mdx +++ b/src/content/docs/factories/integrations/slack.mdx @@ -20,9 +20,7 @@ Each factory appears in Slack as its own app with the factory's name and avatar. Each factory's Slack app uses a bot token. Managed setup also requests separate permissions from the person authorizing app provisioning. -**Installed-grant verification pending.** The bot and manager-user scopes below are defined in Warp's app-generation and authorization paths. Confirm the production manager app's own bot scopes and each installed factory app's consent before approval; those grants can differ from the generated defaults. - -{/* VERIFY: Confirm the production Slack manager app bot and user scope inventories and installed factory bot scopes against registration, generated manifest, and consent; reconcile any differences from these source-defined defaults. */} +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 @@ -62,6 +60,10 @@ These scopes authorize app management, not factory access to your personal messa | `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