New
OAuth Intelligence Reference

Scope-level visibility into connected application access

ThreatLynx helps organisations understand OAuth-connected application access across Google Workspace and Microsoft 365 environments — surfacing what each connected application can access, how permissions are classified, and how governance decisions are recorded.

Scope-level visibilityDelegated accessExplainable classificationGovernance-focusedMicrosoft 365

OAuth visibility is based on available provider APIs, metadata, and granted permission information at the time of workspace sync. ThreatLynx does not inspect email content, file content, or message payloads. Findings are governance indicators — not security determinations.

How OAuth-connected access works

OAuth 2.0 is the authorisation framework used by Google Workspace and Microsoft 365 to allow third-party applications to access workspace data on a user's or administrator's behalf.

Delegated access grants

When a user connects a third-party application to their workspace account, they issue an OAuth grant — a delegated permission that allows the application to act on their behalf within the stated scope.

Persistent refresh tokens

Applications granted offline access receive a refresh token that allows continued access without the user re-authorising. These tokens persist until revoked, meaning access may remain active long after initial consent.

Admin-consented permissions

Workspace administrators can grant organisation-wide OAuth permissions on behalf of all users. These domain-wide delegated authorities are recorded by the identity provider and visible in ThreatLynx discovery.

Service principals and app registrations

In Microsoft 365 environments, applications can operate as service principals — non-human identities with permissions granted at the tenant level. These machine-to-machine grants are distinct from user-delegated access.

Scope-level permission records

Each OAuth grant records the specific API scopes authorised. ThreatLynx surfaces these scope strings — enabling your team to understand exactly what each connected application is permitted to access.

Revocation and lifecycle

OAuth access can be revoked by the user, an administrator, or the application itself. ThreatLynx visibility reflects the current state of grants at the time of the most recent workspace sync.

OAuth access chain — from consent to visibility
01

User or admin consent

User connects a third-party app to their workspace. Scopes requested are presented at consent.

02

OAuth grant issued

Identity provider records the OAuth client, granted scopes, user, and date. Token issued.

03

ThreatLynx discovers

ThreatLynx reads the grant record from Admin SDK or Microsoft Graph via read-only API.

04

Governance review

Your team assesses, classifies, and documents a governance decision against the application.

Scope-level visibility

ThreatLynx surfaces the exact OAuth scope strings granted to each connected application. Scopes are classified by access type and sensitivity to support governance prioritisation.

ProviderScopeAccess typeSensitivityGovernance notes
Google

https://mail.google.com/

Gmail full access

Read / Send / DeleteCriticalComplete mailbox control. Allows sending email as the user, reading all messages, and deleting content.
Google

https://www.googleapis.com/auth/gmail.readonly

Gmail read

ReadHighRead access to all messages and attachments. Widely granted by productivity, AI, and CRM tools.
Google

https://www.googleapis.com/auth/drive

Drive full access

Read / Write / DeleteHighComplete control over all files in Drive. Includes creation, modification, and deletion of documents and folders.
Google

https://www.googleapis.com/auth/drive.readonly

Drive read

ReadMediumRead access to files and folders. Risk depends on the sensitivity of documents held in the workspace.
Google

https://www.googleapis.com/auth/admin.directory.user

Directory admin

Read / WriteCriticalAccess to user account management. Rarely required by legitimate SaaS integrations — investigate immediately.
Google

https://www.googleapis.com/auth/calendar

Calendar full access

Read / WriteMediumCreate, modify, and delete calendar events. Access to scheduling data, attendees, and meeting metadata.
Microsoft

Mail.ReadWrite

Exchange mail write

Read / WriteHighRead and modify Exchange Online messages. Common in email management tools and AI email assistants.
Microsoft

Files.ReadWrite.All

SharePoint / OneDrive write

Read / WriteHighFull read/write access to all files across SharePoint sites and OneDrive for all users in the tenant.
Microsoft

Directory.ReadWrite.All

Directory admin

Read / WriteCriticalFull read and write access to Azure AD directory data. Should be treated as the highest-risk Graph permission.
Both

offline_access / access_type=offline

Persistent access

Persistent tokenElevatedGrants refresh tokens enabling continued access without user re-authorisation. Applies on top of the base scope sensitivity.

Scope strings shown are illustrative examples. Actual scope strings vary by OAuth client implementation. ThreatLynx surfaces the scope strings recorded by the identity provider at the time of the OAuth grant.

Permission sensitivity classification

ThreatLynx classifies OAuth permissions into four sensitivity tiers. Classification is rules-based and fully documented — each tier carries defined examples, score contributions, and governance review recommendations.

Standardscore 0–15

Identity and authentication scopes plus limited read access. Typical for sign-in flows and calendar integrations with narrow data exposure.

Example scopes

