1. What Glasswing actually showed
On April 7, 2026, Anthropic announced Project Glasswing — a partnership with AWS, Microsoft, Google, Apple, Broadcom, Cisco, CrowdStrike, JPMorgan Chase, NVIDIA, Palo Alto Networks, and the Linux Foundation. The framing was straightforward: secure the world’s most critical software against a new class of AI capability. The capability in question is Claude Mythos Preview, an unreleased frontier model that, in the preview phase, identified thousands of high-severity vulnerabilities — including bugs in every major operating system and every major web browser. Some of these had survived decades of human audits, fuzzing campaigns, and open-source scrutiny.
The scope matters for what comes next. Glasswing tested operating system kernels, browser engines, and codec libraries. It did not test telecom BSS. It did not test billing systems, charging engines, mediation platforms, or order management stacks. Anyone telling a telecom CISO that Glasswing has anything direct to say about their billing environment is conflating a press release with an audit.
But the more interesting reaction came not from Anthropic’s marketing — it came from Hacker News. Within a week, a reproduction post appeared from Vidoc Security titled “We reproduced Anthropic’s Mythos findings with public models.” Using Opus 4.6 and a deterministic harness that walked target codebases file-by-file, they hit many of the same vulnerabilities. The thread that followed is more useful than the original announcement, and a commenter going by “jerf” wrote what is probably the clearest analysis of why this matters: the discovery step was already accessible. The thing Mythos changed is the cost calculus on the exploitation step. Mythos turned vulnerabilities into working JavaScript shell exploits 181 times in attempts where Opus 4.6 had managed it twice. That delta — from “lots of plausible bugs” to “working exploit, push button, get shell” — is the part that breaks the existing defender model.
That delta is what your BSS environment needs to reckon with. Not because Mythos will be pointed at it. Because something further down the capability curve already can be.
2. The real threat is open-weight, local, and cheap
Anthropic restricted Mythos Preview to Glasswing partners — which is sensible policy, and gives defenders a temporary advantage. The threat to your revenue assurance environment was never going to come through that door anyway.
The threat comes through a door that has been open for two years and is widening every month. As of March 2026, Hugging Face hosts an empirically documented 8,608 modified open-weight model repositories, according to peer-reviewed research published in Future Internet. The same study tested 20 representative modified models against unsafe prompts. Unmodified base models complied with 19.2% of unsafe requests — refusal vectors mostly intact. The modified variants complied with 80%. That’s a complete inversion of the safety layer, achieved at home, with no API call to log it. The compliance rate was independent of model size — a 14B-parameter abliterated model matched 70B-parameter variants on bypass effectiveness.
The hardware to run this is not exotic. Qwen 2.5-Coder-Uncensored, GLM-4.7-Flash-NEO-CODE, DeepSeek-R1-Distill-Qwen-14B-Uncensored, and Llama-derived code-finetuned variants all run on a single consumer GPU in the 24-48GB range. A used RTX 3090 plus a workstation runs about $2,000 today. A Mac Studio with 192GB unified memory runs every model on the current uncensored leaderboard at Q8 precision. Cloud spot instances make even the larger 70B-class deployments accessible by the hour. The capability that mattered five years ago — having a research budget, having a frontier lab, having API access — is no longer the gating factor. The gating factor is now which codebase you point it at.
And here is where telecom revenue assurance becomes uniquely exposed.
3. Why the BSS surface fits the profile
The categories of code that Mythos demonstrated against — and that public-model reproductions can also probe — share a profile. They are old. They are critical. They handle untrusted input. They’ve been audited by humans for years, but rarely with the offensive intensity of an AI-driven scanner. They have not been fuzzed with modern tooling.
Now describe a typical operator’s BSS middleware stack. Components written between 2005 and 2015 are still running production in every operator I’ve worked with — Every regional integration project I’ve audited since. Mediation transformation rules in proprietary scripting languages. Custom rating logic in product catalogs that have absorbed fifteen years of M&A migrations. Interconnect API adapters built before zero-trust was a vocabulary item, often using shared secrets that haven’t been rotated since the original integration. Internal admin consoles with privileged write access to billing, running on web frameworks that nobody on the current operations team would choose if they were starting today.
That’s the analogy. Not “Glasswing audited your stack.” It’s: the class of code your BSS sits in is precisely the class where this generation of models — frontier or open-weight — finds bugs that human review missed.
The five surfaces, in order of what I have actually seen exploited in regional incidents:
The interconnect API surface is first because it’s the most under-defended given its sensitivity. Every operator has partner-facing APIs for roaming hub integration, MVNO partners, content settlements, clearing house messaging. The credentials are old. The code paths are rarely re-reviewed. A compromised partner credential is an authenticated path into your charging environment. The product catalog comes second — accumulated plugin code, custom rating logic, transformation scripts written by engineers who left a decade ago. Each is an injection surface if anything user-controllable touches it. Mediation transformation rules are third: proprietary scripting against malformed CDRs from compromised network elements, with input validation that wouldn’t pass any modern code review. The customer-facing portal and APIs are fourth — visible enough that operators have invested in WAF and bot-protection, which actually helps here. The internal admin and CRM consoles are fifth and the highest-value target: privileged write access, ancient frameworks, daily use by thousands of agents.
For each of these, the operative question is no longer “could a determined nation-state attacker find something here?” It’s: when a fine-tuned 14B model with a bespoke harness is run against this code by someone with a $2,000 rig and an axe to grind, what does it find?
For most operators, the honest answer is: things nobody has looked for in fifteen years.
4. The revenue assurance angle: this is now an RA problem
It’s tempting to file all of this under “security” and assume it lives in the CISO’s organization. That framing is incomplete. Revenue assurance is the function that owns the consequences when this code is exploited.
Consider the mechanism. International Revenue Share Fraud (IRSF) already costs the industry approximately $6.1 billion annually per CFCA data. The 2025 CFCA Fraud Loss Survey put total telecom fraud losses at $41.82 billion globally — up nearly $3 billion in two years. The FCC reports individual operators losing 3-8% of revenue to fraud, with monthly fraud bills at affected operators ranging $500,000 to $2 million. These numbers are pre-AI. They were already accelerating because of AI in the social-engineering layer — Hiya’s State of the Call 2026 report found 1 in 4 Americans received a deepfake voice call in the past 12 months, and consumers ranked scammers as winning against carriers nearly 2-to-1.
Now layer the new capability. An attacker with an uncensored local model and basic tooling can do three things they couldn’t reliably do a year ago, all of which compound directly into revenue leakage that flows through your RA workflow.
First, automated reconnaissance against integration code. If you exposed an API for a roaming partner in 2014, the attacker can now reasonably expect a model to read it, infer the authentication scheme, and identify weak points without months of human reverse engineering. The cost-per-target on this work has collapsed.
Second, exploit generation specifically tuned to telecom workflows. Subscription fraud — the largest single fraud category in CFCA’s 2025 data at $5.31 billion — depends on identity verification flows that an attacker now models far more easily, especially with deepfake voice augmenting the social engineering layer. First-party subscription fraud added another $4.89 billion. These figures are growing because attacker tooling improved. The next inflection is when exploit generation against the operator’s own onboarding code gets built into the same toolchain.
Third, IRSF and bypass automation. SIM box operators have always operated at the edge of detection because their tooling was good enough; now that tooling is going to integrate live exploit generation against operator detection systems themselves. The detection ML you built last year is in-scope as an attack target.
All three of these flow through the leakage that RA already tracks. The revenue assurance team that today reconciles CDRs against billing, the team I described in the closed-loop recovery post, is going to find their exception queue absorbing categories of fraud that didn’t have signatures last quarter. The five leakage signatures I outlined in the previous post — mediation gaps, catalog misconfiguration, interconnect reconciliation, discount misapplication, roaming settlement — each of these now has an adversarial overlay where the “configuration error” might in fact be a deliberate exploit chain.
Closed-loop recovery, in the architecture I described, includes a validation step. The validation step is going to need to distinguish a measurement artifact from a misconfiguration from a genuine adversarial action. That third category is going to grow.
5. What operators should actually do
Three actions, in priority order, none of which require Mythos-class capability on the defender side.
Inventory the integration surface. Most operators cannot produce a current, accurate list of their BSS integration endpoints — APIs, message queues, file drop locations, database links — across vendor products. This inventory is the prerequisite for everything else. If you cannot list it, you cannot defend it. The first job is mechanical: a complete map, cross-referenced with the system that owns the credential and the date the credential was last rotated. Most operators will discover items on this list that nobody has thought about since the original integration go-live. Those are your priorities.
Pre-fuzz the high-risk surfaces with the tooling that exists today. AFL, libFuzzer, and modern commercial fuzzing platforms are mature and substantially better than nothing. Targeted fuzzing of mediation transform code and interconnect API adapters will surface a meaningful percentage of what an AI-driven scanner would later find. You do not need the frontier model. You need to find it first. This work is also genuinely accelerated by current public coding models — the tooling to write fuzzing harnesses is one of the use cases where mainstream LLMs are reliably useful, and the operational lift is small.
Treat the integration glue as in-scope for security review, continuously, not annually. The vulnerabilities in a BSS stack are usually not in Amdocs CES or Ericsson OCS or Netcracker. The vendors patch their own products. The vulnerabilities live in the custom integration code — message transformations, API adapters, database synchronization logic — that connects vendor products together. That code is owned by the operator or by the SI who built the integration, and it is where the un-audited surface is largest. Quarterly review cycles, narrowly scoped, against the highest-risk endpoints identified in step one. Build the cycle into operations the same way RA reconciliation runs.
There is also a procedural layer that sits above all three. Compress the patching pipeline for security-critical fixes. The standard telecom patching cycle — quarterly maintenance windows for billing systems, regression test cycles measured in weeks for anything touching revenue calculation — was designed around release management, not incident response. If your security incident response can detect a compromise within 24 hours but your patching pipeline takes 90 days to deploy a fix, you have an 89-day exposure window that no detection capability can close. That is an architectural problem, not an operational one. The procedural fix is a separate fast-track patch process for security flaws, pre-authorized by the BSS operations team within defined criteria, that doesn’t go through the normal change advisory board.
The regulatory layer will move on this. NDMO in KSA, TDRA in UAE, and PTA in Pakistan are each tracking AI-driven cybersecurity risk in their respective consultative documents through 2026. The right question for an operator’s board is not “are we compliant today” but “where will the regulatory perimeter sit in 18 months, and is our integration code clean enough to be audited against a stricter standard.”
For SIs delivering BSS work into the region: security review of custom integration code is going to become a standard line item in BSS RFPs, especially in NDMO-supervised environments. Operators will start asking. The SIs who can credibly demonstrate secure-by-design integration practices — code review against modern security standards, fuzzing of high-risk transformations, signed audit trails of build artifacts — will have a differentiator. The SIs who can’t will lose bids on grounds they haven’t seen before.
6. The argument in one sentence
Glasswing is the marquee event. The actual operational threat to telecom revenue assurance is that the same class of capability — somewhat diminished, qualitatively similar — is now running on consumer hardware in the hands of people whose interest in your billing system is not academic. Your RA architecture, your fraud management platform, your integration code: all of these were built against an attacker model that no longer applies.
The operators who will weather the next 18 months without a major BSS security incident are not the ones who bought the best perimeter defense. They’re the ones who took the integration layer seriously before they had to.