The Lightwell Bet: Open-Source Security as the AI-Era Bottleneck

On May 28, 2026, IBM and Red Hat announced Project Lightwell — a five- billion-dollar commitment, a global force of twenty thousand engineers, and an AI-augmented "clearinghouse" model for triaging open-source software vulnerabilities at enterprise scale. The named early adopters include eleven of the largest banks and payment networks in the world: Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. The announcement explicitly positions Lightwell against, or alongside, Anthropic's Project Glasswing and OpenAI's Trust Access for Cyber program — two existing AI-lab efforts in the same problem space.

Read at face value, this is "another big-vendor security initiative." Read structurally, this is the first credible attempt to industrialize the maintenance of the open-source software supply chain at the scale that the AI era now requires. The numbers, the adopter list, and the operating model all imply something more substantial than the press cycle has absorbed.

This piece is the structural read. What Lightwell actually does mechanically, why the supply-chain problem got worse in 2024-2026 rather than better, what the eleven-bank adopter list tells us about the near-term economics, how the program compares to Glasswing and Trust Access for Cyber, what gets monetized, and what gets transferred from the upstream community into a corporate clearinghouse — for better and for worse.

The Supply-Chain Problem AI Made Worse, Not Better

The conventional narrative about open-source security in 2026 goes roughly: the codebase the world's enterprises run on is overwhelmingly open-source, the maintainers are predominantly unpaid volunteers, the vulnerability discovery rate is accelerating, and the patch deployment rate has not kept up. This narrative is correct in every individual claim. What the narrative has missed is that AI made the asymmetry worse rather than better.

The chart above is the denominator. Roughly nine in ten lines of code running in any enterprise production system today came from open-source packages the enterprise did not write. For AI/ML pipelines specifically the number climbs into the high nineties — the modern training stack is PyTorch plus a few hundred Python packages plus a CUDA layer plus a handful of model serving runtimes, all open-source, all maintained by small teams that are not on the deploying enterprise's payroll.

The accelerator of the problem is the rate at which AI-augmented attackers find vulnerabilities in that codebase. By every measurement the security community has published, the time from a vulnerability's existence-in-the- code to its public disclosure has compressed during 2024-2026. The AI that writes code is also the AI that reads code looking for ways in. The attackers were the first ones to industrialize that capability at scale.

A defender at a major bank in 2020 was triaging roughly 380 new CVEs per week. The same defender in 2026 is triaging six times that many. The patch-deployment cycle inside the bank has not gotten six times faster. The bank has not hired six times more security engineers. The gap is absorbed by extending the average time-to-patch and accepting more unpatched-vulnerability days of exposure per system.

This is the bottleneck Project Lightwell is targeting. Not "open-source is insecure" — a 2010s framing — but "open-source vulnerability triage and remediation is operating at the wrong order of magnitude for the threat volume the AI era now produces."

What Lightwell Actually Does

The announcement architecture is more specific than the press cycle has captured. Lightwell has four operational components.

First, a trusted enterprise clearinghouse. This is the central piece. Subscribing enterprises send their software-bill-of-materials (SBOM) and production deployment manifests into a shared Lightwell-operated infrastructure. The clearinghouse cross-references that inventory against a continuously updated map of upstream OSS vulnerabilities, prioritizes the patches the enterprise needs by exploitability and exposure, and serves back signed, validated, enterprise-ready patches for the subscriber's specific dependency graph.

Second, upstream maintenance through embedded engineers working alongside open-source community leaders on the most-deployed packages. The twenty-thousand-engineer headcount is doing two distinct jobs: roughly one-third are upstream-facing, contributing maintenance work directly to OSS projects; roughly two-thirds are downstream-facing, operating the clearinghouse and the enterprise-facing patch pipeline.

Third, AI-assisted vulnerability review at high volume. The model side of Lightwell does the work of reading thousands of CVE-eligible vulnerabilities per week, classifying them by exploitability against a given subscriber's deployment, generating candidate patches, running the patches through automated regression testing, and writing the human- reviewable documentation that lets a Lightwell engineer (and a subscriber engineer) audit the AI's work. This is the part that twenty thousand engineers cannot accomplish without a model in the loop. It is also the part that determines whether Lightwell scales to keep up with the CVE disclosure curve.