openidemailprofileUser.ReadCalendars.Read

Low review priority. Confirm the application has a documented business purpose.

Elevatedscore 16–35

Read access to business content — files, messages, or scheduling data. Broad read access across all users or combined with offline access.

Example scopes

Calendars.ReadWriteContacts.ReadFiles.Read.Allgmail.readonly

Schedule for governance review. Verify scope is justified by stated application function.

Restrictedscore 36–65

Write access to email, files, or business documents. High data-modification risk. Often held by AI tools, email management platforms, and automation workflows.

Example scopes

Mail.ReadWriteFiles.ReadWrite.AllDrive full accessgmail (write)

Prioritise for governance review. Assign owner, document use case, and confirm no over-scoped access.

Administrativescore 66–100

Tenant-level identity or directory administration. Grants control over user accounts, groups, or domain settings. Rarely required by legitimate SaaS integrations.

Example scopes

admin.directory.userDirectory.ReadWrite.AllRoleManagement.ReadWrite.Directory

Immediate review. Escalate to security team. Block or restrict unless explicit administrative justification is documented.

AI and agent access visibility

ThreatLynx identifies likely AI-connected, automation, and non-human identity applications using metadata heuristics applied to OAuth grant records. Detection is confidence-based — not endpoint monitoring or behavioural surveillance.

AI productivity tools

High confidence

Examples

Writing assistants, AI email drafters, content generators

Detection signals

Vendor name/domain matches known AI product pattern. Scope includes gmail.readonly, Drive, or Files.Read.

Governance consideration

Data sent to external AI model for processing. Content exposure to third-party training or inference.

Automation workflows

High confidence

Examples

Zapier, Make, n8n, workflow orchestration platforms

Detection signals

Vendor classification as automation platform. Broad multi-scope access across mail, calendar, and files.

Governance consideration

Persistent access across multiple data categories. Actions may trigger without per-user consent per execution.

AI copilots / assistants

Medium confidence

Examples

Browser assistant extensions, inline copilots, chat-embedded tools

Detection signals

Application name and vendor pattern matches copilot/assistant classification. Workspace data scope present.

Governance consideration

Real-time access to workspace content for context injection or model prompting.

MCP-connected systems

Medium confidence

Examples

Model Context Protocol integrations, AI agent tooling

Detection signals

Client metadata or vendor pattern consistent with MCP server or tool-calling integration.

Governance consideration

Programmatic multi-turn access to workspace data by autonomous model agents.

Service principals (M365)

High (M365) confidence

Examples

App registrations, daemon applications, enterprise applications

Detection signals

Entity registered as a service principal or enterprise app in Entra ID with delegated or application-level permissions.

Governance consideration

Non-human persistent access without per-request user consent. Often hold broader permissions than interactive apps.

Autonomous integrations

Medium confidence

Examples

Background sync tools, scheduled automation, persistent agents

Detection signals

Application holds offline_access or persistent tokens. No identified human owner. Broad scope pattern.

Governance consideration

Continued access outside of active user sessions. Access may persist after the original user departs.

Agent and AI classification signals are governance indicators — not endpoint detection, content inspection, or behavioural monitoring. ThreatLynx does not monitor employee activity or access message payloads. All classification should be reviewed by security or application owners before formal use.

Governance workflow and lifecycle

Every application in the ThreatLynx inventory carries a governance status. Status transitions are logged with actor, timestamp, and documented rationale — creating an auditable governance record.

Ungoverned

No governance review has been initiated. The application is present in the inventory but has not been assessed or assigned. Default state for all newly discovered applications.

Assign owner → Initiate review → Document decision

Under Review

Review has been initiated and an owner assigned. The review has not yet produced a documented outcome. Applications should not remain in this state beyond the governance review cycle.

Complete assessment → Record decision → Set review date

Approved

Application has been reviewed, its scopes confirmed as appropriate, and an approval decision recorded with rationale. Approved status reduces the active risk score.

Schedule next review → Export as evidence

Restricted

Application is permitted under conditions. A restriction has been applied and documented. The restriction and its basis are logged for audit trail purposes.

Document restriction basis → Monitor for scope changes

Exception Granted

A formal exception has been recorded, with a documented rationale, approval authority, and defined expiry date. Treated as a temporary governance posture requiring scheduled re-review.

Set review date → Record approver → Monitor expiry

Blocked

Application has been reviewed and a block decision recorded. The record remains in the governance log for audit evidence. Token revocation must be performed separately by a workspace administrator.

Execute revocation in workspace console → Confirm removal

Audit trail

Every governance action is logged: actor, action, timestamp, and rationale. Immutable record suitable for internal audit and regulator evidence requests.

Evidence export

Point-in-time snapshots of the application inventory, scope data, and governance decisions can be exported for access reviews, compliance reporting cycles, and regulator requests.

