Fourth-Party and Integration Breach Risk

Fourth party risk is the security exposure your organization inherits from the vendors your vendors depend on. Third party risk is exposure from a company you hold a direct contract with. Fourth party risk sits one hop further out: the sub-processors, integration partners, and AI services your third party pulls in, none of which you onboarded and some of which you cannot name. In a modern SaaS stack, fourth party risk is where visibility collapses and where recent breaches now concentrate.

The distinction matters because your controls stop at the contract boundary. Once data flows from your tenant into a third-party app, and that app connects onward to an enrichment service or an AI model, your access reviews, data loss policies, and identity controls no longer reach it. The integration runs on inherited trust.

A quick way to place the parties:

• First party: your company.
• Second party: your customer.
• Third party: the CRM you signed a contract and a data processing agreement with.
• Fourth party: the conversational or marketing app that connects to that CRM over OAuth and processes the data with its own sub-processors.
• Fifth party and beyond: the AI models, tool servers, and enrichment APIs that fourth party depends on.

The trust chain lengthens at every hop, and each hop inherits the credentials of the one before it. That inheritance is the whole problem.

Security teams keep completing vendor questionnaires, and breaches keep arriving through vendors those questionnaires marked as fine. The problem is not the questions. It is the format.

A questionnaire produces a snapshot of intended configuration on a single day. Meanwhile the real integration is granting fresh OAuth scopes, provisioning new service accounts, and picking up AI agents that reach data the original assessment never covered. Reviewing static answers with no evidence of current behavior is chasing ghosts. You are grading a promise, not observing a runtime truth.

Here is what a questionnaire cannot tell you:

• Which OAuth scopes are active in production right now, versus the ones described at signing.
• Which AI agents have inherited the vendor's connection, and under whose identity they run.
• Which service accounts are still enabled after the person who created them left.
• What data has actually moved through the integration in the last 30 days.
• Whether undisclosed sub-integrations, the fourth and fifth parties, are quietly in the path.

A SOC 2 report confirms that a vendor has a control program. It says nothing about whether your specific integration is over-permissioned today. That gap between attested posture and lived behavior is exactly where a machine insider operates: a non-human identity with standing access, trusted by default, watched by no one.

Fourth party breaches happen because SaaS-to-SaaS integrations form long chains, and every link accepts the credential of the previous link without re-checking who is really holding it. A typical chain runs like this:

1. A user grants OAuth access from the CRM to a third-party app.
2. The app stores a bearer token carrying broad CRM scopes.
3. The app connects to its own sub-processors, including AI enrichment services.
4. Those services call downstream tool servers and model providers.
5. An attacker compromises one node anywhere in the chain and moves laterally using tokens that no system verifies beyond possession.

The dangerous mechanic is the bearer token itself. A bearer token assumes that whoever presents it is authorized, with no continuous check on who is actually behind the request. In the UNC6395 / Salesloft Drift campaign, stolen integration tokens let attackers pull data across roughly 700 organizations, and the malicious traffic looked identical to legitimate integration traffic. Defenders could not tell the difference because, at the token layer, there was no difference.

AI agents raise the stakes. An agent built with fixed admin credentials operates at that admin's authority for every user who invokes it. When a downstream vendor's agent chains to that agent, the whole fourth-party path now runs at admin privilege, and no identity control is positioned to see it. This is the machine insider pattern at chain scale: an agent moving far more data than any human would, across a blast radius that no one has mapped. The pattern in the public incidents is consistent. The compromise lands at a node the victim never directly managed, and the victim learns about it from someone else.

Static third-party risk management captures a vendor's posture once a year. The direction the discipline is moving, often called dynamic TPRM, treats the integration itself as the risk object and watches its behavior over time. To be clear, dynamic TPRM is not a shipped product category with a tidy box to buy. It is a direction of travel, and the teams getting ahead of fourth party risk are instrumenting their integrations for runtime evidence rather than requesting more paperwork.

The shift changes what you measure:

Regulation is pulling in the same direction, though depth varies and you should verify the current text of anything you cite. Frameworks such as DORA in the EU push financial entities to manage sub-outsourcing chains, and AI-specific guidance under NIST's AI Risk Management Framework and ISO/IEC 42001 now speaks to third-party components and supply-chain considerations for AI systems. None of these tell you how deep to go into the chain. Compliance requires that you run a program. It does not make you safe. Safety comes from evidence about actual access.

The right unit of measurement is effective access, not vendor identity. Effective access answers a precise question: given every entitlement, OAuth scope, and inherited credential in the chain, what data can this integration actually reach, and what actions can it actually take?

Compare the two framings. Theoretical configuration says, "this integration has read access to the Contacts object." Effective access says, "this integration, through the AI agent built on top of it, can read Contacts, export them to a fourth-party enrichment service, and write updates back using a service account that a former employee provisioned." One is a checkbox. The other is reality.

Producing effective access means correlating signals that usually live in separate tools:

• The integration's OAuth grants and active scopes.
• Every human and non-human principal that can invoke it.
• Downstream agent connections and the permissions they inherit.
• The specific tool calls the integration can trigger in connected model servers.
• The classification of data it has actually touched, not the data it is theoretically allowed to touch.

This is where an operations-first model earns its keep. Rather than acting as an inline gateway in the data path, the practical approach behaves like an "Intel Inside" decision engine: it correlates an agent's activity to its effective access inside the third-party app, which service account it used, which objects and tables it reached, which actions it took, and renders a verdict the platform can act on. Today that correlation supports discover and govern work across the major agent platforms, and autonomous runtime enforcement is live for Claude and Microsoft Copilot, with broader enforcement on the roadmap rather than shipped. Without this correlation, whatever you are measuring, it is not access. It is paperwork.

Not every integration deserves equal scrutiny. The operating question is blunt: which integrations, if compromised right now, would produce the largest blast radius? Rank by effective access first, then by the presence of toxic combinations that turn an ordinary integration into a standing incident.

The combinations worth flagging before anything else:

1. Integration plus fixed admin credentials plus sensitive data scope. Every user of the integration inherits admin authority over regulated data.
2. Integration plus orphaned owner plus still active. The creator left the company. The token stayed behind.
3. Integration plus public webhook plus no authentication. Anyone holding the URL can trigger it.
4. Integration plus AI agent plus unsanctioned tool server. The agent calls tools you have never inventoried.
5. Integration plus cross-tenant reach plus no logging. It touches multiple environments and leaves no trail.

Any two of these on the same integration is a critical finding. Three is an incident waiting for a trigger.

Where to start when you cannot audit your vendors' vendors

You usually cannot inspect a fourth party directly, but you can inspect the integrations they hold with your systems and infer risk from what those integrations touch:

1. Enumerate every OAuth grant across your major platforms and list the third parties and scopes each holds.
2. Ask each vendor for a current sub-processor list and match it against your data classification. Undisclosed processing of sensitive data is a red flag.
3. Inventory the AI agents connected to those integrations, noting fixed-credential configurations, org-wide access, and disabled owners.
4. Review token age and last use. Long-lived tokens with no recent activity should be revoked on sight.
5. Correlate identity to activity: for each integration, which humans and which agents actually invoked it in the last 90 days?

Assign an owner, then compress the window

Fourth party risk usually falls between four teams and gets picked up by none. Vendor questionnaires sit with TPRM, human identity with IAM, SaaS administration with IT, and detection with security engineering, while the integration and its non-human identities sit in the seam. Name an owner for the integration risk register. Extend the identity program to cover non-human identities. Enforce a sanctioned-integration list. You will not drive fourth party risk to zero, and anyone promising that is selling something. The achievable goal is smaller: shrink blast radius, kill toxic combinations, and compress the time between a compromise in the chain and your team knowing about it from weeks to minutes. That is fewer fire drills and evidence that generates itself, which is the point.