Salesforce's Drift-token campaign made OAuth consent an accountability boundary

Summary

• Google Threat Intelligence Group reported that from as early as August 8 through at least August 18, 2025, UNC6395 targeted Salesforce customer instances using compromised OAuth tokens associated with the Salesloft Drift third-party application.
• Salesforce's Trust advisory said Salesloft, working with Salesforce, invalidated active access and refresh tokens and removed Drift from the AppExchange; the issue did not stem from a vulnerability in the core Salesforce platform.
• Salesloft's Trust Center later said Mandiant investigated a suspected intrusion impacting the Drift product and that the investigation assessed root cause, scope, containment, remediation, and segmentation between Drift and Salesloft applications.
• The incident shows that OAuth consent is not administrative background. A deeply permissioned integration can become an access path into customer CRM data, support cases, credentials embedded in records, and downstream cloud systems.
• Accountability follows control. Salesloft controlled the Drift product and token custody. Salesforce controlled platform connected-app governance, AppExchange response, customer notification channels, audit visibility, and emergency token revocation. Customers controlled connected-app approvals and data hygiene, but often only after the platform and vendor made the integration available.

The public timeline begins with delegated authority

Google Threat Intelligence Group's advisory, Widespread Data Theft Targets Salesforce Instances via Salesloft Drift, is the central technical source. GTIG said that beginning as early as August 8, 2025 through at least August 18, 2025, the actor tracked as UNC6395 targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application. GTIG said the actor exported large volumes of data from numerous corporate Salesforce instances and searched for secrets such as AWS access keys, passwords, and Snowflake tokens.

Salesforce's own Security Advisory framed the platform boundary. Salesforce said the incident involved the Drift app published by Salesloft, that Salesloft in collaboration with Salesforce invalidated active access and refresh tokens, and that Drift was removed from AppExchange. The advisory also said the issue did not stem from a vulnerability within the core Salesforce platform. That statement is important and should be preserved. The incident is not evidence that attackers exploited a Salesforce core software vulnerability.

Salesloft's Trust Center later described Mandiant's investigation into a suspected intrusion impacting the Drift product. It said Mandiant was engaged on August 26, 2025 to determine root cause and scope, assist containment and remediation, and verify segmentation between Drift and Salesloft applications. That source is important because it places the investigation at the vendor layer, not only the Salesforce platform layer.

The public response sequence matters. Google and Salesforce describe activity in early to mid-August. Salesforce's advisory says tokens were invalidated and Drift removed from AppExchange. AppOmni's analysis of the Drift-Salesforce breach similarly records that Salesloft and Salesforce revoked Drift OAuth tokens and that impacted organizations were directly notified by Salesforce. Unit 42's threat brief tracks the campaign as compromised OAuth credentials used to exfiltrate data from affected Salesforce environments.

The critical accountability fact is delegated authority. OAuth lets a user or administrator grant an application access to data and actions without sharing the user's password. That design is essential to modern SaaS. It is also dangerous when a third-party app has broad scopes, long-lived refresh tokens, weak token custody, and access to high-value CRM data. The token becomes the authority.

This was not ordinary password theft

Many breach playbooks still assume a human login. Reset the password, add MFA, review login history, and move on. The Drift campaign shows why that is limited public evidence. An OAuth token is not the same as a user typing a password. It can represent a trusted application that already has consent to access data. It can bypass some human login controls because the application is expected to call APIs without a person present.

That does not mean MFA is irrelevant. MFA can prevent initial user compromise and can protect administrative consent workflows. But after a valid app token exists, the important controls are app scopes, token storage, refresh-token lifetime, app review, revocation speed, API monitoring, and data-access anomaly detection. A customer can have good human MFA and still be exposed if a third-party app's token is stolen.

The FBI and IC3 TLP:CLEAR advisory, Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Platforms, warned that UNC6395 used compromised OAuth tokens for the Salesloft Drift application and that the access mechanism differed from other Salesforce-focused campaigns. FINRA's cybersecurity alert on the Salesloft Drift AI supply-chain attack framed the incident for regulated financial firms, saying stolen OAuth authentication tokens allowed threat actors to impersonate the trusted Drift application and gain unauthorized access to customer environments.

