By Olivia Dubois
·
July 18, 2026
One compromised SaaS link can open access to several tools at once. The key point, in my view, is simple: the risk no longer comes from one application alone, but from the trust relationships between applications, browsers, APIs, extensions, sessions and suppliers.
Put simply, I see 3 problems:
I also see 3 signals to track immediately:
The figures set the tone:
For me, the answer can be summed up in three words: see, limit, monitor.
| Area | What I look at | What I do |
|---|---|---|
| Access | OAuth, APIs, sessions, extensions | I reduce permissions |
| Visibility | Shadow IT, Shadow AI, third-party dependencies | I keep the inventory up to date |
| Detection | Tokens, webhooks, exports, browser activity | I monitor and cut access when needed |
If I had to summarise the article in one sentence: the more SaaS tools are connected, the more a normal access path can become a discreet entry point if nobody monitors the links between them.
In an interconnected SaaS supply chain, a simple OAuth consent can create lasting access to several tools. The real trap is that this access often remains active long after the initial authorisation and goes unnoticed in day-to-day operations.
Attackers exploit this blind spot by promoting applications that appear legitimate. Once access has been granted, their actions pass through familiar platforms and look like ordinary API calls or authorised exports. 83% of SaaS applications are used without formal IT approval [4]. As a result, a large proportion of access remains outside the security team's field of control. Three paths appear most often: OAuth, the browser and automations.
The browser is a major entry point. An overly permissive extension can read page content, access cookies and hijack sessions. 56 malicious extensions were recently identified in the OpenVSX registry [1].
The problem does not stop there. When shared identities and persistent sessions are added to the mix, the risk rises quickly. If an account is compromised, the attacker can often move laterally to other connected applications. And if a session remains valid, they can continue acting without a new authentication step, particularly when refresh tokens are still active.
That is precisely what makes detection so difficult. The activity looks like that of a user who is already signed in to an authorised tool. At first glance, nothing stands out. The same trust relationship also extends to automations and machine-to-machine exchanges.
APIs and webhooks move data continuously between tools. On paper, that is convenient. In practice, a misconfigured automation between two SaaS services can quickly become an exfiltration channel. 63% of SaaS data breaches are caused by misconfiguration [4], rather than by highly advanced attacks.
The risk can also come from the supplier itself or from its subcontractors. A SaaS provider may rely on other parties — for example, AI model providers, hosting companies or integration partners — that the customer organisation has never assessed directly. If one of these links fails, the trust relationship already in place can become an entry point into internal data.
That is the core problem: these compromises use legitimate channels, valid credentials and expected data flows. In other words, they blend into the background. They are not invisible, however. They leave clear traces in permissions, tokens and activity logs. Useful signals can also be found in grants, sessions and supplier dependencies.
These attacks do not pass completely unnoticed. They leave marks in permissions, logs and access records. The aim here is straightforward: identify the signals that deserve immediate investigation. The points below also provide a basis for the controls presented in the next section.
When an OAuth authorisation grants far more access than an application needs, it should raise concerns. This is often a sign of excessive privileges. The same applies to tokens: if a refresh token is used at 03:00 Paris time, well outside normal working hours, that is a strong signal. It may indicate a compromised session or automated exfiltration.
The problem is that many organisations do not even see this type of clue. In France, only 21.6% of companies use automated secret detection to identify exposed API keys or tokens [1]. Put differently, a large share of these alerts remains untreated.
A browser or IDE extension requesting broad access without a clear reason should trigger an immediate response. This is not a minor detail. It is a high-risk entry point, and 18% of organisations do not control these high-privilege vectors [1].
Certain behaviours also stand out on the identity side. For example:
These cases should be analysed, especially alongside the session trust model mentioned above. There is also an old problem that continues to cause damage: reusing passwords between personal and work accounts. It is often normalised, incorrectly.
An undocumented webhook sending abnormal data volumes to an external endpoint is a classic signal of possible exfiltration. Similarly, an automation handling sensitive data without an identified business owner creates direct exposure. Nobody is accountable for it, so nobody monitors it closely.
On the supplier side, some gaps should trigger an immediate warning:
This kind of weakness shows that a third-party link can fail and pass the problem on to the rest of the chain. In 2025, more than 48,000 new CVEs were published [3][1]. These signals feed directly into the governance controls described in the next section.
Reducing SaaS exposure comes down to three straightforward actions: map in real time, limit access and monitor continuously. These controls address OAuth abuse, risky extensions and poorly understood automations.
Without a living inventory, there is no solid governance. The inventory must cover approved applications, Shadow IT, Shadow AI, active OAuth permissions, extensions, APIs, automations and supplier dependencies.
Every connection should have an identified owner and a clear business purpose. Otherwise, access quickly accumulates, integrations are forgotten and nobody knows who should respond when a problem occurs.
The inventory must also include the supplier's indirect dependencies: cloud, AI and subcontractors. This level of mapping makes it possible to assess the real geopolitical risk of a third-party dependency [3][2].
Once the connections are visible, rights can finally be reduced to the strict minimum. Put simply: stop handing out a master key when a single key is enough.
Once the inventory is in place, policies can be based on facts rather than assumptions. The principle is simple:
The same applies to limiting persistent sessions and revoking overly permissive grants on sensitive accounts.
Permissions should then be reviewed whenever usage drifts or the supplier changes. An access path that was acceptable at the start can become a weakness a few weeks later.
Governance does not end with the initial approval. The priority is to track changes in behaviour, shifts in the supplier's security posture and critical dependencies.
When a signal falls outside the norm, the team can act without waiting: restrict, remediate or revoke. This is where continuous monitoring proves its value. It prevents issues from being discovered too late, after the damage has already been done.
These controls provide the basis for governance that is automated, clear and usable day to day.
Turning the idea into action requires a platform that connects inventory, policies and detection. Each control helps on its own. Together, they become much more useful. Their value depends above all on one point: covering the entire SaaS ecosystem. Avanoo brings these building blocks together in one framework.
Avanoo correlates authentication data, browser activity and proxy logs to create a real-time map of SaaS and AI usage [8]. This is not limited to applications already visible in the inventory.
The platform also maps indirect dependencies — subcontractors, cloud providers and AI providers used by each third-party tool — and then assigns a two-level sovereignty score: level 1 for the software being used, and level 2 for subcontractors and AI infrastructure [7][2].
For organisations subject to the GDPR, NIS2, DORA or the AI Act, this documentation helps during audits and brings critical dependencies to light more quickly.
The same approach can then be applied to actual data and browser activity.
Avanoo detects risky behaviours that perimeter tools do not see: file uploads and downloads, clipboard activity, dragging and dropping into unapproved applications, and password reuse between applications [9][10].
For browser extensions, Avanoo analyses requested permissions, publisher reputation and known vulnerabilities on Chrome, Edge and Firefox. The platform then assigns a security score to each extension [5][6].
The SaaS supply chain creates very concrete attack vectors. To reduce exposure, three things matter more than the rest: an accurate inventory, the principle of least privilege and continuous monitoring.
In practice, this means applying controls to the main SaaS risks.
| Risk type | Observable indicator | Governance response | Avanoo support |
|---|---|---|---|
| Risky browser extensions | Excessive permissions | Review, approval or blocking | Cross-browser inventory and security score for each extension [5][6] |
| Hidden supplier dependency | Undocumented subcontractors or third-party AI | Third-party risk and data-flow assessment | Supplier-chain mapping and sovereignty score [7] |
| User exfiltration | Uploads, downloads or drag-and-drop into unmanaged applications | Usage controls, awareness and investigation | Behavioural monitoring and visibility into data flows [10] |
| Credential reuse | Password reuse between applications | Identity hygiene and policy enforcement | Detection of risky behaviour through the browser extension [9] |
| Shadow IT / Shadow AI | Unreferenced applications or AI connections | Risk-based inventory and approval | Real-time mapping, authentication correlation and proxy-log analysis [8] |
::: faq
To prioritise SaaS and AI risks, start with the operational reality: the criticality of business processes on one side, and a complete map of actual usage on the other.
The idea is simple. A tool is not risky merely because it is new or unfamiliar. It becomes risky when it touches a critical process, handles sensitive data, depends on other building blocks or falls outside the intended framework. This is where Shadow IT and Shadow AI can create problems: they are adopted quickly and then end up supporting activities that matter.
Start by identifying critical functions — those where an outage, malfunction or data breach would have a direct impact on the business.
Then create a clear map of the existing environment. It should cover:
Next, assess each tool using concrete criteria: its criticality, the data it handles, its hosting model, its dependencies and compliance. This cross-check makes it clear which uses require immediate action and which can wait.
The right approach is to address high risks affecting critical processes first. Then track the gaps in a dashboard to maintain a clear view of what needs fixing, what is under control and what is drifting. :::
::: faq
Start with access to sensitive SaaS applications, as well as access relying on weak authentication protocols, following a Zero Trust approach.
Also review:
::: faq
Adopt continuous, centralised monitoring of your SaaS ecosystem to identify abnormal behaviour, unauthorised access and configuration errors.
Use SaaS governance tools to catalogue applications and their integrations, examine the permissions granted to third-party applications, track indicators of compromise in real time, and regularly check suppliers' risk scores and certifications. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois is Shadow AI Expert and Chief AI Officer at Avanoo. An HEC Paris graduate and former BCG consultant, she helps enterprises detect and govern Shadow AI and Shadow IT.
See how Avanoo can map your SaaS and AI landscape, reduce risk, and optimize costs. A reliable platform with dedicated human support.
