Anatomy of a SaaS Supply-Chain Attack

The anatomy of a SaaS attack starts with a grant you already approved. An attacker does not phish a user or crack a login. They compromise a vendor, integration, or AI agent that already holds a live OAuth token to your Salesforce, Google Workspace, or Microsoft 365 tenant, then inherit the trust you extended months ago. The break-in happens outside your perimeter, so your first-party controls stay quiet.

The mechanics are simple. A third-party service (a marketing tool, a chatbot, a data-enrichment vendor, an agent platform) is breached. Attackers pull the OAuth tokens that vendor stores for its customers, sometimes thousands in one grab. Each token maps to a scope a real customer granted at install and never revisited.

What a single-half tool sees

• Identity and access tooling: nothing. No human logged in, no MFA prompt, no anomalous session.
• Network tooling: nothing unusual. The vendor's IP range is already allowlisted, and the calls arrive from the expected source.

What correlating both halves sees

• The token is being exercised from a new geography and at a new tempo, daily reads replaced by sudden bulk pulls.
• The granted scope (read all opportunities, for example) is finally being used to its full extent, in a way this vendor never touched before.
• The activity ties back to a specific service account inside the app and the specific objects it read, not to the vendor's theoretical config page.

That last line is the whole game. A configuration view tells you the integration is allowed to read opportunities. Runtime truth tells you the integration's service account just read every opportunity in the tenant at 3 a.m. from an IP it has never used. Only the second view is a signal.

Once an attacker holds the token, they hold persistence that survives every human-focused control you own. OAuth tokens are bearer credentials: possession equals authorization. Rotating a user's password does not touch them. Disabling the human who first clicked "allow" does not touch them either.

Why they linger:

• Refresh tokens can extend access for months, sometimes longer.
• Non-human identities do not trigger MFA.
• Revocation requires knowing the token exists and knowing it is compromised.
• Most teams have no inventory of which vendors, agents, and integrations hold which grants.

What a single-half tool sees

• Identity governance: the human who granted consent is still active, and no lifecycle event fired.
• SaaS audit logs: the integration keeps calling the API under the same client ID it always used.

What correlating both halves sees

• The identity is exercising scopes it never used in months of prior activity.
• Its refresh pattern shifted: a different interval, source, or user agent.
• A vendor's disclosed breach window overlaps with this identity's activity in your tenant.

This is where machine insider risk stops being abstract. The token behaves like a badge. Whoever holds it walks past your access controls, because those controls were built for people. The unit of persistence is not a session you can kill from the IAM console. It is a grant tied to a service account and its effective access inside a specific app.

Now the attacker pivots. Using the first token, they enumerate what the compromised integration or agent can reach, then walk the chain of connected apps. No exploit, no malware, just legitimate integrations linked end to end.

A typical path:

• The compromised integration owns a service account inside Salesforce.
• That service account was granted reach into Slack through a connector.
• Slack holds links to Drive documents that carry embedded credentials or API keys.
• Each hop is a sanctioned connection.

AI agents accelerate the whole sequence. An agent built in maker mode carries its creator's admin authority, so an invoker with a low-privilege token can trigger an agent that acts with high-privilege rights. Agent A calls tool B, which fires agent C in another platform. The chain crosses trust boundaries faster than a human ever could, and it moves far more data while doing it.

What a single-half tool sees

• SaaS-native logs: ordinary activity inside each app. No single app sees the full chain.
• Data-movement tooling: no data leaving the corporate network, because everything is SaaS to SaaS.

What correlating both halves sees

• The full path: which token started the chain, which agents it invoked, which apps it touched, and which objects and actions it reached at every hop.
• The confused-deputy pattern, an agent using elevated permissions on behalf of a principal that has no right to them.
• Toxic combinations, like a shadow agent with org-wide access holding a token from a vendor already under disclosed breach.

This is where teams lose the most ground. A configuration snapshot proves the integration exists and lists what it could do. Runtime evidence shows the sequence it actually ran across service accounts and objects. Only the second view exposes the lateral chain.

