SaaS Supply-Chain Attacks in the Agent Era

A SaaS supply chain attack is a compromise that reaches your data through a third-party application, integration, OAuth grant, or AI agent that your SaaS platforms already trust. The attacker never has to breach you directly. They compromise one node in the trust graph, then use its inherited permissions to move. Salesforce, Google Workspace, or Microsoft 365 sees a valid bearer token, honors the request, and the activity looks identical to normal integration traffic.

The classic software supply chain image is a poisoned update flowing from vendor to customer. The SaaS version looks different. Nothing gets installed on an endpoint. Instead the attacker abuses a credential that a legitimate integration already holds. If your incident response plan assumes the attacker has to authenticate as one of your users, it does not cover this class of attack at all.

The real supply chain today is the set of non-human identities you have already authorized: OAuth apps, service accounts, marketplace add-ons, workflow automations, MCP servers, and agents built inside platforms like Copilot Studio, Agentforce, and Bedrock. Each holds a credential, and each credential carries some slice of your data access. The supply in supply chain is not code anymore. It is authority, handed to a third party through a single consent screen that nobody reviewed closely.

Three shifts define the era:

• From code to credentials. The payload is a token, not a binary.
• From vendors to grants. The unit of trust is an OAuth grant or agent connector, not a signed vendor package.
• From humans to machines. Non-human identities now outnumber human ones by a wide margin in most enterprises, and AI agents are the fastest-growing category of all.

AI agents widened the blast radius because they hold credentials like insiders, act across multiple SaaS platforms without a human in the loop, and inherit permissions their invokers do not have. One agent, one token, dozens of downstream apps.

Walk through a modern agent chain. A user asks a Copilot Studio agent to summarize sales activity. The agent calls a Salesforce connector running in maker mode under its creator's admin credentials. It then calls an MCP server that queries a Google Drive folder. The user, who has no Salesforce license and no access to that folder, receives the compiled result. Nothing was hacked. Every step was authorized. The user just walked out with data your IAM never granted them. That is machine insider risk, and it happens at machine speed.

A few numbers set the scale. AI agents move roughly 16 times more data than human users across enterprise deployments. Around 90 percent of agents hold more permission than their actual workflow needs. And a single abused bearer-token class in the 2025 Salesloft Drift campaign reached roughly 700 organizations.

The mechanisms that compound access

• Maker mode. The agent runs with its creator's credentials, not the invoker's. It bypasses IAM by design.
• Action chaining. Multi-step tool calls stack access. Each hop widens the blast radius.
• Agent-to-agent handoffs. A narrow agent delegates to a broad one, and data escapes the intended boundary.
• Orphaned agents. The creator's account is disabled, but the agent keeps running on inherited credentials.
• Shadow MCP servers. Tools exposed through unregistered endpoints stay invisible to configuration audits.

The traditional attack compromises code that customers install. The SaaS-to-SaaS attack compromises a live token that customers already trust. Different mechanism, different detection surface, different response clock.

That difference reshapes detection. Direct attacks tend to trip authentication alerts: unusual logins, MFA prompts, geo anomalies. A supply chain attack through OAuth tokens and agents looks like ordinary integration activity. The token was issued legitimately, the API call is signed correctly, and your SIEM sees expected traffic. Teams that tune detection around user login anomalies miss it, because the attacker never logs in as a user.

It also separates cause from outcome. A data breach is the outcome. A supply chain compromise is one of the mechanisms that produces it. Every organization caught in the Drift campaign experienced a breach, but the upstream cause was a third-party integration compromise, which is exactly why these events are so often underreported. The company that suffers the loss was not the company that got attacked first.

The effective-access problem is the gap between what an agent, app, or token is configured to do and what it can actually accomplish once it starts calling into your stack. Posture-only tooling sees the configured side. Attackers, and over-privileged agents, exploit the real one.

