Legacy Security Is the Real Enterprise AI Bottleneck

· 3166 words · 15 minute read

High quality data is expensive to collect, clean, and maintain. Poor security makes all of it free. To someone else.

As software collapses toward zero marginal cost, that sentence stops being a cybersecurity truism and starts being a business model observation. Data is the last asset with durable value in an AI-native stack. The only thing that keeps that value is the discipline most AI-native companies are treating as optional.

The past few weeks have been a live-fire demonstration. An MCP vulnerability at Anthropic. A “vibe coding” data exposure at Lovable. A supply chain breach at Mercor through a compromised open-source dependency. A supply chain breach at Vercel through a compromised third-party AI tool, pre-emptively framed publicly as “attackers accelerated by AI.” A compliance-first startup, Delve, running into its own compliance problems. None of these are novel threat classes. All of them are failure modes we understood well before the first transformer paper.

The MCP warning nobody wanted to hear 🔗

I’ve spent the last several months pushing back on the default assumption that every AI integration needs to be an MCP. MCP isn’t wrong on its own terms. It’s a reasonable design for the narrow case where an agent genuinely needs a third-party server to execute code inside its trust boundary. The problem is that most integrations are nothing like that. The moment the interaction is “hit a REST endpoint and get structured data back,” there is no good reason to invite arbitrary third-party code into the agent’s execution context. You’re paying the security cost of the hard case in return for none of its capabilities. We spent twenty years teaching engineers not to curl | bash arbitrary scripts. Using MCP as the default for every integration is the same pattern, just productized.

The structural case got much harder to dismiss this month. OX Security’s disclosure of arbitrary command execution in the MCP SDK’s STDIO transport hits every official Anthropic SDK across Python, TypeScript, Java, and Rust, affecting 150M+ downloads, with 7,000+ servers publicly exposed and ten downstream CVEs including LiteLLM, LangChain, and IBM’s LangFlow. OX filed thirty responsible disclosures. Anthropic declined to patch, replying that “sanitization is the developer’s responsibility.” That is the design, not the bug. Push the safety boundary to every downstream implementer, and the safety floor of the agentic stack becomes whichever downstream developer was most tired last Tuesday.

Supply chain is trust by inheritance. Break the root and the compromise ripples through every user downstream, whether they consented to the risk or not. Security is not an addon; it has to be present by design at every layer, or the layers above inherit its absence.

The interesting problem has never been the specific CVE. It’s the class of issue: prompt injection through tool results, tool-name collisions between servers, silent updates on servers that were trusted yesterday, credential exfiltration inside a plausible-looking response. Each is a category, not a bug. The fact that the top skill on ClawHub at one point was malware is not a distribution problem. It’s a design problem.

The category error at the core of MCP is conflating data access with code execution. For the overwhelming majority of agent use cases, what’s actually needed is data access for context enrichment: pull a record, read a document, query a dataset. That is a much narrower class of privilege than “run arbitrary third-party code inside the agent.” MCP collapses the two into a single primitive, which is why a protocol designed for the easy case keeps producing problems that look like the hard one.

This is why at OnDB we’re prioritizing programmatically generated skills.md instead. Concretely, a skills.md is a list of API endpoint calls, essentially curl commands, that the provider publishes and the client decides when to invoke. No third-party code runs inside the agent. That isn’t a novel boundary; it’s the one every well-designed API has enforced for decades. Perplexity has publicly said they’re making the same shift internally. The Anthropic CVE didn’t start that migration. It just pulled the deadline forward.

The fair pushback on skills.md is that they’re harder to monitor than MCP, because there’s no shared runtime to instrument. This matters. The Grugq, who was VP of Threat Intelligence at my previous company Comae, put it well back in 2017: “your perimeter is not the boundary of your network, it is the boundary of your telemetry.” Plain HTTP calls are instrumentable at the network and gateway layer, using tooling cloud teams have been running for a decade. Arbitrary code inside an MCP server is observable only to whatever extent each server author bothered to build in. One surface is already solved. The other is a new one, per server, forever.