Those two advisories show why this was a governance issue, not only a vendor breach. Regulated firms had to examine whether a third-party application had access to Salesforce data, whether secrets were stored in CRM records, and whether customers or prospects had been exposed. The platform and vendor problem became a customer compliance problem.

Salesforce's documentation on connected apps describes the basic model of external applications integrating with Salesforce. Its OAuth documentation for connected apps, including OAuth settings, shows why scopes and policies matter. These documents are not incident evidence. They explain the control surface.

Scopes turned trust into blast radius

OAuth scopes define what an app can do. In a minimal design, an app gets only the access needed for a specific task. In a broad design, it can read or write large classes of records, call APIs, refresh access, and operate across a wide data surface. The Drift campaign asks whether integration convenience had outrun scope discipline.

GTIG reported that UNC6395 systematically queried and exported data from Salesforce environments and searched records for credentials. That means the exposure was not limited to a field list owned by Salesloft. It involved customer Salesforce data accessible through the integration. If a customer had secrets in Salesforce cases, notes, support threads, chat transcripts, custom fields, or attachments, those secrets could become the next stage of risk.

This is a key difference from a breach of a vendor's own customer table. The compromised token let the attacker reach into each connected customer's Salesforce environment. The harm depended on what each customer stored, how its Salesforce org was configured, which entities the app could access, and whether secrets were embedded in records. The same stolen token class could produce different harms across customers.

AppOmni's analysis emphasized SaaS-to-SaaS prevention and the difficulty of visibility across connected apps. Arctic Wolf's security bulletin similarly framed the event around compromised Salesloft Drift OAuth tokens and Salesforce data theft. These sources are vendor analyses, but they reinforce the same control point: SaaS integrations create non-human identities that deserve lifecycle governance.

The term "non-human identity" can sound abstract. In this incident, it means an app credential that can act without a human at the keyboard. It may be approved once and then persist. It may have broad access because broad access makes the integration useful. It may not appear in ordinary user login dashboards. It may outlive the business process that justified it. Once stolen, it can move quickly because API calls are normal for that identity.

The connected app marketplace is part of the control chain

Salesforce's advisory said Drift was removed from the AppExchange pending further investigation. That response matters because AppExchange is not just a directory. It is a trust signal. Customers often infer that marketplace-listed apps have passed a review process and are appropriate to install. The marketplace does not eliminate customer due diligence, but it influences customer choices.

When a marketplace app becomes a campaign access path, the platform's responsibility is not that it caused the vendor breach. The responsibility is that it has to detect, communicate, disable, and help customers recover faster than customer-by-customer discovery would allow. A platform sees app installations across tenants. It can identify which customers installed the app. It can coordinate token revocation. It can notify affected customers. It can remove or suspend the listing. That cross-customer visibility is precisely why platform governance matters.

Salesforce appears to have used that platform role in the public record: its advisory says it worked with Salesloft, invalidated tokens, removed the app, and notified impacted organizations. The accountability question is how fast that happened relative to the first suspicious activity and whether customers had enough log access to determine their own exposure. GTIG reported campaign activity beginning as early as August 8; token revocation was reported on August 20. The public can see the rough interval, but not the internal detection decision process.

Customers also have responsibilities. They choose apps, approve scopes, store secrets in records, monitor API behavior, and review connected apps. But customer responsibility is bounded by platform affordances. If connected-app reviews are hard to understand, if scopes are too coarse, if logs are difficult to access, if token inventory is fragmented, or if marketplace trust is vague, customers make decisions with incomplete visibility.

The incident therefore should not be framed as a simple three-way blame exercise. It is a chain: Salesloft had to protect Drift and its tokens; Salesforce had to govern connected-app trust and emergency revocation; customers had to restrict app access and remove secrets from CRM data; attackers exploited the chain.

CRM data became a secret-hunting surface

GTIG's most disturbing finding was not merely that CRM records were exported. It was that the actor searched for secrets. A Salesforce environment may contain support cases, sales notes, customer onboarding details, technical troubleshooting threads, API keys pasted into tickets, VPN endpoints, cloud-account identifiers, integration credentials, passwords accidentally stored in case comments, or attachments with sensitive operational data. That material should not be in CRM records, but in real organizations it often is.

This shifts the harm from privacy to lateral risk. If an attacker uses a CRM export to find AWS keys, Snowflake tokens, VPN credentials, or other secrets, the breach can move from customer data exposure to infrastructure compromise. The CRM system becomes a map of other systems. It is the place where support teams document problems, and that documentation may include the clues needed to attack the systems being supported.