Fourth, commercial subscription delivery. Enterprises pay a per-seat or per-dependency-graph fee for clearinghouse access. The patches are delivered through existing supply-chain integrations — package managers, container registries, CI/CD pipelines — so the subscriber's developers do not have to learn a new workflow.

The headcount split is the strategic signal. A program that allocates one- third of its engineering capacity to upstream community work is not just extracting value from the OSS ecosystem — it is funding it. Whether that funding produces net-positive outcomes for the community is the open question of the next eighteen months, and the section below on "What This Transfers From Upstream" gets into the substantive risks.

The Eleven-Bank Adopter List

The named early adopters are worth reading literally. Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, Wells Fargo. Eleven firms; the combined market capitalization is roughly $2.5 trillion; the combined US deposit base is roughly $9 trillion. The list is not "interested parties." It is firms that have already signed enterprise subscription agreements at scale.

What is the adopter list telling us? Three things.

First, the buyers are the firms with the most-explicit regulatory exposure to software supply-chain risk. US bank holding companies and payment networks have been operating under the OCC's heightened expectations on third-party risk management for a decade. The 2024-2026 expansion of those expectations to specifically cover open-source dependency exposure is what created the addressable market for a paid clearinghouse model. The eleven-firm list is roughly the same list that showed up to the OCC's 2025 supply-chain risk roundtable.

Second, the buyers are the firms with the largest in-house security engineering teams. JPMorgan's cybersecurity organization is roughly seven thousand people. Goldman's is roughly two thousand. These firms are not subscribing to Lightwell because they do not have engineers. They are subscribing because the work the clearinghouse does is at a scale that their in-house teams cannot replicate without a comparable twenty-thousand-engineer investment. The economics of "build vs buy" favor buy decisively.

Third, the buyers' inclusion provides an implicit regulatory cover for late adopters. The same firms that show up in the OCC roundtables are the firms whose risk-management frameworks become de facto standards. When eleven of the largest US banks adopt a vendor solution, the mid- tier banks and credit unions follow within a regulatory cycle, because "we are using the same controls as JPM" becomes a defensible position in the next exam. Lightwell's named-adopter list is the first phase of a multi-year flywheel that ends with most US-regulated financial firms subscribed.

How Lightwell Compares to Glasswing and Trust Access for Cyber

The press release explicitly references Anthropic's Project Glasswing and OpenAI's Trust Access for Cyber. The three programs are not substitutable. Each addresses a different layer of the same problem.

Glasswing (Anthropic, launched March 2026) operates at the model layer. It provides Claude-derived security agents that subscribers can deploy inside their own environments to triage their own vulnerabilities. The model expertise is the product; the customer brings their own SBOM, their own deployment context, and their own remediation pipeline. The Glasswing analysis from earlier in May on CrashBytes covers what the program does and the asymmetry it creates.

Trust Access for Cyber (OpenAI, launched November 2025) is closer to a managed assessment offering. OpenAI provides early access to frontier models, accompanied by trained human security analysts, who do bespoke threat-modeling and remediation engagements for large enterprise customers. The product is high-touch and high-margin; the unit of sale is the engagement, not the subscription.

Lightwell is the supply-chain clearinghouse. It does not provide models the subscriber operates (Glasswing's offer) and it does not provide bespoke engagements (Trust Access for Cyber's offer). It provides a continuously-updated, validated patch feed for the open-source dependencies in the subscriber's actual production environment. The unit of sale is the subscription. The defensibility comes from operating the clearinghouse at a scale no single subscriber could match.

The three programs are complementary rather than competitive in any near-term horizon. The natural enterprise security stack in 2027 is Lightwell for the supply chain, Glasswing for the in-house agent capability, Trust Access for Cyber for incident-response engagements. The three vendors are not pretending otherwise. The IBM press release explicitly notes "incorporates learnings from initiatives such as Anthropic's Project Glasswing and OpenAI's Trust Access for Cyber," which is unusual diplomatic language for the cybersecurity industry and implies active multi-vendor coordination behind the scenes.

What This Transfers From Upstream

The most-important question Lightwell raises, and the one the press cycle has under-engaged with, is what happens to the upstream open- source community when a vendor operating at this scale offers paid patches faster than the community can produce free ones.

