SaaS-to-SaaS integrations: the access pathways nobody approved

a saas app is not an island

Think about how a record moves through a typical mid-market company. A lead comes in through a web form, a marketing tool captures it, an automation platform copies it into the CRM, the CRM enriches it from a data provider, posts a notice into a chat channel, and creates a task in a project tool, and when the deal closes a billing app picks it up and a reporting tool pulls the numbers into a warehouse for a dashboard. That one record crossed seven or eight applications, and a person touched almost none of those handoffs. Each handoff runs on a connection set up once and now running on its own, and each connection is a standing grant: one app holds permission to read or write inside another, whether or not anyone is using the workflow today. This is normal, and most of it is useful. The point is not that the connections are wrong. The point is that they form a web of access that almost nobody has mapped, grown one connection at a time.

how these connections are made

There are three common ways one SaaS app comes to hold access inside another. App-to-app OAuth grants are the most common pattern: inside one SaaS app, someone connects a second app, which asks for permission to do specific things, read contacts, read and write deals, post messages, and someone clicks Allow and the second app receives a token. That token is standing access into the first app, scoped to whatever was requested, held until someone revokes it. Native integrations inside a SaaS product come from an integrations directory or marketplace: you find a connector for another tool, turn it on in a few clicks, and the two products are wired together through a connection the vendor built, easy to enable without anyone outside the team knowing it now exists. Integration and automation platforms, sometimes called iPaaS, and the no-code automation tools alongside them, concentrate the most access in one place, because to move data between many apps the platform holds credentials to every app it touches. One automation account can carry connections to your CRM, mailbox, file store, finance tool, chat platform, and more, all at once. In every case the mechanics rhyme: a connection is made, a scope is granted, and the access persists. What changes is where the connection lives and how broad it is.

why this is the least-governed layer

Several things line up to make SaaS-to-SaaS access the part of the stack that gets the least attention, and none of them are anyone's fault. A team sets it up, not IT: the connection is made by the people who need the workflow, inside a SaaS app's own settings, in a few clicks, with no ticket and no review, and IT often learns the integration exists only when something breaks. It persists after the person and the project are gone: the workflow keeps running because it was wired into the app, not into anyone's daily attention, and disabling the builder's user account frequently leaves the integration's access intact, because the access lives at the connection, not at their login. The scopes are often broad, because the path of least resistance is to grant the access the connector asks for, which is often read and write across more than the workflow needs. And an automation hub is a single high-value target: the platform that holds credentials to ten apps is one account that, if compromised, reaches all ten. The result is a growing web of standing access, set up outside IT, surviving the people who built it, scoped more broadly than needed, with one or two hubs that touch almost everything.

the risk in plain terms

Strip away the mechanics and the risk is simple to state. First, data moves between your apps along pathways that nobody approved and nobody monitors. A record flows from one system to another because a connection was wired months ago, with no list of those flows, no owner watching them, and no log that anyone reads. Second, a compromise of one connected app or of the automation hub reaches everything that app or hub touches. If an attacker takes over an app that holds a write connection into your CRM, they have a path into the CRM; if they reach the automation platform that holds credentials to a dozen systems, they have a path into all twelve. The blast radius of any single compromise is that app plus everything it connects to. This is not a fringe concern: third-party involvement appeared in 48% of breaches, up from 30% a year earlier, according to the Verizon Data Breach Investigations Report 2026. A SaaS-to-SaaS connection is one of the most direct forms of third-party access into your data, and the same logic applies when one of the connected actors is an AI tool.

how to find these connections

You can build a clear picture of this layer with the admin tools you already have, plus a few conversations. The work has three parts, and you need all three because no single source sees everything. Review the OAuth grants your core apps have issued: start at your identity provider, Google Workspace or Microsoft Entra, which shows the third-party apps connected to your directory and their scopes, then go into each core SaaS app, the CRM, help desk, file store, chat platform, and open its own connected-apps or integrations settings, capturing for each connection what app is on the other end and what it can read or write. Inventory the automation-platform connections and their scopes: if you run an integration platform or a no-code automation tool, this is where the most access is concentrated, so list every connection it holds and note which app it reaches and whether it is read-only or read-write. Ask the teams what they wired together: some of the picture lives only in people's memory, so ask the revenue, support, marketing, and operations teams which tools they connected, treating this as a primary source. A note on honesty: some integrations live entirely inside a SaaS app's own settings and never appear at the identity provider, because they were never a directory-level OAuth grant, which is why the per-app review and the team survey are not optional extras.

how to govern it

Once you can see the connections, governing them is the discipline you already apply to other access, pointed at this layer. Keep an inventory of the integrations and what each can reach: a simple table, one row per connection, with the two apps it joins, whether it is read-only or read-write, what it is for, and who owns it; without it, you are governing from memory, and memory does not survive a departure or a year. Apply least privilege to the scopes: for each connection, ask whether the access matches the job, and where a connection offers read-only and read-write versions and the workflow only reads, choose read-only, which is the single most effective way to shrink the blast radius. Give every integration an owner, the person accountable for that connection continuing to exist and hold access, because a connection with no owner is the one that survives the project and turns into standing access nobody can explain. Set a review cadence: a quarterly look at the automation platform and the highest-access connections, with a half-yearly pass over the rest, and tie a connection check into offboarding. Define a decision path for new integrations: a simple, fast way to request one and get a quick decision, paired with a light review of any connection that asks for write access to a core system. And treat the automation hub as a privileged identity: know exactly what it connects to, keep its connections to minimum scopes, rotate its credentials, and know who owns it. None of this requires a new product; it requires a list, a few decisions per connection, and a cadence to keep the list current.