Access scopes per integration
When you connect a provider to Wisteria, you grant it specific read scopes. This page lists every scope Wisteria requests, what each is used for, and why nothing else is requested.
All scopes are read-only. Wisteria never writes, modifies, or deletes anything in your tenant.
Microsoft 365
Granted via Microsoft Entra ID admin consent (Global Administrator only).
| Scope | What it lets Wisteria do | Why we need it |
|---|---|---|
Files.Read.All | Read documents across OneDrive + SharePoint | Evaluate files for training relevance |
Sites.Read.All | Discover SharePoint sites | Find team content shared in SharePoint |
User.Read.All | List domain users | Understand who content is for |
Group.Read.All | Read group membership | Department-aware course suggestions |
These are tenant-level scopes — they apply to the whole organisation, not individual users. The admin consent is granted once at setup.
What we DON’T request:
- Mail, calendar, contacts
- Write or delete permissions
- Identity providers, conditional access policies, security configs
Google Workspace (Domain-Wide Delegation)
Granted by a Google Workspace super administrator authorising Wisteria’s service account.
| Scope | What it lets Wisteria do | Why we need it |
|---|---|---|
drive.readonly | Read documents the impersonated super-admin can see | Evaluate files for training relevance |
admin.directory.user.readonly | List domain users | Understand who content is for |
These are scopes applied to a service account that impersonates one super-admin user. Wisteria mints fresh tokens server-side using the service account’s private key — no per-user OAuth.
What we DON’T request:
- Gmail, Calendar, Contacts
- Write or delete permissions
- Admin SDK write operations
Lark / Feishu (Self-Built App)
Each customer creates their own self-built app in Lark or Feishu’s developer console and grants:
| Scope | What it lets Wisteria do | Why we need it |
|---|---|---|
drive:drive:readonly | Read Docs and files in Lark Drive | Evaluate files for training relevance |
drive:file:readonly | Read file content | Extract text for AI evaluation |
contact:user.base:readonly | Read user list | Understand who content is for |
The app you create lives in your tenant. You revoke it by deleting the app from your dev console.
What we DON’T request:
- Messages, chats, channels
- Calendars
- Write or delete permissions
Per-user Google Drive (OAuth)
Granted by an individual user via standard OAuth.
| Scope | What it lets Wisteria do | Why we need it |
|---|---|---|
drive.readonly | Read documents the connecting user can see | Evaluate files for training relevance |
That’s the only scope. The user is the only person who can revoke (from myaccount.google.com or from inside Wisteria).
The “principle of least privilege” stance
Wisteria deliberately requests the smallest set of scopes that lets the AI ambient watcher do its job. We don’t request scopes “just in case” — every scope you grant is one we’ve justified.
If you spot a scope you don’t want to grant: that integration won’t fully work. Concretely:
- Without
User.Read.All/admin.directory.user.readonly/contact:user.base:readonly, the AI evaluator can’t understand who content is for. Suggestions become generic. - Without the file read scopes, there’s nothing to scan. The integration is non-functional.
There’s no partial-scope mode — either you grant the full read set or the integration isn’t useful.
Audit at the provider’s end
Every API call Wisteria makes to your tenant is logged at the provider’s end:
- Microsoft 365 — audit log at
compliance.microsoft.comshows every Graph API call from the Wisteria service principal. - Google Workspace — audit log at
admin.google.com → Audit and investigation → Drive log eventsshows reads from the impersonated user. - Lark / Feishu — audit log in the developer console shows API calls from your self-built app.
You can audit Wisteria’s activity from your own console — independently of Wisteria’s audit log.
Revoking access
Two layers, available for every integration:
- From inside Wisteria — Settings → Integrations → Disconnect. The stored credentials are deleted.
- At the provider’s end — see the per-integration runbook for the exact steps.
Either is sufficient to stop the watcher. Doing both is the cleanest option.
Token handling
See Token storage per provider for how each provider’s credentials are stored.
Frequency of access
Wisteria calls each integrated provider:
- Nightly for scheduled scans (typically once per workspace per day)
- On demand when an admin clicks Run scan now (rate-limited)
- Per-action when a trainer clicks Generate on a “Wisteria noticed” card (downloads the source file once for AI module generation)
We don’t poll continuously. We don’t make speculative calls. Every API call is tied to a deliberate action.
What’s NOT in this list
A few scopes you might wonder about:
- Microsoft Mail, Calendar, Teams — not requested.
- Google Mail, Calendar, Meet, Chat — not requested.
- Slack messages — Wisteria integrates with Slack via incoming webhooks (outbound only); we don’t read your Slack messages.
If a scope you’d expect isn’t in the list, it’s because we deliberately don’t request it.