How ThreatLynx discovers, scores, and governs connected applications
This reference explains the technical mechanisms behind ThreatLynx SaaS discovery — what data is collected, how risk is scored, and how governance workflows operate. Intended for security teams, IT administrators, compliance reviewers, and procurement due diligence.
ThreatLynx provides governance visibility and readiness support. Discovery is metadata and permission-based. It does not constitute compliance certification, legal assurance, or guaranteed detection coverage. Findings should be reviewed by qualified security, risk, and legal advisors.
How OAuth-based discovery works
ThreatLynx reads authorised application records from your workspace tenant APIs. No endpoint software is required and no workspace content is accessed.
Discovery data flow
A single read-only connection from ThreatLynx to your workspace admin APIs. No agent installation, no proxy, no traffic intercept.
What ThreatLynx detects
Discovery captures OAuth metadata and governance signals — not content. The following data types are collected from workspace admin APIs.
| Data type | Detail |
|---|---|
| Connected third-party applications | All apps with at least one active OAuth grant in the tenant. |
| OAuth scopes per application | Specific API permissions granted: mail read/write, files, calendar, directory, admin. |
| User authorisation counts | Number of users who have independently authorised each application. |
| Service principals | Applications acting as automation or integration identities without user context (M365). |
| AI-indicator applications | Apps matching known AI/LLM vendor patterns or names — flagged based on metadata, not content inspection. |
| MCP-connected systems | Model Context Protocol connected applications identified via OAuth patterns and vendor metadata. |
| Automation and workflow tools | Applications identified as workflow automation platforms (e.g. Zapier, Make) based on vendor metadata. |
| Governance status | Approved, Under Review, Restricted, or Blocked — as recorded in ThreatLynx by your team. |
| Risk score and band | Composite score 0–100 across four dimensions. Displayed per-application with contributing factors. |
| Vendor jurisdiction | Country of incorporation inferred from vendor registration data where available. |
What ThreatLynx does not access
Understanding the boundaries of discovery is essential for security review and procurement due diligence.
Email content
ThreatLynx does not read, retrieve, or store the content of any email message, calendar event, chat message, or notification in your workspace.
File and document content
Documents, spreadsheets, presentations, and files stored in Google Drive, SharePoint, or OneDrive are not accessed. ThreatLynx records only that a connected app has a file-access scope — not what it accessed.
Employee behaviour or activity
ThreatLynx does not monitor employee behaviour, track individual user activity patterns, log keystrokes, or record screen interactions. It is a SaaS governance tool, not an employee monitoring product.
Endpoint data
No software is installed on endpoints. ThreatLynx does not access device configuration, locally installed applications, browser history, or network traffic from client devices.
Real-time event streams
Discovery reads point-in-time OAuth grant state from admin APIs. It does not tap into real-time event logs, webhook streams, or audit log feeds unless a specific integration is configured and consented to.
Credentials or tokens
ThreatLynx does not capture, store, or replicate OAuth access tokens, refresh tokens, or user passwords. It reads metadata records only.
Privacy architecture by design
The discovery API connection is scoped to the minimum permissions required to enumerate OAuth grant records. ThreatLynx does not request, store, or process any scope that would permit content access to email, files, or messages. Our Privacy Policy documents the full scope of data collected. Read the Privacy Policy →
Discovery sources
ThreatLynx currently supports two discovery sources. Additional sources are in development.
Google Workspace
Generally available- APIGoogle Workspace Admin SDK
- ScopeDomain-wide OAuth clients + user-level tokens
- Auth methodService account with domain delegation
- Data returnedApp name, client ID, scopes, user count, grant date
- Sync typeManual trigger or scheduled sync
- Content accessNone — metadata only
Microsoft 365Beta
Feature coverage evolving- APIMicrosoft Graph v1.0
- ScopeEnterprise apps, service principals, delegated grants
- Auth methodApp registration in Entra ID (Azure AD)
- Data returnedApp name, client ID, permissions, principal type
- Sync typeManual trigger
- Content accessNone — metadata only
Risk scoring methodology
Every discovered application receives a composite risk score from 0–100. Scores are calculated from explicit, auditable factors — no black-box model.
OAuth scope sensitivity
Mail write/delete, directory admin, and delegated admin scopes carry the highest per-dimension scores. Profile-only or calendar read scopes score lower.
Scope breadth
An application granted access across multiple sensitive categories (mail + files + directory) scores higher than a single narrow-purpose scope.
User exposure count
Wider user authorisation amplifies risk. A high-sensitivity scope held by one user scores lower than the same scope granted across an entire department or domain-wide.
AI tool indicator
Applications matching AI/LLM vendor patterns receive additional weighting. AI services commonly process sensitive content to deliver features, raising data-exposure considerations.
Vendor jurisdiction
Applications registered outside Australia may raise data sovereignty and privacy compliance considerations — reflected as a contributing factor, not a disqualifying condition.
Governance status
Unreviewed applications receive a higher score than those with a documented governance decision. Taking a governance action (approve, restrict, block) updates the active score.
Scores are indicative risk signals for governance prioritisation. They are not definitive security assessments and should not be the sole basis for enforcement decisions.
Agent governance discovery
ThreatLynx identifies likely non-human identities and AI-connected applications using rules-based heuristics applied to OAuth metadata. Detection is confidence-based, not absolute.
Known AI/agent vendor + sensitive scope access (mail, files, directory). Both vendor classification and scope classification present.
Partial signals — vendor name pattern only, or scope-only match without confirmed AI vendor classification.
Weak or single-signal match. Governance review recommended before any classification decision.
Agent identity signals are governance readiness support — not a certified AI inventory, legal attestation, or regulatory determination. Findings should be reviewed by security, risk, or application owners before formal use.
Compliance framework mapping
ThreatLynx discovery data supports governance readiness for Australian and international frameworks. Coverage is partial — not certification.
ASD Essential Eight
DirectApplication Control (ML2/ML3) · User Application Hardening
ThreatLynx discovery provides an inventory of third-party OAuth-connected applications across your tenant — directly relevant to Application Control maturity and the assessment of authorised vs. unauthorised software. User Application Hardening is supported by identifying which applications have been granted elevated scopes by individual users.
APRA CPS 234
SupportsInformation Asset Register · Third-party Assessment
CPS 234-regulated entities are expected to maintain an information asset register and identify risks from third-party information security capability. ThreatLynx provides a continuous SaaS inventory with governance decisions that can be used as evidence in CPS 234 information security capability assessments.
Australian Privacy Principles (APP 11)
SupportsSecurity of Personal Information
APP 11 requires organisations to take reasonable steps to protect personal information from misuse, interference, and unauthorised access. ThreatLynx helps identify which third-party applications have been granted OAuth access to personal information held in Workspace environments.
ISO/IEC 27001:2022
PartialA.8 Asset Management · A.9 Access Control
ThreatLynx supports asset inventory (Annex A.8) and access control review (Annex A.9) by maintaining a discoverable record of connected SaaS applications and their granted permissions. This does not constitute ISO certification or a complete implementation of Annex A controls.
Regulatory references are informational. ThreatLynx does not provide legal advice, compliance certification, or guaranteed compliance outcomes. Coverage designations reflect the nature of support provided, not audit attestation. Consult qualified legal and compliance counsel for specific regulatory obligations.
Limitations and confidence
Effective governance begins with understanding what the tool can and cannot do. These limitations apply to all ThreatLynx deployments.
API access is required
Discovery depends on administrative API access to your Google Workspace or Microsoft 365 tenant. If the required Admin SDK or Graph API permissions are not granted, some or all applications may not appear in the inventory.
Microsoft 365 discovery depends on Graph metadata
Microsoft 365 discovery via Microsoft Graph depends on the permission scopes and metadata returned by the tenant. Service principal discovery and permission scope depth reflect what Microsoft Graph exposes at the time of sync.
Metadata-based confidence
Application classification (AI, automation, MCP) is based on vendor name patterns and OAuth metadata — not content inspection. Some applications may be misclassified, and some categories of interest may not be represented in current detection rules.
Not all OAuth clients are visible
Certain application types — particularly those using OAuth flows not recorded in standard admin APIs, or applications approved by individual users before ThreatLynx was connected — may not appear in the initial inventory.
Risk scores are indicative
Scores reflect risk prioritisation for governance review, not a definitive security assessment. They should be used as a starting point for human review, not as the sole basis for enforcement decisions.
Governance action is manual
ThreatLynx records governance decisions but does not automatically revoke OAuth tokens or block application access. Revocation must be performed by an administrator through the workspace admin console.
ThreatLynx provides governance readiness support for Australian organisations using Google Workspace and Microsoft 365. Discovery coverage, score accuracy, and governance outcomes depend on accurate and complete administrative API access. All findings should be reviewed by qualified security, IT, and legal professionals before use in formal compliance assessments or enforcement decisions.
See discovery on your workspace data
Request a guided walkthrough to explore ThreatLynx SaaS discovery, risk scoring, and governance workflows in your Google Workspace or Microsoft 365 environment.