Meanwhile, agent runtimes are quietly rediscovering sandboxing (process isolation, capability-based access, same-origin-style boundaries) from first principles, often by name. Browsers spent twenty years learning those lessons the hard way. Operating systems spent forty. The agentic stack is on track to repeat the entire curriculum unless it picks up the textbook that already exists.

Consider what the endpoint of that textbook looks like. Bromure runs every browser session inside its own lightweight VM: a compromised tab cannot reach the host, other sessions, or anything that VM wasn’t explicitly granted. Multiple layers, assumed breach, minimal trust per surface. Real defense in depth. Meanwhile, a large part of the AI agent ecosystem is still debating whether unrestricted filesystem access is a reasonable default for a tool call. The gap between what the security community already knows how to ship and what most AI stacks actually ship is enormous, and it’s mostly invisible to the non-security founders who stand to be most hurt when it matters.

Lovable, Mercor, and the 2017 rerun 🔗

There’s roughly one startup data breach per day right now. The cadence is familiar because we lived through it in 2017, when every new crypto exchange got hacked in sequence. Not because attackers had become unusually capable, but because “move fast” had quietly replaced “have a threat model.” The AI-native generation of startups is repeating that curve, for the same reasons.

The industry has had a stated answer to exactly these failures for two decades: the Secure Development Lifecycle. Threat modeling, code review, security testing built into the development process as steps, not events. Skipping it doesn’t make the bugs harder to find. It makes them cheaper to exploit.

Lovable’s first apology and fuller follow-up are the instructive case. A permissions refactor in early 2026 silently re-enabled public access to chat streams users assumed were private. Textbook Row-Level-Security and IDOR, fifteen years of prior art. Vulnerability reports came in through HackerOne and were closed as “intended behavior” before anyone escalated. The follow-up walks back the original “it was documented” framing but still reduces the failure to the chats were technically public, users misunderstood the UI, and we’ve fixed the defaults going forward. Deflection in more gracious prose.

Underneath the incident, responsibility is diffused across every layer. The AI has no threat model. The founder doesn’t read the output. The end user has no idea what backend their app runs on. The bounty reviewer doesn’t recognize the severity. The comms team closes the loop by calling the whole thing a misunderstanding. By the time the incident is over, no single layer owns the failure. And “no clear ownership” is itself the final deflection. Diffusion across five layers is indistinguishable from excusing all five.

Mercor’s March 2026 breach is a supply chain story in the same family. The compromise arrived through LiteLLM, an open-source proxy layer Mercor had integrated into their stack. An upstream dependency whose security posture effectively became Mercor’s security posture by default. Two more weaknesses compound on top of that. The first is dependency understanding. AI startups adopt open-source infrastructure because it showed up in a tutorial or a Discord recommendation, not because anyone audited what it reaches, what credentials it touches, or what its own upstream dependencies look like. The second is observability. You cannot detect a compromise inside a dependency you aren’t instrumenting, and most of this generation’s stack isn’t instrumented meaningfully. Mercor’s business is high-value proprietary training data: contractor evaluations, annotation tasks, the raw material frontier labs pay for. When your product is the data, every dependency sits inside your blast radius, and every gap in observability is free dwell time for whoever got in. It won’t end with Mercor.

This is the part the ecosystem keeps underpricing: as software goes to zero, data is the only asset left with durable value. A breach doesn’t just leak records. It resets the company’s valuation, because the thing that was being valued is now being sold by the attacker at a steep discount. Build a company around proprietary data without investing in securing it, and you don’t have a company. You have a pipeline someone else is about to monetize.

Vercel, Context, and the AI-did-it defense 🔗

Guillermo Rauch’s public framing of the incident contained a line worth quoting:

“we believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI”

