> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tendor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration permissions

> Choose Microsoft and Google access, configure administrator restrictions, and verify resource boundaries.

Choose the service and access you need before continuing to the provider's consent screen. New native connections start with read access. Drafts, labels, calendar changes, and supported Microsoft file changes require a deliberate additional selection. Google Drive defaults to read/import access; explicitly selecting Upload and share files requests full Drive access. Review both Tendor's access summary and the provider's consent screen.

Microsoft services share a Microsoft 365 account connection. Gmail, Google Calendar, and Google Drive have separate service connections, but may share an OAuth application. Separate buttons do not prove separate provider grants or independent revocation. If you grant Mail or Calendar but decline SharePoint, the authorised services can connect successfully while SharePoint remains unavailable.

## Requested permissions

The tables below describe new permission requests. Existing grants can be broader. Microsoft adds `User.Read` for account identification and `offline_access` for background access. Google adds `openid`, `email`, and `profile`; Google scope names below have the prefix `https://www.googleapis.com/auth/`.

### Microsoft

| Selection | Data permissions | What to review |
| - | - | - |
| Read Outlook Mail | `Mail.Read` | The signed-in account's mailbox |
| Prepare Outlook drafts | `Mail.ReadWrite` | Mail changes, including drafts; this permission does not itself grant sending |
| Manage Outlook labels | `Mail.ReadWrite`, `MailboxSettings.ReadWrite` | Message categories and the account's category settings |
| Read Microsoft Calendar | `Calendars.Read` | The account's calendars |
| Change Microsoft Calendar | `Calendars.ReadWrite` | Create, change, and delete calendar events |
| Read OneDrive | `Files.Read` | The signed-in user's files |
| Change OneDrive | `Files.ReadWrite` | Create, change, and delete the signed-in user's files |
| Read approved SharePoint sites | `Sites.Selected` | Choose multiple sites after connecting; an administrator must grant this app a `read` role on every site and the signed-in account must have access |
| Browse and choose SharePoint sites (organization administrator opt-in) | `Sites.Read.All` | A shared account enables workspace site browsing; Microsoft grants broader read access, while Tendor reads only your saved site selection |

Read scopes can accompany write scopes where background notifications require them. No selection in this table requests application permissions, `Mail.Send`, `Mail.Send.Shared`, `User.Read.All`, `Directory.Read.All`, or FullControl. Existing consent must still be inspected separately.

Microsoft distinguishes delegated access, which acts with a signed-in user, from application access without a user. OneDrive personal accounts also include files shared with that user under `Files.Read` and `Files.ReadWrite`. See Microsoft's [permission definitions](https://learn.microsoft.com/en-us/graph/permissions-reference).

<Warning>
  Site selection happens in Tendor after Microsoft sign-in. Microsoft's consent screen approves permissions, not individual sites. **Browse and choose SharePoint sites** requires a Tendor organization administrator connecting a shared account; this enables workspace approval for read-only site browsing. Microsoft may include that already-consented read permission in other account tokens. Tendor's selection does not narrow the provider token. **Read approved SharePoint sites** uses `Sites.Selected` and requires Microsoft administrator approval for each site. That restricted profile cannot coexist with broad consent in the same token. Neither profile requests `Files.*.All` or `Sites.ReadWrite.All`.
</Warning>

### Choose and manage multiple sites

1. Choose the SharePoint permission and complete Microsoft sign-in once.
2. In Microsoft 365 account settings, open **Manage SharePoint sites**. Browsing mode supports search and multiple checkboxes. Restricted mode accepts known approved site URLs or IDs; your Microsoft administrator must grant access first.
3. Save the sites Tendor should read. No sites are read when the selection is empty.
4. Use the same account setting to add or remove sites later, without another OAuth connection. Removing a site stops future access and syncing in Tendor; files already imported into projects are kept.

The personal account owner manages its restricted selection. Organization owners and administrators manage shared account selections. Other team members cannot enable broad consent or change those shared sites.

### Google