Ownership assignment

Each application can be assigned a business owner and reviewer. Owner accountability is reflected in the risk score — unowned applications carry a higher ungoverned penalty.

Compliance framework alignment

OAuth intelligence data supports governance readiness for Australian regulatory frameworks. ThreatLynx provides visibility and evidence support — not compliance certification.

ASD Essential Eight — Application Control

Readiness visibility

OAuth grant visibility supports identification of authorised and unauthorised third-party application access — directly relevant to Application Control maturity assessment at ML2 and ML3.

APRA CPS 234 — Information Assets

Evidence support

OAuth scope and permission records provide structured evidence for information asset registers and third-party information security capability reviews required under CPS 234.

Privacy Act 1988 — APP 11

Identification support

Identifying which applications have OAuth access to personal information (mail, contacts, directory) supports an organisation's reasonable-steps obligations under APP 11 for protection of personal information.

Regulatory references are informational. ThreatLynx does not provide legal advice, compliance certification, or guaranteed compliance outcomes. Framework mappings are rules-based governance indicators. Consult qualified legal, compliance, and security advisors for specific regulatory obligations applicable to your organisation.

Example investigation walkthrough

An illustrative example showing how ThreatLynx surfaces OAuth intelligence for a discovered application. All details are hypothetical and for reference only.

Hypothetical application

AI Document Assistant

AI productivity tool · 54 users authorised · Vendor incorporated in USA · No governance decision on record

Critical risk · Score 82

Detected OAuth scopes

ScopeAccess typeSensitivityNote

https://mail.google.com/

Gmail full access

Read / Send / DeleteCriticalFull mailbox control. Highest-risk Gmail scope.

https://www.googleapis.com/auth/drive

Drive full access

Read / Write / DeleteHighComplete file management across all Drive content.

offline_access

Persistent refresh token

PersistentElevatedAccess persists without re-authorisation. Active token issued.

AI vendor classification

Confirmed — High confidence

Persistent access

Yes — offline_access granted

User exposure

54 users authorised

Governance status

Ungoverned — no decision on record

Recommended governance action

Assign a business owner and initiate a governance review. Document the approved use case — specifically confirming whether Gmail full access and Drive write access are justified by the stated business function. Consider requesting a restricted scope from the vendor (readonly variants). If mail write or delete access cannot be justified, move to restrict or block. Documenting a governance decision will reduce the composite risk score by up to 25 points.

This example is illustrative only. Actual scope data, classifications, and scores depend on the OAuth metadata available for each application in your environment.

Microsoft 365 OAuth Intelligence

Microsoft Graph API access required (read-only enterprise application registration)
Service principal and enterprise application visibility available
Not all Graph permissions are currently classified
Some advanced Graph APIs may require elevated Microsoft 365 licensing tiers

Confidence and limitations

Effective governance requires understanding the boundaries of OAuth intelligence tooling. These constraints apply to all ThreatLynx deployments.

01

Visibility depends on API access

OAuth intelligence requires administrative API access to your Google Workspace or Microsoft 365 tenant. If required permissions are not granted, some or all connected applications may not appear in the inventory.

02

Scope data reflects the granted record

ThreatLynx reads the scope strings recorded by the identity provider at the time of the OAuth grant. Scopes are reported as granted — ThreatLynx does not independently verify whether each scope is actively used by the application.

03

Microsoft 365 intelligence depends on Graph metadata

Graph API scope depth, service principal discovery, and permission data fidelity for M365 depend on the metadata returned by Microsoft Graph. OAuth intelligence from M365 tenants reflects what was available at the time of sync.

04

AI and agent classification is heuristic

AI tool and agent identity classification relies on metadata pattern matching — not content inspection, API call monitoring, or behavioural analysis. Some AI tools may not be classified, and classification patterns are updated periodically.

05

Revocation requires administrator action

ThreatLynx records governance decisions including block status but does not automatically revoke OAuth tokens. Revocation must be executed by a workspace administrator through the identity provider's admin console.

06

Snapshot state, not real-time

OAuth intelligence reflects workspace state at the most recent sync. New grants issued between syncs will not appear until the next discovery run. For environments with frequent OAuth activity, more regular syncs are recommended.

About ThreatLynx OAuth Intelligence

ThreatLynx provides governance and visibility tooling designed to assist security and risk workflows. OAuth intelligence is metadata-based and depends on the scope of administrative API access granted. It does not replace formal security review, legal assessment, or compliance audit conducted by qualified advisors. Findings should be reviewed and acted upon by qualified security, IT, and governance professionals.

See OAuth intelligence on your workspace

Request a guided walkthrough to explore scope-level OAuth visibility and governance workflows across your Google Workspace or Microsoft 365 environment.