The mechanics are: a vulnerability is disclosed. The upstream maintainer (volunteer, often one person) takes some median number of days to investigate, patch, test, and release. Lightwell — with twenty thousand engineers and an AI-assisted pipeline — can produce a tested patch faster than the upstream maintainer, package it for subscribers, and ship it. Subscribers receive the patch first; non-subscribers wait for the upstream maintainer's release; the upstream maintainer, having lost the urgency-based justification for their work, may or may not stay engaged.

This is not hypothetical. The exact dynamic played out with Microsoft's acquisition of Patch My PC in 2024, with Snyk's commercial patches for npm vulnerabilities throughout 2023-2025, and with the entire log4j post-mortem in which corporate forks ran ahead of upstream for months.

The seventeen-day gap in the chart is what Lightwell is selling. Subscribers get a tested patch in roughly four days; the open-source community produces the same patch in roughly seventeen. For most enterprises, the thirteen-day window of additional exposure is the business case for the subscription.

The risk is that the upstream maintainer who used to receive the urgency-based reward — the recognition, the trust, the eventual maintainer-as-founder career path — now sees the corporate clearinghouse absorb that role. The volunteer's motivation degrades. The volunteer stops contributing. The upstream package eventually depends on Lightwell for its security maintenance, and the "open" in open-source becomes a license property rather than a community property.

This is the bull case for Lightwell's upstream-maintenance investment. One-third of the twenty-thousand-engineer headcount is doing community- facing work specifically to mitigate this risk — funding upstream maintainers directly, sponsoring foundation work, contributing patches back to upstream rather than only to subscribers. Whether that investment is enough to prevent the upstream-degradation dynamic is the substantive question of the next eighteen months. The empirical answer will come from the contribution-velocity data of the top-fifty packages through 2027.

The Build-vs-Buy Math

A natural first reaction from a large enterprise is "we have our own security engineers, why would we pay an external clearinghouse?" The build-vs-buy comparison is worth working through carefully, because the answer is not obvious in the abstract and the numbers turn out to be decisive.

Consider a representative large bank with roughly two thousand security-engineering staff and a production dependency graph of roughly forty thousand distinct open-source packages across all environments. The internal team's current allocation against open-source dependency maintenance is, in published peer-data from the FS-ISAC, roughly fifteen percent of total security-engineering capacity — three hundred full-time-equivalent engineers, costed at roughly four hundred thousand dollars all-in per engineer per year. That is a hundred- twenty-million-dollar annual line item, against which the team produces patches on a median timeline that matches the seventeen-day upstream median (because the team is itself mostly waiting on upstream releases).

The same bank's Lightwell subscription, at the top tier inferable from adopter-firm chatter, is in the two-to-three-million-dollar annual range. The clearinghouse delivers patches at the four-day median.

The math the chart describes is what made the eleven-firm adopter list inevitable. The "in-house + Lightwell" hybrid is the middle column: the bank keeps a smaller internal team for the bespoke work (custom-built software, proprietary forks, escalation response) and offloads the clearinghouse-shaped problem to Lightwell. The annual cost falls roughly thirty-five percent. The patch median falls four-fold. The exam-cycle defensibility improves because there is a vendor-attestation artifact for each patch.

The "Lightwell-led" column is the longer-horizon target: most enterprises will not get there because they have legitimate reasons to keep in-house capability for non-clearinghouse work, but the trajectory of the cost curve is what drives the program's revenue projection. Every percentage point of capacity an enterprise shifts from in-house OSS maintenance to Lightwell is a percentage point that subsidizes the clearinghouse's unit economics.

The build-vs-buy decision is therefore not really a decision — it is a mandated migration. The only question is the pace at which each enterprise gets there, and the pace is set by the regulatory cycle and the in-house team's willingness to give up scope. Both of those favor Lightwell.

Why IBM and Red Hat, Why Now

The strategic positioning is worth a brief read because it explains why Lightwell came from IBM and Red Hat rather than from one of the AI labs or from a pure-play security vendor.

IBM's enterprise distribution into regulated industries is the deepest in the market. The same sales relationships that sold Db2 and CICS to the named-adopter firms in the 1990s now sell Lightwell subscriptions in 2026. The contracts go through procurement organizations that already have IBM as an approved vendor. The legal templates do not need to be renegotiated. The compliance attestation paths are pre-built.