This is 2026’s version of “sophisticated nation-state actor.” It’s a rhetorical instrument, not a technical claim: it pulls attention from the defender’s posture toward the attacker’s alleged exceptional capability, and it ends the conversation before anyone gets to ask whether the basics were in place. Attackers have always used the best available capabilities: leaked nation-state exploits like EternalBlue and the rest of the Shadow Brokers cache, cracked red-team frameworks like Cobalt Strike, credential-dumping tooling like Mimikatz, and now LLMs. That’s the job description of a modern defender, not an unfair surprise.

Vercel’s own knowledge base article tells a different story. Per the bulletin: “The incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee. The attacker used that access to take over the employee’s Vercel Google Workspace account, which enabled them to gain access to some Vercel environments and environment variables.” On scope, Vercel states that “a limited subset of customers whose non-sensitive environment variables stored on Vercel (those that decrypt to plaintext) were compromised,” and separately that “environment variables marked as ‘sensitive’ in Vercel are stored in a manner that prevents them from being read, and we currently do not have evidence that those values were accessed.”

“Non-sensitive” here is Vercel’s classification, not a statement about the material. Env vars routinely hold API keys, database URLs, service tokens, and OAuth secrets, and the actual blast radius is determined by what each customer put in each variable, not by whether the “sensitive” checkbox was ticked. Structurally this is the same story as Mercor: an upstream third-party compromise inherited by the downstream integrator, because third-party integrations sit inside the trust boundary by default. The “accelerated by AI” framing got amplified first. The supply chain attack through a third-party AI tool is what actually happened.

The reason this matters isn’t Vercel specifically. It’s that “accelerated by AI” is on track to become the default postmortem template. Once the deflection is socially acceptable, the uncomfortable questions stop being asked: bad secrets hygiene, blast radius too large, no tabletop run in twelve months. Every incident the industry explains away is an incident nobody in the ecosystem learns from.

Stack this against Delve’s ongoing SOC 2 issues, and the deeper pattern gets clearer. Compliance is what fails startups, and security more broadly, because compliance is a checklist, and defenders who think in checklists are defending against a threat model attackers never agreed to use. A SOC 2 report tells you what an auditor verified at a point in time. It doesn’t tell you what’s exploitable. The AI-native generation of companies is shipping the artifact (SOC 2 reports, trust pages, “enterprise-ready” badges, and increasingly “Security Agent” as a product category) considerably faster than the underlying work those artifacts are supposed to represent. Putting “security” in front of “agent” is not an engineering claim. It is a marketing one.

We’re talking about AGI on one screen and failing authorization checks on the other.

Frontier capability isn’t what’s breaching you 🔗

A misunderstanding worth naming directly. When Anthropic announces Glasswing or OpenAI ships GPT-5.4-Cyber, people hear “frontier AI security research” and assume it’s pointed at the same vulnerabilities that make headlines: the Lovable-class auth misconfigs, the Mercor-class supply chain leaks. It isn’t. Frontier research is optimized for a genuinely hard category: understanding closed systems. Binary exploitation, protocol reversing, architecture-level bug classes that only make sense once you’ve read the system end-to-end. That is where truly intelligent AI capability actually matters, and it is a different domain from web application security.

The bugs in every breach in this post are OWASP Top 10. IDOR, Row-Level-Security misconfigurations, secrets in client bundles, SSRF against metadata endpoints, insecure deserialization. Classes of vulnerability that were documented, fixed, and re-documented fifteen years ago. No frontier model is required to exploit any of them.

The cleanest exhibit this month is CVE-2026-32173 in the Azure SRE agent. Yanir Tsarimi found that any user could listen in on any other user’s AI chat stream (LLM thinking, invoked commands, tool results) because, in his words, “the auth check was there, but at the wrong place.” Broken Access Control is OWASP #1 and has been documented for twenty years. It landed in production inside a hyperscaler’s AI agent. Frontier research doesn’t enter the story at all. The bug class is older than most of the stack it broke.