The public GTIG advisory says organizations should search for secrets and rotate credentials. That advice is operationally expensive because customers have to search their own data for material they should never have stored there. The incident therefore exposes a data-hygiene failure at the customer layer. But the trigger was a trusted integration compromise. Customers may not have realized that a chatbot or revenue workflow integration could reach records containing credentials.

Salesforce and customers can reduce this risk by treating secret scanning as a CRM control. Records should be scanned for key patterns. Support workflows should discourage pasting passwords or tokens. Sensitive fields should be masked. App scopes should not include entities that are not needed. Exports should be monitored. These are not exotic controls; they are practical responses to the reality that CRM systems hold messy operational data.

The risk also explains why customer notification matters. If a customer organization was affected, its security team needed to know quickly enough to search records, rotate exposed secrets, check downstream cloud logs, and warn its own customers where needed. A delayed or vague notice could allow stolen secrets to remain valid.

Revocation was necessary, but it was not recovery by itself

Token revocation closes the immediate delegated-access path. Salesforce's advisory and GTIG both describe revocation or invalidation of Drift access and refresh tokens. That was necessary. It did not, by itself, remove data already exported or secrets already harvested. Recovery had to continue inside customer environments.

The first recovery step is exposure scoping: which Salesforce entities were accessed, which records were queried, which API jobs were run, and which integrations were used? Salesforce's event monitoring and transaction security documentation and API logs can matter here, but log availability varies by edition, configuration, retention, and customer maturity. Public advisories cannot substitute for tenant-level evidence.

The second step is secret rotation. If records contained AWS keys, Snowflake tokens, VPN credentials, API keys, passwords, or webhook secrets, those secrets needed to be found and rotated. That is hard because secrets may sit in free-text fields, attachments, case comments, chat logs, or custom entities. Automated search helps, but it can miss unusual formats. Manual review is slow.

The third step is customer and downstream notification. A Salesforce customer whose CRM data was exported may have obligations to its own customers, employees, prospects, partners, and regulators. That creates a cascade. Salesloft's incident became Salesforce's platform incident, which became each affected customer's incident, which may become each affected customer's customer notice. The cost of one OAuth compromise travels outward.

The fourth step is app governance review. Customers need to ask which other connected apps have similar scopes, whether they are still needed, whether refresh tokens are long-lived, whether app owners are known, whether vendor risk reviews are current, and whether emergency revocation playbooks exist. The Drift incident should be treated as a rehearsal for every other deeply permissioned SaaS integration.

AI branding did not change the accountability problem

Some public discussions framed Drift as an AI chatbot integration. That matters for product context, but the security failure was not magic because of AI. The key issue was delegated SaaS access. A chatbot, sales engagement tool, support widget, analytics connector, data enrichment tool, or marketing automation platform can all become dangerous if it holds broad tokens into customer systems.

AI may increase the appetite for integrations because companies want conversational tools to see more context. A sales or support chatbot is more useful if it can read CRM records, answer customer questions, update cases, route leads, and personalize responses. Each additional scope increases usefulness and risk. If the token behind that scope is stolen, the attacker receives the same broad context that made the product attractive.

This is the security economics of SaaS automation. Vendors sell smoother workflows. Customers approve access because the workflow saves labor. Platforms host the permission model because integrations expand ecosystem value. The risk is that none of the parties fully prices the cost of a token compromise until after a campaign. The Drift incident is a case study in that underpriced risk.

FINRA's alert matters because regulated financial firms do not get to treat this as a general tech-news story. If a financial firm used Drift with Salesforce, it had to assess whether customer, prospect, or internal data was exposed and whether credentials in CRM records created downstream risk. The same logic applies in healthcare, education, software, public-sector contracting, and any sector where Salesforce contains sensitive operational context.

The incident exposed a visibility asymmetry

Platforms see patterns that individual customers cannot. A single customer may notice strange API behavior in its own Salesforce org. Salesforce can see AppExchange app installations, token invalidations, and cross-customer patterns. Salesloft can see Drift product telemetry and token custody. Google Threat Intelligence can see threat activity across customers and its own investigations. No one customer can see the whole campaign.

