In many companies, SaaS integrations are approved as if they were “automations”: connecting GitHub with Slack, syncing Notion with the IdP, giving an AI assistant access to the corporate drive, or enabling a bot to create tickets from a channel. The problem is that, in practice, you are delegating security decisions (and part of observability) to a third party that operates outside your direct control.
The risk is rarely in the “main SaaS” that you already govern with SSO and policies, but in the ecosystem of connected apps: personal tokens that survive employee departures, overly broad scopes granted for convenience, and permissions that get inherited to more sensitive data as the organization grows. When something goes wrong, the incident does not look like a “SaaS hack”, but a broken chain of trust caused by an integration.
Real attack surface: the chain of trust that almost nobody maps
A SaaS integration introduces a new trusted subject with the ability to act on your behalf. In operational terms, that usually materializes as OAuth (scopes), access tokens (sometimes without short expiration), inbound/outbound webhooks and, in some cases, static API keys. Each piece opens a channel for exfiltration or remote action, even if the base SaaS has impeccable MFA and SSO.
In companies, the same pattern is often seen: a “productivity” app is connected to GitHub to generate summaries, then it is enabled for access to issues and PRs, and over time it ends up reading entire private repos because “otherwise, it fails”. In parallel, the same vendor integrates with Slack for notifications and ends up having access to message history or to files shared in channels. The result is a lateral path from an external app to critical assets without going through the usual network controls.
- Tokens and scopes as a “perimeter”: an OAuth with broad scopes is, in practice, equivalent to service credentials. If the token leaks (logs, CI, a laptop), the external app stops being an “integration” and becomes an actor that can read or write corporate data.
- Webhooks as an entry channel: poorly validated webhooks (no signature, no IP allowlist when applicable) allow injecting fake events. In real incidents, this ends up in automations that open tickets, trigger pipelines, or post messages with malicious links “with the integration’s seal”.
The difficulty is not conceptual: it is truly inventorying what is connected, with what permissions, and what data it touches. Without that map, the SOC chases symptoms (access alerts, changes in repos) without seeing that the origin was an authorized and “legitimate” app.
When the “legitimate” is the problem: forgotten tokens and inherited permissions
The hidden risk appears when access persists beyond its need. In GitHub, for example, a personal access token (PAT) created for a test can stay alive for months; in Slack, an app installed in a workspace can retain capabilities even if the user who authorized it is no longer there; in Notion or other wikis, integrations with access to entire spaces keep working even after the project has ended.
In corporate environments, staff turnover and delivery pressure normalize “temporary exceptions”. The problem is that temporary is rarely reverted. A typical example: an external vendor asks for access to a repository to integrate deployments; it is granted with broad scopes “to avoid blocking”, and that token ends up circulating among teams (or being stored in the vendor’s secrets manager). If one day that vendor has an incident, your exposure is not theoretical: the attacker enters with a valid credential and permitted actions.
There is also a silent effect: permissions become more dangerous over time. An integration that initially only saw a “utilities” repository may end up seeing sensitive information because the repository is reused for configuration, example credentials, or internal scripts. The authorization did not change; what changed was the value of the accessible data.
How to do it in practice: auditing integrations in GitHub, Slack and Notion (without relying on “feelings”)
Auditing integrations is not reviewing a list once a year; it is establishing a repeatable process with evidence. The first step is to inventory all authorization paths: OAuth apps, GitHub Apps, personal tokens, webhooks, and third-party connections. The second is to classify by real scope (what it can read/write) and by the criticality of the data touched. In companies, this becomes actionable when you turn it into a backlog with owners and dates.
GitHub (org/enterprise): review installed GitHub Apps and their permissions, authorized OAuth apps and, if applicable, PAT usage. In mature organizations, “OAuth app restrictions” are enforced and only an allowlist is allowed. Operationally, look for integrations with write permissions in repos and access to private content; they are usually the ones that turn a leak into an integrity incident (malicious commits, workflow changes, dependency modification).
- Concrete action: enable OAuth app restriction and require admin approval for new apps. Then review already approved apps and reduce permissions or replace them with GitHub Apps with finer permissions. This reduces the risk of OAuth’s typical “generic scopes”.
- Validation: verify in GitHub logs/audit (Audit Log) that there are no new installations without an associated ticket, and correlate app access events with sensitive repositories. If an app touches repos it shouldn’t, it’s not a debate: it’s a finding.
Slack (workspace/enterprise grid): inventory installed apps and their permissions, especially those with access to private channels, message reading, file downloads, or administration capabilities. A frequent case: “archiving” or “search” apps that end up having access to files that contain operational secrets (screenshots, exports, logs). The consequence is usually silent exfiltration, hard to detect by DLP if the output occurs via an authorized API.
Notion (and similar wikis): review integrations that access entire spaces. The usual mistake is granting access “to the whole workspace” because the product suggests it to work better. In a company, that is equivalent to giving a third party access to runbooks, architecture diagrams, incident response procedures and, in the worst case, credentials pasted into an old page.
Abuse scenarios seen in companies (and why traditional controls don’t stop them)
The most damaging abuse is usually the one that does not trigger alerts: actions performed by an authorized app with valid credentials. If your defense is oriented toward detecting suspicious logins or anomalous IPs, an integration operating via API can pass as “normal noise”. The attacker doesn’t need to break MFA; they need a token, a webhook secret, or to compromise the vendor that runs the integration.
In real incidents, the most repeated scenarios combine persistence and low friction. For example: a token with broad scopes allows reading private repos and extracting code; then, the attacker modifies a CI workflow to add a secret-exfiltration step; finally, they use Slack to move socially, sending messages from a bot that looks legitimate. All of this can happen without a single interactive “login”.
- Data exfiltration via API: an app with read access to channels or documents can download content incrementally to avoid spikes. In practice, it is detected late because the pattern looks like a normal “sync”.
- Integrity manipulation: integrations with write permissions (repos, wikis, automations) allow introducing changes that then propagate through internal processes. In companies with fast CI/CD, a small change in a pipeline can become a deployment with altered code.
Network controls (proxy, partial CASB) help, but they do not replace permissions governance. When the outbound channel is a legitimate API to an approved vendor, the key question is: why did that app have that scope and why was nobody reviewing it?
Recommendations for corporate environments
SaaS integrations are not “auxiliary tools”: they are extensions of your identity and your data. The hidden risk appears when security is delegated to third parties without a complete inventory, without permissions governance, and without evidence of real use. What most reduces incidents is not banning integrations, but making them operable: knowing what exists, what it can do, and who is accountable for it.
If I had to condense it into corporate practice: a living inventory of integrations, systematic scope reduction, token expiration/rotation, and a review based on audit logs (not on the vendor’s statements). From there, any integration that does not have an owner, justification, and minimum permissions stops being “automation” and becomes security debt ready to be exploited.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.