The final stage is the payoff: bulk export, privilege escalation, or destructive action inside a core app. The attacker uses the same API calls a legitimate integration would, at a scale and shape that only reads as malicious if you know what normal looks like for that specific non-human identity.

Common patterns:

• Bulk export of opportunity records or contact lists.
• Enumeration of Drive documents that match sensitive keywords.
• Extraction of labeled files through an agent's inherited permissions.
• Harvesting API keys from documents, then pivoting toward cloud infrastructure.

What a single-half tool sees

• API gateway logs: standard REST calls with valid authentication.
• Data-movement tooling: transfer between two sanctioned apps.
• Endpoint tooling: nothing, because no human endpoint is involved.

What correlating both halves sees

• Call volume from this identity running well above its own baseline.
• Records whose data classification sits outside the integration's documented purpose.
• An agent's runner (the human or system invoking it) with no business reason to reach these records.
• Effective access, meaning what the identity actually did inside the app, exceeding the theoretical configuration it was supposedly restricted to.

The gap between effective access and theoretical configuration is the exfiltration itself. The config page said "restricted integration." The runtime record shows a service account that read 40,000 customer records it had never queried before. One of those is evidence. The other is a promise.

The reason this attack works is structural, not clever. Every stage falls into a seam between the tools most enterprises already own.

Configuration-based tools confirm the integration exists. Runtime tools show what it did. Neither half alone catches the chain, because the chain only appears when you correlate a non-human identity's grant with the effective access it exercised inside each app.

The documented pattern: UNC6395 and Salesloft Drift

The clearest reference is the UNC6395 activity against the Salesloft Drift integration, which reached roughly 700 organizations from a single compromised third party. It maps onto all four stages and shows exactly where each one hid.

Attackers reached downstream Salesforce tenants through the integration's legitimate OAuth access (Stage 1). Those grants persisted quietly across the affected organizations, none of which knew until public disclosure (Stage 2). The activity queried customer data using the integration's normal API access, and in places reached toward connected apps (Stage 3). Records were pulled through traffic that looked identical to expected integration behavior (Stage 4).

Most affected organizations learned of the breach through vendor disclosure rather than their own tooling. The tokens were legitimate and the traffic matched expected patterns, so routine SaaS audit reviews had no reason to flag it. That is the lesson in one sentence: without correlation between identity and behavior, there was no signal to find.

The chain has a cut point at every stage, but each one depends on runtime truth about your agents, integrations, and their effective access, not a configuration snapshot.

Cut point 1, at issuance. Keep a live inventory of every OAuth grant, integration, agent, and MCP server. Route new grants through a governance workflow. Kill orphaned agents whose creators are disabled.

Cut point 2, at persistence. Correlate vendor breach disclosures against your integration inventory. Rotate tokens for any vendor inside a disclosed window. Flag identities exercising scopes they have never used.

Cut point 3, at lateral movement. Detect action chaining across platforms. Watch for the confused-deputy pattern where a low-privilege invoker triggers a high-privilege agent. Flag toxic combinations such as a shadow agent with org-wide reach.

Cut point 4, at the in-app action. Put deterministic guardrails on probabilistic agents so behavior outside an agent's documented purpose gets stopped, and alert on bulk pulls that break normal patterns.

A word on how enforcement actually works, because vendors overstate this constantly. Obsidian does not sit inline as a gateway. It supplies the decision, an Intel Inside model that scores an action against the identity's effective access, and the platform carries out the verdict. That runtime enforcement is live today for Claude and Microsoft Copilot. For Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, and n8n, the current capability is discovery and governance: full inventory, effective-access mapping, and policy, with autonomous enforcement on the roadmap rather than in production.

The earlier you cut, the smaller the blast radius. But no cut point functions without visibility into effective access, and that comes from runtime evidence, not a config page. The teams that stop chasing configuration ghosts and start operating from runtime truth are the ones that measure detection in hours instead of months.