That asymmetry creates duties. The party with cross-customer visibility must warn quickly. The party with product telemetry must investigate and contain quickly. The platform must help identify which customers are affected. Customers must act quickly once notified. If any party waits for perfect evidence, the attacker can keep using valid authority.

The public record suggests coordinated action, but not the exact speed of internal escalation. GTIG said the campaign began as early as August 8. Salesforce's advisory reported invalidation and removal actions. Salesloft's Trust Center says Mandiant was engaged on August 26. Those dates show movement, but they do not show when each party first knew enough to act or what signals were available earlier.

That missing timeline matters because OAuth campaigns are fast. Once tokens are stolen, the attacker can automate queries and exports. A difference of days can determine whether customers rotate secrets before or after use. A high-quality postmortem would show detection time, decision time, token invalidation time, customer notification time, and log availability time.

What customers should learn without being blamed

Customers have responsibilities, but the lesson should not become "customers should have known better." Many customers install marketplace apps because they rely on platform trust signals. They approve scopes because vendors say the scopes are needed. They store operational data in CRM because employees use CRM as the shared memory of customer work. Those are normal business behaviors, not reckless acts by default.

The better lesson is disciplined connected-app governance. Customers should inventory connected apps, owners, scopes, token lifetimes, last-use dates, and vendor risk status. They should remove apps that are no longer needed. They should restrict profiles and permission sets available to apps. They should scan CRM data for secrets. They should monitor API behavior by app, not only by user. They should have a playbook for emergency token revocation.

Salesforce can make those customer responsibilities easier or harder. Clear app permission explanations, app-risk scoring, admin warnings for broad scopes, simple token inventory, better default expiration, anomaly alerts, and strong AppExchange review can reduce customer burden. The platform's design shapes customer behavior.

Salesloft and other SaaS vendors can also reduce burden by storing tokens securely, minimizing required scopes, rotating credentials, publishing incident updates quickly, and proving segmentation. Salesloft's Trust Center reference to verifying segmentation between Drift and Salesloft applications is important because customers need confidence that one product compromise did not become a broader vendor compromise.

OAuth standards explain why bearer tokens require extra discipline

OAuth is designed for delegated authorization. The core OAuth 2.0 specification, RFC 6749, lets a client obtain access tokens to resources with the resource owner's authorization. The design is powerful because the user does not need to give the client their password. The risk is that an access token is often a bearer credential: whoever holds it can use it within its scope until it expires or is revoked.

The OAuth threat model and security considerations in RFC 6819 warn about token leakage, token storage, replay, phishing, redirect abuse, and the need to limit scope and lifetime. The newer OAuth 2.0 Security Best Current Practice, RFC 9700, continues that direction by emphasizing modern defensive patterns. These standards are not Salesforce incident reports. They explain why the Drift campaign was structurally dangerous.

If a Drift token had broad Salesforce access, the token itself embodied trust. A security team could remove the user's password, enforce MFA, and still face risk if the app token remained valid. That is why token revocation was the emergency action. It is also why the next layer is scope minimization. A stolen token with narrow scope can be harmful but bounded. A stolen token with broad read access can become a data-export tool.

MITRE ATT&CK's technique Steal Application Access Token describes adversaries stealing application access tokens to access remote systems and APIs. Its technique for Use Alternate Authentication Material covers the broader pattern of using valid authentication artifacts instead of passwords. These frameworks help name the attack class without overstating the Salesforce-specific facts: the issue was valid delegated material in the wrong hands.

The standard lesson is simple but operationally hard. Tokens should be treated as secrets. Refresh tokens should be treated as especially sensitive secrets because they can mint future access. Scopes should be as narrow as the product can tolerate. Tokens should be rotated and revocable. Logs should show token use by app and by entity. Customers should know which non-human identities can read their data. Platforms should make dangerous scopes hard to approve silently.

Connected-app hygiene needs an owner, not a spreadsheet after the breach

Many organizations discover their connected apps during an incident. That is too late. A connected-app inventory should exist before the campaign: app name, vendor, business owner, technical owner, scopes, installed profiles, last use, refresh-token policy, data entities touched, contract status, and removal procedure. If no one owns the app, no one owns the risk.

Salesforce's documentation for managing connected apps and OAuth policies for connected apps shows that the platform offers administrative controls. The question is whether customers have the staff, knowledge, and incentives to use them well. A small company may install a sales chat tool and never revisit its scopes. A large enterprise may have hundreds of connected apps and no unified review cadence.