Make it concrete. A Copilot Studio agent's configuration shows a Salesforce connector with a specific set of OAuth scopes. That is the theoretical configuration. The runtime reality is that the connector runs in maker mode under an administrator's fixed credentials. When a lower-privileged user invokes the agent, the token used against Salesforce carries the admin's authority, and the user reads records they were never provisioned to see. No connector audit catches this. The OAuth scopes were correct. The Salesforce role was correct. The identity substitution happened inside the agent runtime.

This is why the useful signal is not the vendor's theoretical config page but the agent's effective access inside the third-party app. The question that matters is narrow and answerable: when this agent acted, which service account did it use, against which Salesforce objects, tables, or Drive folders, and with which actions. Correlate the invoker to the credential to the objects touched, and you can tell an authorized summary apart from a quiet extraction. Runtime truth beats theoretical configuration every time, because effective authority is the only version an attacker can actually spend.

Legacy third-party risk management goes blind because it evaluates vendors at procurement, not integrations at runtime. CASB goes blind because it inspects user-to-SaaS traffic, not the SaaS-to-SaaS API calls between installed apps. Both predate the OAuth-and-agent stack, and neither was built to answer the operational questions that matter now:

• Which OAuth apps are currently installed across every tenant?
• Which of those apps hold sensitive scopes they never actually use?
• Which agents run in maker mode with admin-inherited credentials?
• Which MCP servers are reachable from those agents, and what tools do they expose?
• When a token calls the API, is the requester supposed to have that authority?

A questionnaire filed two years ago answers none of these. The blindness is structural, not a tuning problem, because the platforms are built to be extended.

Why the attack class keeps working

• OAuth consent is a one-time gate. Users approve broad scopes once, and no one reviews what the app does with them afterward.
• Bearer tokens are trust-by-possession. Hold the token and the platform assumes you belong.
• Marketplaces remove friction. Business users install connectors and agents with no security review.
• Native audit logs are messy. Every platform logs differently, in different places, at different fidelity, and correlating them by hand does not scale.

The highest-exposure platforms are the ones holding valuable data with the largest extension ecosystems, and where low-code builders let business users create connectors on their own. Risk tracks three factors: data sensitivity, the number of installed OAuth apps, and the presence of maker-style agent builders.

Discovery-first collapses the response clock from months to hours, because you already know which agents, connectors, and grants existed before the incident. Forensics without a pre-existing inventory is archaeology. The Drift case shows it plainly: organizations that kept a current inventory of installed Salesforce-connected apps could scope their exposure the day disclosure landed. Organizations without one spent weeks reassembling the picture from native audit logs.

A workable sequence puts visibility first and keeps the harder controls downstream:

1. Inventory every non-human identity. OAuth apps, service accounts, agents, MCP servers, workflow connectors, including the shadow ones.
2. Map effective authority. For each identity, resolve what it can actually reach inside each app, not what its configuration claims.
3. Retire orphaned and unused grants. Any token tied to a disabled account, or unused for 90 days, is a candidate for revocation.
4. Flag toxic combinations. Maker mode plus org-wide reach plus a sensitive scope is your critical queue.
5. Right-size agent scopes. Restrict grants to the actual workflow.
6. Govern with runtime evidence. Configuration snapshots do not survive contact with a real incident, so keep behavior, not just settings.

If a compromise is suspected, revoke first and investigate second, and treat the token as the identity. Revoke the suspected integration's OAuth tokens across affected tenants, rotate any service account or connector credentials tied to the vendor, pull the runtime log of every API call that token made, and map which agents and downstream apps depended on it. Standard user-account playbooks miss the machine identity entirely.

Autonomous, inline blocking of agent activity is still emerging, available today only for a narrow set of platforms and on the roadmap for the rest. That is why the near-term work is discovery and governance, not enforcement promises. Obsidian's model is deliberately not an inline gateway sitting in the request path. It is a decision layer, an Intel Inside approach, that gives you a connector-free view of every AI agent, OAuth grant, and MCP server across your SaaS fabric, with effective authority mapped for each. The payoff is what you can tell the board: not we think we are okay, but here is every agent, connector, and token that touched customer data this quarter, and here is what each one did. Configuration is not reality. Runtime is.