Red Hat's positioning in the open-source community is the deepest among commercial vendors. The same engineering organizations that maintain RHEL and OpenShift, the same kernel-maintenance commitments, the same relationships with upstream foundations — these are the assets that make "twenty thousand engineers, one-third upstream-facing" a credible proposition rather than a marketing slide. Red Hat has been doing this work for twenty-five years. The novel piece is the AI-augmentation and the clearinghouse business model.

The combination is what no other vendor in the market currently has. Anthropic and OpenAI have the model capability but neither the enterprise distribution nor the upstream-community standing. Microsoft has the enterprise distribution but a more-complicated relationship with upstream OSS. AWS and Google Cloud have neither the regulated-industry sales motion nor the upstream-maintainer reputation at the depth Red Hat does. Pure-play security vendors (Snyk, Sonatype, Mend) have specialized expertise but not the engineering scale.

The "why now" question is the regulatory timing covered above plus the model-capability timing — the AI-augmented vulnerability triage that makes the twenty-thousand-engineer plan tractable is a 2025-2026 capability that did not exist when, say, Microsoft acquired GitHub in 2018. The program is technically possible now in a way it was not three years ago, and the regulatory backdrop is forcing the enterprise demand that pays for it.

The Commercial Model

Lightwell's pricing was not announced in detail, but the contours are inferable from the early-adopter discussions reported in the trade press. The model is a tiered subscription with three components.

A per-organization base fee for clearinghouse access — in the seven- figure annual range for the named-adopter tier, scaling down for smaller enterprises.

A per-dependency-graph charge that grows with the size of the subscriber's open-source footprint — the bigger the SBOM, the more the clearinghouse has to track and patch, and the more the subscriber pays.

A per-incident escalation fee for critical CVE-class events that require dedicated Lightwell engineering response on tight timelines.

The unit economics work because the cost of operating the clearinghouse scales sub-linearly with subscriber count — the same AI-assisted analysis of a single CVE serves all subscribers whose SBOM includes the affected package — while the revenue scales linearly with subscribers. This is the canonical clearinghouse business model. It is the same shape as a credit bureau, a payments network, or a market-data provider.

The total addressable market for the named-adopter tier is roughly five hundred large enterprises globally. The mid-market tier — firms with significant OSS exposure but without dedicated security-engineering organizations — is closer to fifty thousand firms. If Lightwell captures even ten percent of the mid-market on a smaller subscription, the program's revenue trajectory is in the multi-billion-dollar annual run rate within thirty-six months.

The trajectory is the case for IBM's five-billion-dollar commitment. Five billion is the program-level investment; the projected ARR by year four is roughly half that figure annually. By year six the program is paying back its own commitment per year. This is the unit economics of a clearinghouse, and it is why a five-billion-dollar pre-commitment is a defensible bet rather than a moonshot.

The Regulatory Tailwind

Lightwell's launch is timed against a regulatory environment that has been moving toward exactly this model for two years.

The US Cybersecurity and Infrastructure Security Agency's (CISA) Secure Software Development Framework, in revisions through 2025, increasingly requires evidence-based attestation that an enterprise's open-source dependency graph is being actively maintained. The 2026 update made that requirement specific: an enterprise must demonstrate not just an SBOM, but an active patch-management process against that SBOM. A clearinghouse subscription satisfies the requirement; a manual process does not, in practice, scale to meet the documentation burden.

The EU's NIS2 Directive, which took effect in October 2024 and reached its first round of compliance enforcement in early 2026, imposes similar requirements on critical-infrastructure operators. The three-speed-AI-governance analysis covers the broader EU regulatory landscape; the supply-chain piece of NIS2 is the specific hook for Lightwell-class offerings.

The UK Cyber Resilience Bill, which received Royal Assent in March 2026, contains a near-identical supply-chain attestation requirement. The OCC's enhanced supervision framework for US bank holding companies, updated in the same March 2026 window, requires the eleven firms in the Lightwell adopter list to demonstrate "continuous validated patch management" on all critical open-source dependencies. There is no plausible interpretation of that requirement that a bank's internal team can satisfy without a clearinghouse-class vendor.