| Selection | Data permissions | What to review |
| - | - | - |
| Read Gmail | `gmail.readonly` | Read the connected account's mail |
| Prepare Gmail drafts | `gmail.readonly`, `gmail.compose` | Google also authorises sending with the compose permission |
| Manage Gmail labels | `gmail.modify` | Google also authorises composing and sending with this permission |
| Read Google Calendar | `calendar.calendarlist.readonly`, `calendar.events.readonly`, `calendar.freebusy` | Calendar list, event details, and availability |
| Change Google Calendar | `calendar.calendarlist.readonly`, `calendar.events`, `calendar.freebusy` | Event changes across calendars the account can access |
| Read Google Drive | `drive.readonly` | All files the connected account can access |
| Upload and share Google Drive files | `drive` | Enables native upload and sharing; the provider scope also authorises viewing, editing, creating, and deleting all files the account can access |

Google does not provide an ordinary Gmail draft or message-modification scope that excludes sending. Tendor action availability and review rules do not reduce the authority of the provider token. See [Gmail scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) and [Calendar scopes](https://developers.google.com/workspace/calendar/api/auth).

Google's `drive.file` provides access to files created by or explicitly shared with an application. It is not the permission used by Tendor's automatic Drive indexing. Selecting a folder in a workflow does not restrict a `drive` or `drive.readonly` grant to that folder. See [Drive scopes](https://developers.google.com/workspace/drive/api/guides/api-specific-auth).

## Microsoft administrator setup

Before connecting a dedicated tender mailbox, an Entra administrator should:

1. Record the intended tenant, application/client ID, dedicated account, approved services, and exact permissions. Use a non-administrator account that owns the tender mailbox. A separate user's shared mailbox is a different permission model.
2. Review the enterprise application's existing delegated grants and application permissions. Remove obsolete broad grants through the provider's administration process before claiming that the account has been narrowed.
3. In Entra **Enterprise applications → Consent and permissions → User consent settings**, disable user consent or apply an administrator-managed consent policy that disallows broader permissions. Check that the dedicated account has no role that can grant consent itself.
4. Require assignment to the enterprise application and assign only approved accounts. Approve the reviewed permission set; do not approve a suite-wide permission list without inspecting it. An admin consent workflow can collect requests without letting users approve them.
5. Connect the dedicated account in Tendor. For mailbox-only use, select Outlook Mail and leave Calendar, OneDrive, and SharePoint unselected.
6. Compare the actual grant with the approved list. Run the positive and negative access checks below before accepting the configuration.

These controls govern future consent. Existing grants are not removed by disabling user consent. See [configure user consent](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) and [assignment and admin consent](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview).

### Dedicated mailbox and one SharePoint site

| Requirement | Supported answer |
| - | - |
| Dedicated mailbox, no other users' mail | A dedicated signed-in mailbox with delegated Mail access is a supported configuration; verify it in the customer tenant |
| No send-as-other permission | New native Microsoft profiles do not request sending or shared-mail permissions; inspect old grants and Exchange delegation too |
| No broad Files/Sites permissions and exactly one SharePoint site | Use approved-site read access, configure the site grant below, and verify actual tenant restrictions before acceptance |
| Users cannot broaden permissions themselves | Configure Entra consent restrictions and application assignment; Tendor's selection screen alone is insufficient |
| Evidence of resources accessed | Capture provider activity records and the verification results below; consent screenshots alone are insufficient |

### Configure approved-site read access

This profile uses delegated `Sites.Selected` and supports reading and importing documents. It does not expose SharePoint writes or tenant-wide site search. Microsoft enforces the intersection of the application's site grant and the signed-in account's rights. Tendor also binds discovery, tool reads, and file synchronisation to the saved site selection. `Sites.Selected` alone does not grant access or specify a read/write role.

1. Identify the exact Microsoft OAuth application/client ID used by this Tendor environment. An Entra administrator must review both per-user and tenant-wide grants for this app, including historical Files, Sites, Mail.Send, shared-mail and directory grants. Remove incompatible grants; selecting a narrow scope does not revoke them. The current connector uses Tendor's registered client, not a customer-supplied client ID. If your tenant cannot remove incompatible grants for that client, do not accept this profile as isolated.
2. Using the administrator's independent provisioning tool, resolve the approved site's canonical ID, in the format `hostname,site-collection-UUID,web-UUID`. Do not grant Tendor broad site search merely to discover this ID.
3. Grant the **Tendor application's client ID** a **read** role on exactly that site:

   ```http theme={null}
   POST https://graph.microsoft.com/v1.0/sites/{approved-site-id}/permissions
   Content-Type: application/json

   {
     "roles": ["read"],
     "grantedToIdentities": [{
       "application": {
         "id": "TENDOR-APPLICATION-CLIENT-ID",
         "displayName": "Tendor"
       }
     }]
   }
   ```

   This is an administrator operation performed with a separately authorised administrative identity/tool. Its provisioning permissions must never be assigned to Tendor's runtime application. In particular, do not grant Tendor FullControl so it can provision itself. See [Microsoft's site permission creation requirements](https://learn.microsoft.com/en-us/graph/api/site-post-permissions?view=graph-rest-1.0).
4. Give the dedicated tender account access only to the intended site and its own mailbox. Consent to delegated `Sites.Selected` plus identity/background permissions, and optionally `Mail.Read`. Apply the Entra consent and assignment restrictions above. Do not grant `Files.*`, broad `Sites.*`, shared-mail, sending, directory read-all or user read-all access to this profile. Tenant-wide consent to `Sites.Selected` does not change other connections: a managed account reads only its saved site selection.
5. In Tendor, choose **Read approved SharePoint sites** and continue to Microsoft. Select the approved site URLs or IDs in Tendor after sign-in. Clear **Read email** if only site access is needed. Existing OneDrive or broad SharePoint grants prevent selecting this profile; follow the disconnect/revoke/Add account sequence first.
6. Tendor verifies every selected site with Microsoft before saving the selection. Missing site permission or an incorrect URL/ID produces a setup error. If Microsoft declines the optional site permission but grants the requested mailbox, Mail connects while SharePoint stays unavailable. Site files synchronise through periodic delta polling; this profile does not request broader drive-notification permissions.
7. Perform the positive and negative tenant tests below. A successful read proves access to that resource; it does **not** prove the app has no other site grants, only the `read` role, or no historical broad consent. Retain the administrator's grant inventory and provider-denial evidence.

Use **Manage SharePoint sites** to change the selection without reconnecting. An administrator can grant several sites to one account/app; a new grant is needed only for a site not already approved. Microsoft grant revocation stops subsequent provider reads. Existing imported copies have a separate lifecycle. Tendor does not infer write permission from `Sites.Selected`; assign `read` for provider-enforced read-only access.

### Read-only site browsing

For the self-service experience, a Tendor organization owner/admin connects a shared Microsoft account and explicitly chooses **Browse and choose SharePoint sites**. Approve delegated `Sites.Read.All`, keep application permissions and broad file/write grants removed, then choose multiple sites in Tendor. Only administrators manage the shared selection; team members use that account's selected files.

This shared connection records the workspace's browsing approval. Temporary credential expiry does not erase the approval; disconnecting the shared account withdraws it for future connections and reconnects. Provider consent remains a separate Microsoft administrator action. Existing mail accounts may retain already-approved read-only consent without acquiring SharePoint access. Do not combine broad consent and a claimed restricted `Sites.Selected` token within the same tenant/app grant.

## Google Workspace administrator setup

Use **Security → Access and data control → API controls → Manage third-party app access** to inspect the OAuth client ID. Configure **Specific Google data** with only the approved scopes, including the required sign-in scopes, for the intended organisational unit. A **Trusted** designation allows broader access and is not equivalent to a scope allowlist. See [Google Workspace app access controls](https://support.google.com/a/answer/7281227?hl=en\&p=app_access_apps).

Connect the intended account and check its calendar sharing, shared-drive membership, and accessible files. Account restrictions are not a per-folder grant. Personal Google accounts do not have Workspace administrator policy controls. Google verification and restricted-scope security assessment requirements still apply; selecting fewer services does not replace them.

## Existing connections, reconnecting, and revocation

Changing the selection does not revoke an existing provider grant. Reconnect requests supported stored service permissions again. Accounts retaining broad Microsoft file/write grants or unapproved site-wide read grants cannot reconnect: disconnect in Tendor, revoke the provider grants, then add the account with the approved permissions. Revoking at the provider alone does not clear Tendor's stored scope record. The provider may return only part of the request. Tendor uses the returned grant to determine which capabilities are available. For example, Mail or Calendar can remain connected when SharePoint is not granted. Enabling another supported capability requests additional consent.

Microsoft can return broader permissions from historical consent even after a new narrow request. Tendor rejects broad file/write grants and unapproved site-wide read grants on that new connection; ask an administrator to revoke them first. Existing connections are not automatically disconnected by this change.

Use Reconnect on an existing account to add or restore supported access. If you use Add account and choose an identity that is already connected, Tendor keeps its existing connection and asks you to use Reconnect.

Microsoft consent is cumulative for an application. Its refresh tokens are tied to the user and client, and may obtain access for other already-approved resources. See [incremental consent](https://learn.microsoft.com/en-us/entra/identity-platform/consent-types-developer) and [refresh-token behaviour](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens).

Google's combined authorisation can include permissions granted through different clients in the same API project. Revocation can affect other connected Google services using that grant. Tendor does not opt new requests into automatic incremental scope combination, but that does not erase historical consent. Inspect actual grants when reconnecting. See [Google incremental authorisation and revocation](https://developers.google.com/identity/protocols/oauth2/web-server#incrementalAuth).

To narrow an existing connection, plan the interruption and follow this order:

1. **Disconnect the account in Tendor.**
2. **Revoke any remaining grant at the provider.** Microsoft requires this separate administrator action; review Google grants and related service connections too.
3. **Use Add account to create a new connection**, selecting only the approved access.

Do not use ordinary **Reconnect** as the downgrade step: it retains supported stored scopes and rejects unapproved broad Microsoft scopes, including when provider consent was revoked first. Recheck related service connections after Google revocation. Disconnecting external access does not by itself delete files already imported into projects; review those copies separately.

Microsoft disconnect removes Tendor's local credentials and stops its connection; it does not remove the Entra consent grant or guarantee immediate invalidation of an already-issued provider token. Remove that grant separately in Microsoft administration. Google token revocation can also invalidate sibling service connections that share the same grant.

An unconnected capability remains unavailable to Ask AI and routines until authorised. A connected read-only account does not authorise writes. For expired access, review the request before using Reconnect to restore access. To reduce permissions, use the disconnect, provider revocation, and Add account sequence above.

## Other connected applications

Composio-brokered integrations use separate enterprise applications and consent grants.
The Teams toolkit can post channel messages; Microsoft 365 native mail permissions
above do not describe that application's authority. Administrators should block
unwanted Composio/Teams enterprise applications and approve them separately only
when those features are intended.

## Access verification and audit evidence

Run this checklist with an authorized test account and sites in a tenant with a
SharePoint Online license. Record the results for your tenant; repository tests
and provider documentation do not demonstrate its effective restrictions.

Use approved test resources and a controlled recipient. Record a permitted resource and a known resource outside the approved set. A missing or invalid resource ID is not sufficient evidence of denied access.

<Note>
  Results below are from a controlled Microsoft 365 test tenant using synthetic
  files and a Tendor development deployment on 3–4 October 2026. They are recorded
  in assessment TND-MS-2026-10-03. Both Tendor Microsoft app registrations have
  verified publisher COMPLIANCE0 PTY LTD (publisher ID 7123446), verified since
  8 June 2026 and confirmed again on 4 October. Production verification and
  acceptance in your own tenant remain separate. Untested rows
  remain explicit; a passing resource read does not establish every permission boundary.
</Note>

| Test | Expected result | Actual result / evidence |
| - | - | - |
| Connect one service using a clean grant | Consent contains only that service and required identity/background access | Executed: SharePoint-only and OneDrive-only grants contained the selected service plus identity/background scopes. |
| Grant Microsoft Mail or Calendar while declining SharePoint | The granted services connect successfully; SharePoint stays unavailable | NOT EXECUTED: partial-consent decline was not exercised in this tenant run. |
| Connect Google Drive with a clean grant | Default read-only access supports catalog, reading, and import; upload/sharing requires explicit full Drive consent | NOT EXECUTED in this Microsoft assessment. |
| Connect the approved-site profile with only its site grant | Consent includes `Sites.Selected` and no broad Files/Sites scopes; the configured site and libraries are readable | Passed: actual `Sites.Selected` token had no broad Files/Sites grant; assigned site files downloaded with matching hashes. |
| Restricted profile: access a known unapproved site/library with the same token | Provider denies access; use an existing resource ID and inspect the actual app/site grants | Passed: known existing unassigned-site file paths and item IDs returned 403; assigned-site files were positive controls. |
| Remove the approved site grant and retry a provider read | Provider denies access; do not use an already imported copy as the test | Passed: the revoked site’s known library root returned 403 while the retained site returned 200. Site metadata alone still resolved. |
| Read the dedicated mailbox and approved files | Expected fixture content is accessible | Passed: own-mailbox reads and five approved-site fixture downloads were exercised; file hashes matched. |
| Read another mailbox by known ID | Provider denies access | NOT EXECUTED: own-mailbox success is not evidence for another mailbox’s denial. |
| Access unconnected Mail, Calendar, or Drive APIs | Provider denies access where scopes do not overlap; separately verify Tendor blocks unavailable capabilities | Passed for exercised controls: OneDrive-only consent denied Mail/Calendar; Tendor denied unavailable capabilities. A separate no-scope OneDrive 404 is not treated as proof of provider permission denial. |
| Modify a fixture using read-only access | Provider denies the change | Passed: provider SharePoint/OneDrive writes were denied; Tendor denied draft/event writes on read-only connections. |
| Send as another user with the Microsoft connection | Provider denies the send; inspect shared/send grants and Exchange delegation | NOT EXECUTED: the separate own-draft send-denial test below does not cover another user or Exchange delegation. |
| Request broader consent as a non-admin user | Administrator approval is required or request is blocked | NOT EXECUTED: configure and verify the administrator controls in your tenant. |
| Browsing profile: select two sites on one account, then remove one | Tendor denies future access to the removed site; Microsoft may still permit it under the broader read token | Executed: direct access and catalog entries for the removed site were denied/hidden. Mixed site/library IDs exposed a separate defect, tracked in the paired-ID test below. |
| Browsing profile: reconnect mail with workspace-approved cumulative `Sites.Read.All` | Mail remains usable; the extra provider scope does not enable unselected SharePoint sites | NOT EXECUTED: shared site browsing was tested separately from this cumulative-consent reconnect scenario. |
| Access another site using a historical broad SharePoint grant | May succeed until provider revocation; removing the selection does not narrow existing tokens | Observed with a new browsing grant: Microsoft still read the removed site after Tendor deselection. Historical reconnect variants were not separately exercised. |
| Revoke provider consent, then use ordinary Reconnect | Supported stored scopes are requested again; retired broad Microsoft grants block reconnect with revocation guidance | NOT EXECUTED: the tested narrowing flow used Disconnect, provider revocation and Add account. |
| Disconnect in Tendor, revoke remaining provider consent, then use Add account | The new request includes only the selected access; verify actual grants and related service reauthorisation requirements | Passed: old Tendor account access and materialization were denied; the new OneDrive-only grant had `Files.Read` without Mail/Calendar access. |

Additional exercised boundaries:

| Test | Expected result | Actual result / evidence |
| - | - | - |
| Use a selected site ID with a known unselected site’s library/item IDs | Tendor denies the mismatched pair even when Microsoft can read both sites | Fixed and passed on dev revision `c2b1db27e` (4 October): an approved-site fixture with two provider grants and one saved site denied direct and mixed-site reads/listing, with an allowed-site positive control. Browsing mode was not repeated after the fix. |
| Materialize approved-site catalog files into the Tendor task workspace | The actual workspace bytes match the approved source fixtures | Passed on dev revision `fcae747d1` (4 October): all five SharePoint fixtures matched their SHA-256 values in temporary Scratch. This does not cover Google/OneDrive or durable Project imports. |
| Send the known mock draft with `Mail.ReadWrite` but without `Mail.Send` | Microsoft denies sending | Passed: 403; the draft remained unsent. No email was sent by the test. |
| Revoke Microsoft consent and immediately reuse an already-issued token | Invalidation timing follows Microsoft’s token policy; disconnect Tendor separately | The cached token still worked immediately afterward. This does not establish immediate provider revocation. Tendor disconnect separately blocked subsequent use of the old connection. |

For each test, record UTC time, deployment revision, tenant/account/client IDs, requested and granted scopes, resource IDs, operation, response status, and provider request ID. Retain no access tokens, refresh tokens, message bodies, or file content in this evidence sheet.

Microsoft Graph activity logs include application/user identity, request URI, scopes, response status, and request identifiers. They require Entra P1/P2 and a configured Azure logging destination. Filter by the reviewed app and user, and correlate positive and denied requests. Sign-in and consent logs describe authentication and authorisation changes; they are not a complete file-access history. See [Microsoft Graph activity logs](https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview).

Tendor does not currently claim a complete customer-visible history or export of
every integration item read and write. The assessment records above and provider
logs are evidence for their recorded operations; they do not constitute that
product capability.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.