This is where platform design should reduce error. Dangerous scopes should be visible in plain language. Unused connected apps should be easy to find. Apps with refresh tokens should be highlighted. High-risk apps should have expiration or periodic reauthorization options. Admins should be able to revoke app access without breaking unrelated workflows. Security teams should receive app-specific API anomaly alerts.

Customers also need policy. No app should receive broad access without a named owner and review date. No app should remain installed after the business owner leaves. No app should store secrets in CRM records merely because it is convenient. No app should be exempt from incident playbooks because it is "just a sales tool." The Drift campaign showed that a sales tool can become a security incident path.

The problem is partly economic. Connected apps save labor. Review costs labor. If the benefit is immediate and the risk is rare, organizations underinvest in review. The platform and vendor can reduce that imbalance by lowering the cost of good governance: clear dashboards, risk scores, automated recommendations, and safer defaults.

Logs must answer questions a customer can act on

Incident guidance often tells customers to review logs. That advice is only useful if logs answer the right questions. For the Drift campaign, customers needed to know which app tokens were used, which Salesforce entities were queried, which records were exported, from which IPs, with which user context, over what time window, and whether queries searched for secret-like strings.

Salesforce event monitoring, API logs, and connected-app reports can help, but access to complete evidence may depend on licensing, retention, and configuration. A customer that lacks the right edition or log export pipeline may receive a notice and still struggle to determine exposure. That is a platform-governance issue. When a marketplace integration is abused across customers, the platform is in the best position to supply normalized evidence packages.

Customers also need a repeatable triage path. First, identify whether Drift was installed and connected. Second, determine whether tokens were active during the campaign window. Third, inspect API activity attributed to the app. Fourth, identify entity and field access. Fifth, search exported or accessible records for secrets. Sixth, rotate any secrets that may have been exposed. Seventh, notify downstream parties if regulated or customer data was involved.

The FBI/IC3 advisory and GTIG guidance point customers toward this kind of action, but execution varies widely. A large financial firm may have a security operations team and log lake. A small SaaS company may have a Salesforce admin, a managed security vendor, and a backlog. The same campaign therefore creates unequal recovery burdens.

That inequality matters for accountability. Platforms that serve companies of very different maturity levels should not assume that all customers can interpret raw logs or threat-intelligence indicators. Actionable, tenant-specific evidence reduces the cost of response and the chance that stolen secrets remain valid.

Secrets in CRM records are a preventable but common failure

One uncomfortable lesson is that customers have to stop treating CRM as a safe place for operational secrets. Support and sales teams often paste API keys, credentials, bearer tokens, webhook secrets, VPN details, or screenshots into cases and notes because they are trying to solve a problem. The CRM becomes a convenience archive. When an integration can read it, the convenience archive becomes a secret repository.

OWASP's Secrets Management Cheat Sheet explains why secrets need controlled storage, rotation, and access discipline. The Drift campaign applies that principle to CRM data. If secrets appear in records, a CRM export can become a keychain.

The repair is partly technical: scan records for secret patterns, mask sensitive fields, restrict attachments, and alert when known key formats appear. It is also cultural: train support teams not to request or store secrets, provide secure intake channels for necessary diagnostic material, and make it easy to purge secrets when discovered. If the organization punishes slow support but not unsafe support notes, employees will keep taking shortcuts.

Salesforce and integration vendors can help by building secret-detection features and warning customers when broad app scopes include entities likely to contain sensitive operational data. But customers still own the data hygiene inside their orgs. The Drift incident did not create the bad practice of storing secrets in CRM; it revealed how that practice can amplify a third-party token compromise.

The public record should preserve what did not happen

It is just as important to state what the public record does not show. The sources do not show that attackers exploited a Salesforce core vulnerability. They do not show that every Salesforce customer was affected. They do not show that every Drift-connected customer had the same data exported. They do not show that every exported record contained secrets. They do not show that Salesloft's broader product suite was compromised beyond what Salesloft's investigation described.

Those limits protect fairness. They also make the real lesson sharper. The incident is serious without exaggeration because a trusted integration became a delegated-access path into customer environments. The gravity comes from the trust model, not from a need to invent a platform zero-day.

