Third-party risk management was built for a world that no longer exists

Every security team I talk to has a third-party risk program. Almost none of them believe it works. They run it because auditors expect it, because the questionnaires have always gone out, and because nobody wants to be the one who says it out loud.

‍

So I'll say it. The way we assess third-party risk was already broken before AI showed up. AI just made it impossible to pretend otherwise. We're pointing a once-a-year process at a problem that reinvents itself monthly, and we're surprised when it can't keep up.

‍

There were three cracks in the foundation before the acceleration started. Let's walk through them.

‍

1. We never found everything, so we triaged aggressively and hoped.

Discovery was always a guess. Finance controls caught whatever showed up on an expense report, which left every free tool invisible. The security-procurement handshake caught whatever someone was polite enough to route through procurement. Network and DNS data gave you aggregate signal about domains, not about which employee connected what to which data.

‍

Because we couldn't see it all, and because the volume of what we could see was already overwhelming, we triaged hard. We decided what deserved scrutiny based on perceived usage, maybe a short intake questionnaire about what the tool would touch. Only the vendors at the top of that list got real diligence, and that diligence was almost entirely about the vendor: their security org, their certifications, their pen test summary.

‍

That's a program that evaluates a small fraction of your vendors, on a dimension that tells you about them and not about you.

‍

2. We assessed the vendor. We never assessed the use.

Knowing a vendor is well run is one piece of the puzzle. Knowing that this specific application has access to your customer records, your source code, or your finance data is the piece that actually determines your risk. And that piece was captured, if at all, in a questionnaire filled out once, at procurement, by whoever was sponsoring the purchase.

‍

Here's the part that should bother everyone. That answer was treated as permanent. Assessment happened at intake, maybe again at renewal a year later, and maybe once more if the vendor made the news for a breach. That was the full list of opportunities.

‍

Meanwhile, the actual risk changed constantly. A new team adopted the tool. An employee connected it to Google Drive or GitHub with one click and one OAuth grant. The vendor shipped an AI feature that reads everything it can reach. An agent started operating on your data through the API. Not one of those events triggered a reassessment, because not one of them was visible to the process. Traditional third-party risk management is blind to the exact moments when third-party risk moves.

‍

3. We screened on signals that had nothing to do with the risk.

When we did filter vendors, we leaned on productized security scores. The pitch was that outside-in observation of a vendor's infrastructure predicted their likelihood of breach. In practice, the vendors selling those scores dug up whatever they could see from the outside: an outdated server, a weak SSL configuration on a marketing site, a vulnerability on a property that had nothing to do with the application your employees were using.

‍

Using that to screen or triage vendors is unhelpful. Using it as an actual risk evaluation is a mistake. Those signals tell you almost nothing about the likelihood the specific service you depend on gets compromised, and they tell you exactly nothing about the risk your organization is carrying. The score is about them. Your exposure is about what you gave them.

‍

Then everything got connected.

Two forces turned these three cracks into a structural failure.

‍

First, connectivity. Data flows between applications more easily than it ever has. Integrations, OAuth grants, webhooks, and now agents mean that a tool doesn't need to hold your crown jewels to become a path to them. It just needs a trust relationship with something that does.

‍

Second, velocity. New capabilities land every month, and every employee can wire a new data set into a new tool in the time it takes to click "Allow." The gap between what your program assessed and what's actually running in your environment doesn't grow annually. It grows daily.

‍

Put those forces together, and the vendors that never passed your initial triage are now critical entry points. The Vercel breach disclosed this past April is the case study. The initial foothold was an AI tool: benign on paper, no commercial relationship with the company at all. It would never have made it through a triage process built on spend, procurement, or vendor scoring. But a single employee had granted it sweeping OAuth access to their Google Workspace account, and when that vendor was compromised, the attacker used the stolen token to pivot straight into Vercel's internal systems.

‍

Nobody's questionnaire would have caught that. Nobody's security score would have flagged it. That's not a gap in execution. That's a gap in the model.

‍

What the modern version has to look like

If the problem is that risk changes continuously and invisibly, the answer can't be a point-in-time review of a filtered list.

‍

You need continuous discovery, so the free tool and the unsanctioned AI assistant show up alongside the enterprise contract. You need continuous assessment, so a new integration, a new data scope, or a new AI feature triggers a fresh look instead of waiting for renewal. And you need continuous context, so you're evaluating the risk of how the application is used inside your organization, not just how the vendor looks from the outside.

‍

In practice, that looks like this: an employee connects a new AI note-taker to Google Drive. A vendor security assessment starts automatically, and the app owner gets a Slack prompt to justify the access or switch to an approved alternative. Nobody files a ticket, and nobody waits for renewal.

‍

More assessments for their own sake won't help. Risk informed by context tells you where to focus. It shows you which grants to revoke, which integrations to restrict, which tools deserve a real conversation, and which ones you can safely leave alone. That's how you apply mitigating controls at the scale the problem now demands.

‍

Third-party risk hasn't gotten harder to manage. It's gotten harder to ignore that we were never really managing it.

‍

We just shipped the next step in closing this gap. See how it works →