Most conversations about integration security stop at the breach. The question that actually decides how bad a week you have is the next one: when a third-party integration is compromised badly enough that every token it holds has to be assumed stolen, the fix is to revoke all of them at once, and the things running on those tokens stop. Syncs, pipelines, dashboards, the attribution model your board deck is built on. Marketing teams wire connectors in to get a feature. What the company inherits is a switch, and on the worst day someone outside your team throws it.
This expands on a post I published on LinkedIn after hiring a security lead out of crypto.
Key Takeaways
- The useful security question about an AI agent or connector is not only what it can do. It is also what its access can reach, and who can shut it off within the hour.
- In August 2025 an actor Google tracks as UNC6395 used valid OAuth tokens from a third-party chat application to pull data from corporate Salesforce instances. Google states plainly that this did not stem from a vulnerability in the core Salesforce platform. The tokens were legitimate, so the access looked legitimate.
- The remediation was total: on August 20, 2025 the vendor and Salesforce revoked all active access and refresh tokens for that application. That is the second blast, and it is the one that hits marketing.
- Revocation is not always scoped to whoever was breached. When a vendor cannot bound which customers' tokens were taken, it revokes at the integration level and every customer of that integration loses the connection.
- Revenue teams feel it early and recover late, not because they hold the most integrations, but because theirs are the least inventoried and the least represented in continuity planning.
- "Who owns the switch" is an org design question before it is a tooling question. Many companies cannot answer it, and find out during the incident.
- The mitigation is unglamorous: an inventory of what holds credentials, a named custodian, a continuity plan for revocation, and fewer standing credentials in the first place.
What Actually Happened in August 2025
The specifics matter here, because the shape of this incident is the shape of the risk.
According to the Google Threat Intelligence Group advisory published on August 27, 2025, an actor designated UNC6395 ran a data theft campaign from August 8 through at least August 18, 2025, authenticating to corporate Salesforce instances using compromised OAuth tokens tied to the third-party Salesloft Drift application. The advisory does not say how those tokens were obtained.
Two details deserve emphasis. First, GTIG is explicit that "this issue does not stem from a vulnerability within the core Salesforce platform." Nobody broke into Salesforce. Valid credentials were used the way valid credentials are meant to be used. Second, the actor was not primarily after CRM records for their own sake. GTIG reports the exported data was searched for AWS access keys, passwords, and Snowflake-related access tokens. The goal was more credentials, which is how one integration becomes a path into systems that integration was never part of.
Then the remediation. On August 20, 2025, Salesloft in collaboration with Salesforce revoked all active access and refresh tokens for the Drift application, and Salesforce removed it from AppExchange pending investigation. On August 28, GTIG updated the advisory to say the compromise "is not exclusive to the Salesforce integration with Salesloft Drift and impacts other integrations," confirming compromised tokens for the Drift Email integration. For that one, Google identified the impacted users, revoked those specific tokens, and disabled the integration between Google Workspace and Drift. Every other Drift customer was advised to treat any and all authentication tokens stored in or connected to the Drift platform as potentially compromised, and to revoke and rotate credentials across connected applications themselves.
Read that last paragraph as an operations document rather than a security one and you get a different story: over about a week, every company using the Drift-Salesforce integration had it revoked out from under them, Google cut the Workspace connection, and everyone else was told to go revoke and rotate their remaining Drift-connected credentials by hand.
The Second Blast: Revocation Is the Outage
There are two blasts in an incident like this, and the industry mostly writes about the first one.
The first blast is the theft. It is the one that generates the headlines, the disclosure obligations, and the board conversation. It is also, for most companies in the blast area, not the thing that disrupts the quarter.
The second blast is the remediation. Salesloft revoked every access and refresh token for the application at once. Revocation does not have to work that way. A provider can scope it to the customers or users it knows were affected, which is exactly what Google did for the Drift Email integration in this same incident, and on some platforms an already-issued access token stays valid until it expires regardless. But when the whole token store is suspect, the sweep is total, and it does not distinguish the attacker's use of that credential from yours. All of it goes.
What that means operationally is that every scheduled sync, pipeline, report and automation riding that grant stops. Some at the moment of revocation, the rest at their next scheduled run, with no deprecation notice and no migration window. The failure often shows up as stale data before it shows up as an error, which is worse, because a dashboard that is quietly three days behind still gets used in a meeting. If it lands mid-quarter, the pacing data your team steers on is gone until somebody rebuilds the connection. And if the platform has pulled the application pending investigation, as Salesforce did here, you cannot rebuild it at all until the vendor is cleared to return.
This is the part that surprises people: you do not have to be breached to eat the second blast. You have to be adjacent to a compromise. When a vendor cannot bound which customers' tokens were taken, revocation lands at the integration level, so the blast radius of the fix becomes every customer of that integration rather than every victim of the attack. Being uninvolved is not protective.
The same structural point applies to agents. An agent that authenticates through a standing credential is not more resilient than the credential. We have written before about what happens when an agent runs unattended with no hard limits. This is the mirror image: the agent behaves perfectly, and the access underneath it disappears.
Why Revenue Teams Go Dark First
When the switch gets thrown, marketing and sales operations tend to feel it before anyone else, for three reasons that have nothing to do with how careful those teams are.
Marketing runs on a large number of third-party integrations, most of them wired in without a security review. Ad platforms, CRM, MAP, chat, call tracking, enrichment, the warehouse, the BI layer. Each one is an authenticated connection. The surface is not large because anyone was reckless. It is large because the job requires many systems to talk.
Those connections are frequently wired in by the team itself. A tool gets adopted because it solves a real problem this quarter, and it is connected with an OAuth grant by someone who owns a number, not a threat model. There is nothing wrong with the motive. The consequence is that the company's credential inventory now includes a grant that no security review saw and no runbook lists.
Marketing systems are underrepresented in incident response. Business continuity planning tends to cover the systems that stop the company from transacting. It rarely covers the reporting stack. So when tokens are revoked, there is a documented path to restoring the systems that take orders, and no documented path to restoring the ones that tell you whether the quarter is on track. That failure is invisible right up until the moment it is very visible.
The related pattern, which compounds this quietly, is credential and tool sprawl: every additional tool that holds its own grant adds a switch, and nobody is counting the switches. That is one of the failure modes behind shared credentials and over-permissioned tooling, where the absence of a clean revocation path is the thing that turns a contained problem into an uncontained one.
Talk to an Improvado expert about consolidating marketing connectors into one governed layer.
Who Owns the Switch
I will be direct about my own position here, because it is the honest version of this argument. A year ago I could not have told you who throws that switch in our own stack, and I run the company. It took hiring someone who has spent years assuming the worst day arrives on schedule before that question had an owner.
That is the actual gap at most companies. Not a missing control. A missing name.
The security team usually cannot answer it alone, because they do not know which marketing workflows depend on which grant. The marketing team usually cannot answer it either, because they do not know which grants exist across the org or what else those credentials can reach. So the question sits between two functions, and gets resolved for the first time under incident conditions, which is the worst possible time to be discovering your own topology.
There are only three workable answers, and any of them beats ambiguity:
Security owns the switch, with a marketing continuity obligation. Security decides what gets revoked and when, and accepts a documented duty to tell revenue operations what is about to go dark and for how long. This is the right default for most companies above a certain size.
Marketing ops owns the connection, security owns the standard. The team that wires the integration in stays accountable for it: it goes on an inventory, it has a named owner, and it has a documented recovery path. Security sets the bar and audits against it. This works when marketing ops is mature and staffed.
Neither, because the credential moves. Consolidating platform access behind one governed layer does not delete the switch. It relocates it somewhere with an inventory, an owner, and a notification path, and it reduces how many independent switches exist. That is a real improvement over a dozen switches nobody is counting, and it is also a concentration. It is the same trade we argue for with a single gateway rather than fifty separate integrations, including the concession that piece makes explicitly: centralizing access concentrates risk, and one gateway is one point of compromise. It is a deliberate trade, not a free win. What makes it worth taking is that the remaining switch is one you can see, plan around, and be told about.
What to Do Before the Worst Day
None of this requires a security program. It requires a list and an owner, and the first useful version is days of work rather than a quarter.
Inventory what holds credentials to your marketing systems. Not tools you pay for. Tools that hold a live authenticated connection, including the ones connected with a personal OAuth grant by someone who has since changed roles. It is common to find integrations nobody remembers approving, and those take the longest to chase down.
Put a name on each one. A specific person, not a team. The test is whether that person could say, within an hour, what stops working if this grant is revoked.
Write the revocation plan, not just the breach plan. For your top five integrations by dependency: what goes dark, who notices, what the manual fallback is for the reporting that leadership will still ask for, and roughly how long reconnection takes. This document is boring and it is the whole deliverable.
Ask about revocation in vendor evaluations. Three questions with concrete answers: what happens to your data flows if the vendor has to revoke all tokens, how they notify you, and how fast a connection can be re-established afterward. Vendors who have thought about it answer immediately. Vendors who have not will reframe the question as a security-posture answer, which is a different question.
Reduce the number of standing credentials. Every integration retired is a switch removed. Every integration consolidated behind a governed layer is a switch someone is actually tracking. This is also the part with a return outside of incidents, since the same consolidation is what makes reporting consistent on ordinary days.
The obvious objection, and I would rather raise it than have it raised for me: Improvado is itself a third party that holds standing credentials into your platforms. That is the exact shape of the thing this article just described. Consolidation does not remove this risk class. It concentrates it into one switch that is inventoried and owned instead of a dozen that are not, and that trade only earns its keep if the layer you consolidate into can answer the same three questions above. Ask us those three questions. They are the ones we are telling you to ask everyone.
What we build is that layer: marketing and sales data across your platforms through one governed connection point, with credential custody and access control that belong to the company rather than to whoever set up the connection. When something upstream gets revoked, the question becomes which connection to restore, not which forty people to ask.
Talk to an Improvado expert about who owns credentials in your marketing stack.
Frequently Asked Questions
What is OAuth token revocation and why does it cause an outage?
An OAuth token is the credential a third-party tool holds to access your systems on your behalf, which is what lets a connector sync data without anyone logging in. Revoking it invalidates that access. When a vendor cannot determine which customers' tokens were stolen, the response is to revoke every token it holds, for every customer, at once. Because that revocation happens at the integration level rather than per workflow, every sync, pipeline, report and automation authenticating through it stops, some immediately and the rest at their next scheduled run, with no migration window. The security action and the outage are the same event.
What happened in the August 2025 OAuth token incident?
Google Threat Intelligence Group published an advisory on August 27, 2025 describing a campaign by an actor it designates UNC6395, running from August 8 through at least August 18, 2025, in which compromised OAuth tokens for the third-party Salesloft Drift application were used to access corporate Salesforce instances. GTIG states the issue did not stem from a vulnerability in the core Salesforce platform, and does not say how the tokens were obtained. The exported data was searched for AWS access keys, passwords, and Snowflake-related access tokens. On August 20 all active access and refresh tokens for the application were revoked, and an August 28 update said the compromise was not exclusive to the Salesforce integration and impacted other integrations, confirming the Drift Email integration specifically.
Can revocation affect you if you were not breached?
Yes, and this is the part most planning misses. When a vendor can bound the exposure, it may revoke narrowly: in this same incident Google identified the impacted users and revoked only their Drift Email tokens. When it cannot, revocation is applied to the integration rather than to the victims, and every customer of that application loses the connection whether or not their data was touched. Since you cannot know in advance which of those two you will be on the receiving end of, continuity planning has to be based on dependency rather than on your likelihood of being targeted.
Why does marketing feel this before other functions?
Three structural reasons. Marketing depends on a large number of third-party integrations, because the work requires ad platforms, CRM, automation, enrichment, and analytics to exchange data. Many of those connections are authorized directly by the team that needs them rather than through a security review, so they are not on any central inventory. And business continuity plans usually cover transaction-critical systems rather than the reporting stack, so there is a documented path to restoring the systems that take orders and no documented path to restoring the ones that tell leadership whether the quarter is on track.
Who should own connector revocation, security or marketing?
Any clear answer beats the common one, which is that nobody knows until an incident forces it. The usual best default is that security owns the revocation decision and carries a documented obligation to tell revenue operations what will go dark and for how long. The alternative is that marketing ops owns each connection with a named person and a recovery path while security sets and audits the standard. Consolidating platform access behind one governed layer reduces how many independent switches exist and puts the remaining one somewhere inventoried, though it concentrates rather than removes the risk, which is why that layer has to answer the revocation questions too.
How do you audit your exposure without a security team?
List every tool holding a live authenticated connection to a marketing system, including personal OAuth grants made by people who have changed roles. Assign each one a specific named owner who could say within an hour what breaks if it is revoked. For the five with the deepest dependency, write down what goes dark, what the manual fallback is, and how long reconnection takes. That list plus those five paragraphs is the entire exercise, and it is worth more during an incident than any tooling purchase made after one.
What should you ask vendors about this?
Ask what happens to your data flows if they have to revoke all tokens, how they notify customers when it happens, and how quickly a connection can be re-established afterward. Also ask what else the credential they hold can reach, since the August 2025 campaign was primarily a hunt for further credentials rather than for the CRM records themselves. Vendors who have run the scenario answer these directly. Vendors who have not will answer a question about their security posture instead, which tells you they have planned for the first blast and not the second.