The regulatory tailwind is what makes Lightwell defensible against in- house alternatives. The same regulation that makes Lightwell mandatory also makes the in-house alternative uneconomic.

What Could Go Wrong

The bear case has three components.

Glasswing or Trust Access for Cyber expands into the clearinghouse layer. Anthropic and OpenAI both have the model capability and the engineering organizations to compete in Lightwell's lane if they choose to. The lab-led clearinghouse has different defensibility properties — better model quality, weaker enterprise sales motion, weaker upstream- community relationships. Whether IBM's enterprise distribution advantage outweighs the labs' model advantage is the most-important competitive question of the next twelve months. Today the answer is "Lightwell wins on enterprise distribution"; in twelve months the answer might be different.

Upstream community degradation outpaces Lightwell's mitigation spending. If the one-third upstream-facing headcount is not enough to maintain volunteer maintainer engagement, the long-term health of the ecosystem deteriorates and the clearinghouse becomes responsible for absorbing the maintenance work entirely. The cost structure of the program changes from "pay engineers to operate a clearinghouse" to "pay engineers to be the maintainer community," which is a meaningfully more expensive proposition.

A successful Lightwell-attributed breach. Any clearinghouse becomes a single point of trust. If a Lightwell-issued patch turns out to contain a backdoor (intentional or otherwise) or a vulnerability is missed and a breach is later attributed to it, the regulatory hook that made Lightwell mandatory becomes the regulatory hook that requires alternatives. Clearinghouses have an asymmetric reputation risk profile — the upside case is "boringly reliable for a decade," the downside case is "one incident ends the franchise."

The bull case is straightforward: Lightwell continues to scale, the upstream investment is sufficient to maintain community health, the regulatory tailwind compounds, and by 2029 the program is the de facto operating system for enterprise open-source maintenance.

The most-likely outcome sits between the two extremes. Lightwell becomes the dominant clearinghouse for regulated industries (banking, healthcare, critical infrastructure), competes for the broader enterprise market with Glasswing-derivative offerings, and the OSS community settles into a two-tier model where corporate forks of the most-deployed packages get better maintenance and longer-tail packages get less attention.

The Two-Tier OSS Question

The structural concern about Lightwell that takes the longest to engage with is what happens to packages outside the top-fifty most-deployed list — the long tail of open-source software that the eleven-bank adopter list does not directly depend on.

The top-fifty packages (the React ecosystem, the Python data-science stack, the major Linux distributions, Kubernetes, the major databases, the major language runtimes) are clearly inside Lightwell's coverage. The clearinghouse has every reason to invest heavily in maintaining them — they are what the subscribers run. The economic incentive to keep contribution velocity high on those packages is direct and quantifiable.

The next thousand packages — slightly-less-deployed libraries, niche but important tooling, language-specific frameworks that serve large but non-financial-services audiences — sit in a more ambiguous zone. Some of them will be inside Lightwell's coverage; some will not. The cutoff will be set by where the subscriber-revenue math justifies the maintenance investment.

The long tail — the hundreds of thousands of OSS packages that are used by a few projects each, the small utilities that solve specific problems, the experimental and educational projects — is outside Lightwell's coverage entirely, by design. The clearinghouse's economics do not reach down that far, and probably should not.

The chart describes the two-tier dynamic. The top tier gets better maintenance under Lightwell than it had before. The bottom tier gets roughly what it had before — volunteer maintenance at variable velocity, periodic security scares, the occasional famous incident. The middle tier is the contested zone, and the negotiation over which middle-tier packages get the clearinghouse's attention will set the de-facto maintenance hierarchy of the OSS ecosystem for the next decade.

The risk in the middle tier is specifically that a package's inclusion or exclusion from Lightwell coverage becomes a self-fulfilling property. Packages inside coverage attract more enterprise adoption (because the enterprises can attest to the maintenance). More adoption justifies more clearinghouse investment, which produces better maintenance, which attracts more adoption. Packages outside coverage do the opposite. The ecosystem stratifies into a "Lightwell-maintained" tier and a "community- maintained" tier, with the boundary set by an economic logic that does not necessarily match technical merit.

This is the part of the story that the open-source community is right to be uncomfortable with. The mitigation, if there is one, is the upstream- maintenance portion of the Lightwell engineering force funding the middle tier explicitly rather than only the top tier. Whether that happens at scale is a 2027-2028 question.