The reason these keep showing up in 2026 is generational. A large slice of the AI-native startup generation has a stack literacy that ends at TypeScript, Supabase, and Vercel. None of those tools are the problem. But nobody whose entire mental model of “the stack” is that narrow develops the instinct for where a trust boundary actually lives, how data moves across it, or what an adversary reaches when they find a gap. The 2000s hacker generation learned that by being forced to read kernels, drivers, proprietary binary protocols, and everything under the abstraction layer, because there was no managed layer yet. That literacy is what lets you see the IDOR in the query rather than the feature in the UI.

As a friend put it recently: “the next few years are going to be a fun ride over all the old bug classes becoming new again.” That’s a fair description of right now.

AI is not a black box that solves this for you 🔗

Underneath all of these incidents is a quieter assumption: that AI itself will eventually clean up its own mess. That the models will get smart enough. That “AI will fix it” is a reasonable resting state for a founder who doesn’t want to hire a security engineer. It is not. Security is not an emergent property of model scale. It’s a discipline: threat modeling, least privilege, key management, auditability, incident response muscle memory. None of it appears for free when you wire up an LLM. If anything, every additional tool call in an agentic stack is a new place the blast radius can leak.

The consumer-enterprise distinction matters here, because it’s where the ecosystem is about to fracture. Consumer AI tolerates a lot of mess. A hallucinating chatbot costs a user five minutes, a leaky side project embarrasses a hobbyist, the upside feels large and the blast radius looks small. Enterprise does not behave the same way and does not forgive the same way. Enterprises care about auditability, data residency, access control, revocation, third-party risk, breach notification timelines, and regulatory exposure. They will not deploy agentic AI at scale into environments that can’t answer basic security questions, and most of the current stack can’t.

Security is going to be the primary blocker for Agentic AI in the enterprise. Not model quality, not latency, not cost. Every deflecting postmortem, every breach attributable to skipped basics, raises that bar higher for everyone. It’s an industry tax, paid collectively by every serious team trying to build.

I’m willing to help, for free 🔗

Most of these mistakes aren’t malice. They’re velocity, inexperience, or a founder who simply never had a security mentor in the room. If you’re building an AI company and would find it useful to have an experienced set of eyes on your security posture, I’m happy to help. No fee, no contract, no pitch. I’m in San Francisco and happy to meet up. Reach out.

Each step the industry takes forward shouldn’t feel like two steps back a week later. That’s the whole ask.

Security is not a layer you add. It’s the foundation that makes data monetization possible at all. The OnDB thesis is a trifecta: Trust (real security, not compliance artifacts), Data (the durable asset in an AI-native stack), and Monetization (the rails that let it flow to the agents that need it). Take any one of those out and the other two collapse. That’s the frame we’re building around.

Structurally, OnDB sits as middleware between data providers and agents: a message bus for agentic-enterprise interactions. That position makes it the natural telemetry layer for both sides. Data providers get visibility into who accessed what, how often, and at what price. Agents and apps get an auditable record of every data call and every payment attached. Which matters because the perimeter is the boundary of your telemetry, and in this architecture, the middleware is where the perimeter lives.

Programmatically generated skills instead of MCP-style arbitrary execution. Trust by construction. x402 and Stripe’s Machine Payments Protocol (MPP) on top of HTTP 402 as what we believe is the fairest protocol for data and information exchange: verifiable, per-call, and accountable on both sides, instead of gated behind shared API keys lying in configs. Least-privilege, auditable, revocable access as the default posture for every integration, so the data keeps being an asset rather than becoming a liability.

The AI economy compounds trust or it erodes it. Everything else follows from which one you pick.

MCP Lovable Mercor LiteLLM Vercel Delve SOC2 Data Breach OnDB Trust Agentic AI Enterprise OWASP Glasswing GPT-5.4-Cyber Azure CVE-2026-32173 HackerOne Supply Chain