[FEATURE] Per-routine connector permission scoping (e.g. read-only vs. read-write)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Routines run autonomously without approval prompts, which means the permission footprint of each routine matters a lot. Currently, when a connector is included in a routine, it inherits the full OAuth scope granted at the account level. There is no way to attach a connector to a routine with a reduced set of permissions — for example, read-only access to Gmail for a routine that only needs to monitor an inbox.
This is a least-privilege problem. A routine that reads from Slack to create a Linear issue shouldn't carry the ability to send Slack messages or delete threads. The blast radius of a misbehaving or prompt-injected routine is directly proportional to the permissions it holds.
Proposed Solution
Allow users to configure connector permission levels at the routine level, independently of the account-level OAuth grant. For example:
- When adding a connector to a routine, offer a permission tier selector (e.g. Read only / Read + Write / Full access)
- The routine's session would receive a downscoped token for that connector, regardless of what the account-level OAuth allows
This would complement the existing ability to remove connectors from a routine entirely — giving users a spectrum of access control rather than an all-or-nothing choice.
Alternative Solutions
_No response_
Priority
Medium - Would be very helpful
Feature Category
MCP server integration
Use Case Example
A routine that monitors Gmail for a specific type of message and logs results to Notion only needs read access to Gmail. Granting it full Gmail access (including send, delete, etc.) violates the principle of least privilege and creates unnecessary risk for an unattended automated process.
Additional Context
Related Issues
- #50062 — per-project connector scoping (which connectors load, not permission depth)
- #29914 — blanket Drive permissions with no folder-level scoping
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