The International Story

The named-adopter list is heavily US-skewed. Eight of the eleven firms are US-headquartered; two are dual-headquartered between the US and the UK/EU; one is Canadian. The European and Asian adopter trajectory will be different in shape and timeline, and the international story matters for the program's eventual scale.

The European adopter dynamic is constrained by data-residency rules and by the fact that some of the subscriber data flowing into the clearinghouse (the SBOM, the deployment manifests, occasionally the vulnerability-specific context) is treated as regulated data under NIS2 and GDPR. Lightwell's European offering will need to operate from European-hosted infrastructure with European-resident engineering teams. IBM has the infrastructure footprint to do this; the engineering team buildout is the gating constraint, and the program's announced hiring plans include explicit European expansion.

The Asian adopter dynamic is more bifurcated. Japan and South Korea have regulatory environments that map cleanly onto the Lightwell proposition — large regulated financial firms with significant OSS exposure, comparable supply-chain attestation requirements, and existing IBM/Red Hat enterprise relationships. Singapore is similar. China is unreachable for a US-headquartered program of this profile; the equivalent function in China will be provided by a domestic vendor (likely from the Alibaba or Tencent infrastructure orbit) with a similar architecture but no operational tie to Lightwell.

The international trajectory matters because the case for IBM's five- billion-dollar commitment depends on Lightwell achieving global scale, not just US scale. The US-only revenue ceiling, even at full adoption of the regulated-industry tier, is not large enough to justify the program's investment on its own. The European and Asian tiers are where the difference between "a successful niche product" and "the de facto OSS-maintenance utility for the global enterprise" gets decided.

What This Means for OSS Maintainers

If you are a maintainer of a widely-deployed open-source package, the Lightwell-era reality has three implications.

Your work becomes more visible, more leveraged, and more commercially-relevant — and also more constrained. The clearinghouse wants your project to remain healthy. It will fund you, sponsor you, embed engineers with you. The funding is genuine. The constraint is that your project's direction increasingly takes corporate-customer requirements into account, because the corporate customer is now paying you (directly or indirectly) and your reach has multiplied by the clearinghouse's distribution.

Your incentive to take "uncommercial" architectural decisions — a major rewrite that breaks API stability for the long-term health of the codebase, a deprecation of a feature that has many users but is fundamentally unsafe — is correspondingly weaker. The maintainer who historically had absolute authority over the project's direction now has to weigh the clearinghouse's downstream implications.

This is the trade-off open-source has been negotiating with corporate sponsorship since the Linux Foundation was founded. Lightwell is the most concentrated version of the trade-off the ecosystem has yet seen, because it operationalizes the corporate relationship at a scale and a structural position that previous corporate sponsors did not occupy.

The Forward Reading

Three things to track over the next twelve months.

Whether Glasswing or Trust Access for Cyber expands into the clearinghouse layer. If Anthropic or OpenAI announces a competing program in 2026, the competitive dynamic shifts decisively. If they do not, Lightwell consolidates the position and the next entrant has a much harder problem.

The contribution-velocity data on the top-fifty OSS packages through 2027. If upstream contribution velocity holds or grows on the most- deployed packages, Lightwell's upstream investment is working. If velocity drops, the upstream-degradation risk is materializing and the ecosystem-level cost of the program becomes part of the conversation.

The mid-market subscription uptake through 2027. The named-adopter tier is locked in; the question is whether the mid-market expands at the rate Lightwell's revenue model requires. If yes, the program is on its base-case trajectory. If no, Lightwell remains a niche regulated- industry offering rather than the de facto operating model for enterprise OSS maintenance.

The structural read is that Lightwell is the first attempt to industrialize open-source security maintenance at the scale the AI era requires, and the structural reading is mostly favorable. The execution will determine whether the favorable structure produces a favorable outcome.

Further Reading

• Glasswing Asymmetry — Anthropic's operational-technology security bet — the comparison program at the model layer.
• Three-Speed AI Governance — US, EU, UK regulatory divergence — the regulatory backdrop that makes Lightwell-class offerings defensible.
• The Open-Weight Safety Mirage — abliteration analysis — the parallel story about why model-level security claims have stopped being load-bearing.