When Your Infrastructure Supplier Gets Hacked, You're Already Compromised
Vercel got breached. ShinyHunters claimed responsibility. A third-party AI tool was the entry point. I read the news on Tuesday morning, coffee still lukewarm, and realized I needed to audit every single integration I've shipped in the last eighteen months.
This shouldn't be novel. But it is. Most of us building AI products treat our dependencies like weather—inevitable, monitored loosely, dealt with after the storm. I'm guilty. When I integrated OpenAI's API into a client project last year, I ran the standard security checklist. API keys stored in environment variables. Rate limiting configured. Monitoring enabled. But did I audit what OpenAI itself uses internally? No. Did I map out the supply chain risk of their infrastructure? Absolutely not.
Vercel's statement said the incident impacted a "limited subset" of customers. That phrase bothers me because limited is relative. One customer's limited breach is another customer's entire production database exposed to ShinyHunters. And here's where I'm genuinely uncertain: should I assume Vercel's definition of limited is trustworthy, or should I treat every third-party breach like it potentially touched me?
The AI Tool Problem Nobody Wants to Discuss
Vercel didn't name the compromised AI tool. That's telling.
- Could be an internal tool they built for developer experience. Probably security-tested once. Maybe twice.
- Could be a third-party service like Datadog or New Relic or some lesser-known monitoring platform that integrates with their deployment pipeline and has access to everything
- Could be something more obscure—a code analysis tool, a performance testing suite, something that seemed low-risk because it runs offline in CI/CD
When you're building AI products, you inherit this exact problem at scale. I use Claude's API for content generation in one project. I use Together AI for inference in another. Neither of these companies discloses their full security architecture. I trust them because they're established and have reputation to lose, but that's not security—that's just optimistic gambling.
The real tension here is that AI tools are getting integrated everywhere now. They're not optional anymore. If you're building anything remotely intelligent, you're reaching for an API. And each API is a potential attack surface. I'm not sure there's actually a solution to this beyond prayer and better incident response, but I hate admitting that.
What I'm Doing Differently This Week
First pass: I'm documenting every external service my projects touch. Not the happy path. The actual path. What data flows where. What keys exist. Which services have production access. It's painful and I haven't finished yet.
Second: I'm implementing stricter API scope management. OpenAI's API keys should only have permission to do exactly what they need to do. Same with Anthropic. Same with anything that touches customer data. This seems obvious, but most implementations give services overly broad permissions because it's faster to set up.
Third: I'm considering whether some of these integrations are actually necessary or if I'm just using AI because it's there. Sometimes the honest answer is no. A simple regex or a lightweight string matcher would work for what I'm doing, but I reached for GPT-3.5 because it felt more sophisticated.
The Uncomfortable Part
Here's what keeps me up: Vercel is huge. They have security teams. They have compliance certifications. They have customer trust baked into their brand. And they still got breached through a third-party tool nobody seems able to name publicly.
If that can happen to them, it can happen to any platform I depend on. AWS could get breached tomorrow. GitHub could. Stripe could. And my incident response plan is basically "find out on Twitter, then panic."
I don't have a clean answer here. No framework that makes this problem go away. Building with modern tools means accepting supply chain risk as a permanent feature of the landscape, not a bug to be fixed. That's not reassuring. It's barely acceptable.