The incident also should not be reduced to "third-party risk" in a vague sense. The specific third-party risk was token custody and connected-app authority. A vendor can have SOC reports, contracts, and security questionnaires while still holding tokens that require exceptional protection. Customer vendor-risk reviews need to ask how SaaS integrations store tokens, what scopes they require, how quickly tokens can be revoked, and what evidence the vendor can provide after an incident.

The platform's AppExchange review also needs specificity. It should not only check whether an app functions and meets baseline security requirements at listing time. It should support continuous monitoring, rapid suspension, customer notification, and post-incident revalidation. Trust in a marketplace is a continuing obligation, not a one-time badge.

What evidence would change the assessment

The assessment could change in either direction with more evidence. If later forensic detail shows that the compromised tokens were extremely narrow, that exports were limited, and that affected customers received complete entity-level logs quickly, the operational severity should be reduced. If later evidence shows broader scopes, long-lived tokens, weak token storage, delayed revocation, or widespread secret exposure, the severity should rise.

If Salesforce publishes more detail on AppExchange monitoring improvements, token inventory features, customer log packages, or safer connected-app defaults, that would strengthen the repair record. If Salesloft publishes more detail on root cause, token custody, segmentation, and customer remediation, that would strengthen vendor accountability. If regulators issue findings, those should be evaluated separately from the current public advisory record.

Until then, the evidence supports a high-confidence control conclusion: SaaS ecosystems need connected-app governance that treats delegated tokens as production credentials, not as integration plumbing.

That conclusion is useful precisely because it avoids overclaiming. It lets customers harden connected apps without waiting for a final courtroom record. It lets platforms improve marketplace and token controls without admitting a core-platform flaw that the evidence does not show. It lets vendors treat token custody as a product-safety obligation. The campaign's lesson is not speculative: delegated access can be stolen, and when it is, the ecosystem has to know who can revoke it, who can explain it, and who can prove what it touched.

Revocation drills should be routine

The fastest way to learn whether OAuth governance is real is to run a revocation drill before an incident. Pick a noncritical connected app. Identify the business owner, scopes, users, tokens, logs, dependent workflows, and rollback path. Revoke access in a controlled window and measure what breaks. Then document who approved restoration and what evidence showed the app was safe to reconnect.

That drill turns abstract app inventory into operational knowledge. It shows whether security can find the app, whether admins can revoke it, whether the business understands the workflow, whether users receive clear instructions, and whether logs can prove what the app accessed. It also reveals where teams are afraid to touch old integrations because no one knows why they exist.

The Drift campaign shows why that practice matters. In a real compromise, the organization cannot spend days discovering who owns an integration while attackers use stolen tokens. A prepared customer can revoke first, investigate quickly, and reconnect only with evidence. An unprepared customer may hesitate because every token looks like business continuity.

The accountability test

The Drift-Salesforce campaign should be judged through seven controls.

First, token custody: did Salesloft protect access and refresh tokens as highly sensitive credentials, and did its architecture minimize token exposure across Drift and other products?

Second, scope design: did the Drift integration request only the Salesforce permissions it needed, and did customers understand the blast radius of approving those permissions?

Third, marketplace governance: did Salesforce's AppExchange review, monitoring, and emergency removal process reduce customer risk quickly enough once the vendor app became unsafe?

Fourth, cross-customer detection: did Salesforce, Salesloft, and threat-intelligence partners identify campaign patterns quickly enough to revoke tokens before further exports?

Fifth, tenant evidence: did affected customers receive enough logs, entity-access evidence, and guidance to determine what was queried and whether secrets were exposed?

Sixth, secret hygiene: did customers store passwords, API keys, cloud tokens, or VPN credentials in Salesforce records, and did they rotate them after exposure?

Seventh, public communication: did advisories preserve the critical distinction that Salesforce core was not exploited while still making clear that Salesforce customer data was accessed through trusted app tokens?

The final finding is not that Salesforce was the vulnerable product. The public record says the opposite: the issue did not stem from a Salesforce core platform vulnerability. The finding is that Salesforce's trust boundary includes connected apps because customers experience the platform through its ecosystem. OAuth tokens are delegated authority. When a trusted integration loses that authority, the platform, vendor, and customer all have distinct duties. The Drift campaign made those duties visible in the most uncomfortable way: by turning an approved productivity integration into an attacker-held key.