Permission Model at a Glance
Ruli integrations use delegated OAuth access. In practical terms, the data available to Ruli is the intersection of:
The permissions requested by the Ruli integration.
The resources the connecting user can access in the third-party service.
Any restrictions imposed by the customer’s third-party tenant administrator.
The narrower set of operations implemented by Ruli’s integration tools.
An OAuth scope is an authorization ceiling, not evidence that Ruli reads every resource covered by that scope. Assistant tools make on-demand API calls when a connected integration is enabled and relevant to a user’s request. The current Assistant tools retrieve information; they do not create, edit, send, or delete third-party content.
Some providers only offer broad delegated scopes. For example, Google Drive’s drive.readonly and Microsoft’s Files.Read.All allow reads across files available to the connecting user, even though Ruli only retrieves files selected by the user or relevant to an Assistant search. Slack is a special case: its shared installation supports both Assistant search and Legal Hub intake, so the installed Slack app requests read-only user scopes as well as bot write scopes used by Legal Hub.
Integration Security Overview
Question | Ruli Behavior |
Are integrations enabled by default? | No third-party account is connected by default. Each user must authorize an integration through OAuth. Once connected, it is enabled in Assistant chats by default, but the user can turn it off for a chat or disconnect it. Turning it off in a chat prevents Assistant use in that chat; it does not revoke the OAuth credential. |
What can Ruli do? | Assistant integrations provide live, on-demand search and retrieval. Ruli does not currently expose third-party write, modification, send, or delete tools through the Assistant. Separate products, such as Legal Hub’s Slack bot, may have write permissions needed for their stated workflow. |
Is data continuously synchronized? | Assistant connectors query the provider when relevant to a user’s prompt; they do not continuously index the connected account. Separately imported files or folders follow Ruli’s normal file-storage and synchronization behavior. |
Whose permissions apply? | The connecting user’s delegated permissions apply. Ruli can retrieve only resources available to that user and allowed by the granted OAuth scope. A broad scope does not bypass the provider’s underlying user, workspace, site, channel, folder, or record permissions. |
Is every access user-approved? | Initial connection requires explicit OAuth consent and may also require tenant-admin approval. After connection, relevant read tools may run automatically when the integration is enabled for the chat; there is no separate approval prompt for each search or read. |
What does offline_access or a refresh-token permission mean? | It allows Ruli to obtain new short-lived access tokens without asking the user to sign in for every request. It does not create additional resource rights, but it allows the granted access to continue until the user disconnects, the provider revokes the grant, or an administrator blocks the application. |
How is retrieved data used? | Relevant excerpts and metadata are passed into the Assistant to answer the request and may be retained with the chat and its citations under Ruli’s normal retention and access controls. Assistant connectors do not copy or index the entire connected account as part of the connection process. |
How are credentials handled? | Credentials are tied to the individual Ruli user. OAuth credentials stored server-side by Ruli are encrypted. Connector traffic and credentials may also be processed through Nango, Ruli’s integration proxy. Cloud file-picker workflows may temporarily hold an access token in the user’s browser storage. |
What is logged? | Ruli retains normal chat messages, responses, and citations. Application errors are logged. There is currently no customer-facing, connector-specific audit log showing every API request or resource accessed. Provider and Nango logging and retention should be included in an IT/subprocessor review. |
What user controls exist? | A user can connect or disconnect their own account and enable or disable a connected integration in a chat. Disconnecting removes the Ruli connection and, where supported, removes the corresponding Nango connection. Users may also revoke Ruli directly through the provider’s account-security settings. |
What admin controls exist? | Tenant administrators can approve, restrict, or block Ruli’s OAuth applications using provider controls in Google, Microsoft, Slack, Atlassian, and other services. Ruli does not currently provide a granular organization-wide integration allowlist, connected-user dashboard, connector-specific policy configuration, or admin disconnect control. |
Does personal data flow through integrations? | Potentially yes. Email, calendars, messages, contacts, documents, user profiles, CRM data, task records, and support tickets can contain personal data. The applicable DPA, subprocessors, retention terms, and customer instructions should therefore be included in the review. |
Assistant Integrations and Requested Permissions
All current Assistant tools are retrieval-only. The table below identifies the permissions requested by the implementation and the effective exposure those permissions create.
Integration | Use Case and Data Access | Requested Permissions | Effective Reach and Limitations |
Gmail | Searches email threads and reads matching messages. | gmail.readonly; userinfo.email | Can read message and thread content across the connecting user’s mailbox. It cannot send, modify, label, or delete email. |
Google Calendar | Searches events, attendees, times, and availability. | calendar.events.readonly; calendar.freebusy; userinfo.email | Can read event details and free/busy information available to the user. It cannot create, update, accept, or cancel events. Visibility restrictions configured in Google Calendar still apply. |
Google Drive | Searches and reads accessible files live. Also supports selecting files or folders for import. | drive.readonly; drive.metadata.readonly; userinfo.email | Can list metadata and read content for files available to the user, including shared files and shared drives the user can access. This is broader than access only to manually selected files. It cannot edit, move, share, or delete Drive files. |
Outlook Mail | Searches and reads messages and conversations. | openid; offline_access; User.Read; Mail.Read | Can read mail in the connecting user’s mailbox and basic signed-in profile information. It cannot send, modify, move, or delete messages. Microsoft tenant consent policies may restrict connection. |
Outlook Calendar | Searches events, attendees, locations, and availability. | openid; offline_access; User.Read; Calendars.Read | Can read calendars and events available to the connecting user. It cannot create, update, respond to, or cancel events. |
Microsoft Teams | Reads the user’s chats and joined team channels. | openid; offline_access; User.Read; Chat.Read; Team.ReadBasic.All; Channel.ReadBasic.All; ChannelMessage.Read.All | Chat.Read covers the user’s one-to-one and group chats. The team and channel scopes enumerate memberships and channels. ChannelMessage.Read.All reads channel posts and normally requires Microsoft administrator consent. Ruli cannot post or modify Teams messages through the Assistant. |
OneDrive & SharePoint | Searches and reads files from accessible drives and sites; also supports file or folder import. | openid; offline_access; User.Read; Files.Read.All; Sites.Read.All | Can read files and SharePoint site content available to the signed-in user. The All suffix does not override the user’s delegated access, but the scope is broad across resources that user can access. Ruli cannot modify, share, move, or delete content. |
Slack | Searches messages and reads threads in channels and DMs available to the user. Legal Hub separately receives and answers inquiries in Slack. | User: users:read, search:read, channels:history, groups:history, im:history, mpim:history.
Bot: channels:history, channels:read, chat:write, commands, files:read, files:write, groups:history, groups:read, im:history, im:read, im:write, users:read, users:read.email. | Assistant search uses the connecting user’s visibility across public channels, private channels, group DMs, and direct messages. Legal Hub’s bot permissions allow it to receive inquiries and write messages/files in the channels or conversations where the bot is installed or permitted. Slack workspace administrators can approve, restrict, or remove the app. |
Confluence | Searches and reads accessible spaces, pages, blog posts, comments, permissions, users, and attachments; also supports import. | read:confluence-space.summary; read:confluence-content.all; read:confluence-content.summary; search:confluence; read:confluence-content.permission; read:confluence-user; read:space:confluence; read:page:confluence; read:comment:confluence; read:blogpost:confluence; read:attachment:confluence; offline_access | Can search and read content in Confluence sites and spaces available to the connecting user. It cannot create, edit, comment on, or delete Confluence content. |
Jira | Counts, searches, and reads issues and user information. | read:jira-work; read:jira-user; offline_access | Can read issue fields, comments, projects, and user information available to the connecting user. It cannot create, transition, assign, comment on, or edit issues. |
Asana | Lists the connecting user’s assigned tasks, projects, and due dates. | workspaces:read; users:read; projects:read; tasks:read | The implemented Assistant tool is limited to tasks assigned to the connecting user, even though the scopes can expose other readable workspace, user, project, and task metadata. It cannot create or modify tasks. |
Linear | Searches and reads issues and comments. | read | Can read Linear workspace information available under the connected account. It cannot create, update, assign, or comment on issues. |
Trello | Lists boards and cards, searches cards, and reads card details and comments. | read | Can read boards and cards available to the connecting user. It cannot create, move, update, comment on, or delete cards. |
Notion | Searches and reads pages shared with the integration. | No OAuth scope list is passed by Ruli; the integration requires read-content capability. | Notion access is resource-based. Ruli can search and read only pages and databases the user explicitly shares with the Notion integration. It cannot access unrelated workspace content or modify shared content through the Assistant. |
Airtable | Lists bases and tables and searches records and comments. | data.records:read; data.recordComments:read; schema.bases:read; workspacesAndBases:read; user.email:read | Can read base schemas, records, comments, workspace/base metadata, and the connected user’s email for resources available to that user. It cannot create, update, or delete records. |
HubSpot | Searches CRM companies, contacts, deals, quotes, line items, owners, properties, and tickets. | oauth; crm.objects.companies.read; crm.objects.contacts.read; crm.objects.deals.read; crm.objects.quotes.read; crm.objects.line_items.read; crm.objects.owners.read; crm.schemas.companies.read; crm.schemas.contacts.read; crm.schemas.deals.read; tickets | Can read the listed CRM objects and their schemas where available to the connected account. Ruli’s Assistant tools do not perform writes, but the legacy tickets permission should be reviewed because its provider-defined grant is not named as read-only. |
Zendesk | Searches and reads tickets, users, organizations, groups, attachments, views, and Help Center content. | read; tickets:read; users:read; organizations:read; groups:read; ticket_attachments:read; ticket_views:read; hc:read | Can retrieve the listed support and Help Center information available to the connecting user. It cannot create, update, assign, comment on, or close tickets. |
Dropbox | Searches and reads accessible files; also supports file or folder import. | files.metadata.read; files.content.read; account_info.read; sharing.read | Can list metadata, download readable files, resolve account/team-root information, and read existing sharing links. Dropbox determines these grants from the configured app permissions. Ruli cannot edit, upload, move, share, or delete Dropbox content through the Assistant. |
Box | Searches and reads accessible files; also supports file or folder import. | root_readonly | Can list and download content available to the connecting user within the Box account. The issued token is explicitly narrowed to read-only access. |
Salesforce | Browses records and imports selected contracts or attachments into Ruli. It is not currently a live Assistant search connector. | api; refresh_token | api permits Salesforce REST API access within the connected user’s Salesforce permissions, while refresh_token permits continued access until revoked. Ruli uses it to browse supported records and retrieve selected files; the Salesforce scope itself is broader than file-only access. |
ServiceNow | Search ServiceNow incidents, legal requests, and legal matters. | OAuth client credentials, dedicated read-only user, ruli_read, GET-only REST scope, and applicable read roles. | Read-only access to approved tables and fields. No creating, editing, deleting, comments, attachments, or arbitrary table access. |
Monday | Searches and summarizes accessible boards, groups, items, subitems, updates, Workdocs, files, users, teams, and tags through Assistant, with source citations. | account:read, assets:read, boards:read, docs:read, me:read, tags:read, teams:read, updates:read, users:read, workspaces:read | Read-only access to monday.com content available to the connecting user, including boards, items, updates, Workdocs, files, and directory data. Ruli cannot create, edit, delete, comment, or upload content. Access remains subject to the user’s monday.com permissions and continues until disconnected or revoked. |
Permission and Control Considerations for IT Review
Broad delegated file scopes: Google Drive, OneDrive, and SharePoint permissions cover content available to the connecting user, not only content previously imported into Ruli.
Mailbox and message exposure: Gmail, Outlook, Slack, and Teams can expose confidential communications and personal data within the connecting user’s access boundary.
Administrator consent: Microsoft Teams channel-message access normally requires tenant-admin consent. Other providers may also require administrator approval based on customer policy.
Persistent authorization: Refresh-token and offline_access grants remain usable until disconnected, revoked, expired by the provider, or blocked by an administrator.
Chat toggle versus revocation: Disabling an integration for a chat stops its use in that chat but leaves the account connected. Disconnecting or provider-side revocation is required to terminate the credential.
Slack’s combined permission set: Assistant search is read-only, but the shared Slack installation also has bot write permissions for Legal Hub workflows.
Third-party integration infrastructure: Nango participates in the credential and API request path for live connectors and should be included in security, logging, retention, and subprocessor review.
No granular Ruli organization policy: Ruli currently relies on individual connection controls and the customer’s provider-side OAuth administration rather than a Ruli organization-wide allowlist or connector policy framework.