Three days. That is how long Claude Fable 5 and Claude Mythos 5 lasted in the wild before the <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.anthropic.com/news/fable-mythos-access">US government ordered</a> Anthropic to pull the plug on both models worldwide. On June 9, 2026, Anthropic launched what it called its most capable public model ever. By the evening of June 12, an export control directive citing "national security authorities" forced Anthropic to disable access for every customer on the planet, including its own foreign national employees.If you read our earlier piece, "<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/the-myth-of-mythos-why-anthropic-is-selling-you-fear-before-they-sell-you-s">The Myth of Mythos: Why Anthropic Is Selling You Fear Before They Sell You Safety,</a>" you'll remember our core argument: Anthropic has built a business model where the scariness of its own models is part of the pitch. Every launch comes wrapped in warnings about catastrophic misuse, cyberweapons, and existential risk, conveniently timed right before a funding round.This week's events complicate that story, but they don't erase it. If anything, they reveal something messier and arguably more important: a regulatory system that is now reacting to AI hype almost as fast as labs can generate it, sometimes without waiting to confirm whether the hype is true.<h2>What Actually Happened</h2><img src="https://cdn.calebms.com/articles/24e7ee0a-a7ca-4f93-9ad7-dae12887b81d.jpg" alt="82895.jpg" data-caption="A screenshot of Anthropic tweet regarding the US government order to suspend access to Fable 5 and Mythos 5">According to <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.anthropic.com/news/fable-mythos-access">Anthropic's own statement, </a>the directive arrived at 5:21pm Eastern on June 12. The letter did not specify the exact national security concern, but Anthropic's understanding is that the government became aware of a method for "jailbreaking" Fable 5, essentially a way to bypass its safety guardrails.Anthropic says it reviewed the demonstration behind this and found it amounted to a narrow, non-universal jailbreak: a way to get the model to read a codebase and identify a handful of previously known, relatively simple vulnerabilities. Crucially, Anthropic claims other publicly available models, including OpenAI's GPT-5.5, can find these same vulnerabilities without needing any jailbreak at all.<ad-spot></ad-spot>In Anthropic's words, no universal jailbreak (one that broadly unlocks dangerous cyber capabilities across the board) has been found. What was reportedly demonstrated to the government was, by Anthropic's account, something closer to "the model can help find bugs in code," which is also something defenders use every day.Because the export control directive applies to any foreign national anywhere, including Anthropic's own staff, the company says the only practical way to comply was to shut both models down entirely, for everyone, rather than try to selectively restrict access by nationality. Every other Claude model remains unaffected.Anthropic's response is notably blunt for a company that usually leans into safety messaging. It says it disagrees with the action, calls it a misunderstanding, and argues that if "a narrow potential jailbreak" is sufficient grounds to recall a commercially deployed model, "it would essentially halt all new model deployments for all frontier model providers."<h2>Why This Doesn't Prove Anthropic Built "The Best Weapon"</h2>It's tempting, especially after our last article, to read this as confirmation that Anthropic's models really are as dangerous as the marketing suggests, perhaps even more so, since now a government has acted on it. But that reading doesn't hold up well against the actual sequence of events.A government export control directive is not a verdict on capability. It's a regulatory action triggered by a report of a vulnerability, one that Anthropic disputes the severity of, and one that by Anthropic's account is already replicable by competing models without any special bypass. If the underlying capability genuinely isn't unique to Fable or Mythos, then banning only Anthropic's models doesn't tell us much about how powerful those models actually are relative to everything else on the market.What it does tell us is that the US government is willing to act fast, abruptly, and broadly when it believes a frontier AI system might pose a security risk, even when the evidence presented is, in Anthropic's framing, "verbal" and lacking specific detail.<ad-spot></ad-spot>That's a very different headline than "government bans Anthropic's model because it's too powerful to exist." It's closer to "government bans Anthropic's model because it's worried, possibly more than the facts currently justify, and would rather act first and sort out the details later."<h2>The Real Story: Regulation Can't Keep Pace With Release Cycles</h2>Here's where we'll soften our earlier critique a little. Our original piece argued that Anthropic's repeated invocations of catastrophic risk were largely a marketing device, a way of making "this model could end the world" sound like a feature rather than a bug. We still think there's truth to that. But this week's events suggest something else is also true: regulators increasingly can't tell the difference between marketing-driven fear and genuine cause for concern, because they don't have the time, tools, or technical depth to evaluate frontier models on the timescale labs are now shipping them.Anthropic itself has acknowledged this dynamic publicly, in its "<a target="_blank" rel="noopener noreferrer nofollow" href="https://darioamodei.com/post/policy-on-the-ai-exponential">Policy on the AI Exponential" framework</a>, which argues that policymakers need a transparent, fair process to evaluate and potentially block dangerous deployments. The irony is that this week's action looks like exactly the kind of move Anthropic warned could happen if that process isn't built properly: a fast, opaque, broad-brush intervention based on incomplete information.Consider the pace involved. Fable 5 and Mythos 5 launched on June 9. A jailbreak demonstration was reportedly shared with the government sometime in the following 72 hours. By June 12, an export control directive, the kind of instrument typically associated with restricting weapons technology or sensitive semiconductors, was issued for a chatbot model. According to reporting from Isaacus, this appears to be the first time the US has issued an export control directive for LLM access at all.When the regulatory toolkit's response to "we're worried about this AI model" is "ban it for every foreign national on Earth, including the company's own staff, with three days' notice and no detailed evidence," that's not a sign of careful oversight. It's a sign of an agency that knows it's behind and is choosing to err drastically on the side of caution because it has no better option. Better safe than sorry, as I put it, but "safe" here means "blunt enough to shut down a global product overnight based on a report nobody outside the agency has fully seen."<h2>What This Means for Anthropic's Valuation Story</h2>Now, to the investor angle, because that's where this gets genuinely interesting for our audience.Anthropic was reportedly valued around 980 billion dollars in its most recent funding round. The instinct might be to assume a government ban on your newest flagship product is bad news for that number. And in the short term, it probably doesn't help; headlines about regulatory bans rarely calm investor nerves.But there's a more cynical read, and it's one that fits uncomfortably well with our original "Myth of Mythos" thesis. Anthropic's entire pitch to investors has been that its models are at the frontier of capability and risk simultaneously, and that this dual nature is precisely why Anthropic, not its competitors, should be trusted with the resources to build AGI safely. A government ban, regardless of the underlying technical merits, is a vivid, real-world demonstration that someone with real authority believes Anthropic's models are powerful enough to warrant export controls.For a company whose valuation is built substantially on a narrative of "we are building something so significant that the rules of normal software companies don't apply to us," having a government agency treat your product like a controlled technology, even briefly, even disputedly, is a strange kind of validation. It doesn't matter whether the jailbreak was "real" in the sense of being uniquely dangerous. What matters for the narrative is that it happened, it was newsworthy, and it reinforces the idea that Anthropic operates in a different risk category than other AI labs.<ad-spot></ad-spot>Whether this pushes Anthropic past a trillion dollar valuation, as has been speculated, is genuinely hard to predict. Markets could read this as "regulatory risk just got real for AI labs," which is a negative for valuations across the sector, not just Anthropic. Or they could read it as "Anthropic's models are taken seriously enough by the US government to warrant export controls," which, however perversely, fits the existing hype narrative investors have already bought into. Both readings are plausible. Neither is certain.<h2>Connecting the Dots: Hype, Fear, and the Trillion Dollar Question</h2>This brings us back to our other recent piece, "<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/everyone-betting-trillions-ai-so-why-nobody-found-business-case">Everyone's Betting Trillions on AI, So Why Has Nobody Found the Business Case?</a>" That article asked a simple question: if AI valuations are running this far ahead of demonstrated revenue and use cases, what exactly are investors pricing in?Events like this week's ban offer one answer: investors may be pricing in narrative momentum as much as fundamentals. A trillion dollar valuation isn't purely a bet on subscription revenue or API usage. It's increasingly a bet on which lab is positioned as the one governments, enterprises, and the public believe is "ahead," for better or worse. An export control directive, even one Anthropic disputes and calls a misunderstanding, becomes part of that positioning whether Anthropic wanted it or not.That's not necessarily healthy for the industry. When the regulatory system's primary tool is "ban it now, ask questions later," and when the businesses being regulated have an incentive to lean into "we're so powerful we're scary" framing anyway, you end up with a feedback loop where regulatory overreaction and corporate hype reinforce each other, regardless of what the underlying technology can actually do.<h2>What Better Oversight Would Look Like</h2>If there's a constructive takeaway here, it's this: both AI labs and regulators would benefit from a process that doesn't rely on either marketing claims or worst-case-scenario directives issued with three days' notice and minimal evidence.Anthropic has called for exactly this kind of framework publicly, evaluation processes with technical depth, transparency about what triggered an action, and proportionality between the evidence and the response. This week's events are, in a sense, a real-world stress test of the absence of that framework. A vulnerability report that Anthropic disputes as minor and non-unique somehow translated into a global shutdown of two flagship products within 72 hours of launch, with no detailed public explanation of what was actually found.Whether or not you think Anthropic's models deserve that level of scrutiny, and there's a reasonable argument that frontier models do deserve serious scrutiny, the process by which that scrutiny gets applied matters. Right now, it looks less like oversight and more like a fire alarm being pulled because nobody's sure where the smoke is coming from, and pulling the alarm is easier than finding out.For our readers, particularly anyone building on top of US-based AI models, the practical lesson might be the one raised by Isaacus in their response to the ban: any application depending on a US-based LLM is now demonstrably subject to being shut down at any moment, by export control directive, with essentially no warning. That's a sovereignty and reliability risk that goes well beyond questions of whether any individual model is "too dangerous." It's a question of how much control you actually have over the AI infrastructure your business depends on, and this week, the answer for two of Anthropic's models turned out to be: none at all.

When Regulators Panic Faster Than AI Labs Can Ship: What the Fable 5 Ban Really Tells Us

A new investigation reveals that tools freely available on the internet can dismantle the safety controls built into powerful open-source AI models in minutes, with no technical expertise required.For years, tech companies have poured tens of millions of dollars into building safety guardrails into their AI models. These guardrails are meant to prevent the models from producing dangerous content such as instructions for making weapons, code designed to steal financial data, or material that exploits children. They are, in theory, the last line of defence between powerful AI and catastrophic misuse.A new joint investigation by the <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.ft.com/content/5630ed79-a263-41ed-9a1a-321617ae310e">Financial Times</a> and the AI safety group Alice has now exposed just how thin that line is.Using a freely available software tool called Heretic, researchers were able to strip the safety guardrails from Meta's Llama 3.3 model in under 10 minutes, requiring no specialist hardware and no advanced technical knowledge. The Heretic tool removes safety guardrails from Meta Llama 3.3 and Google Gemma in under 10 minutes with no specialist hardware. What they were left with was an AI model willing to answer questions that its original version flatly refused, including how to synthesise dangerous chemicals and how to calculate lethal doses of biological toxins.<ad-spot></ad-spot>The findings have sent shockwaves through the AI industry, and they raise a question that policymakers, developers, and the public now urgently need to grapple with: if safety guardrails can be removed this easily, were they ever really safe to begin with?<h2>What Happened: The Investigation</h2>A joint investigation by the Financial Times and AI safety research group Alice revealed that modified versions of premier models from Meta Platforms and Google are being used to generate dangerous content.The tests were stark. A version of Google's open-source model Gemma 3 responded to a question on how to disperse chlorine gas through a crowded indoor space, generated code to steal credit card information, and wrote stories describing child sexual abuse. The FT was able to use Heretic, a tool available on the popular code repository GitHub, to remove the guardrails from Meta's Llama 3.3 model in less than 10 minutes without any specialist hardware. The modified model responded to prompts on topics the original system refused to discuss, such as the number of micrograms of ricin per kilogram of body mass required to achieve a 50 per cent chance of death.These are not edge-case scenarios. They are precisely the kinds of outputs that AI safety systems are specifically built to prevent. The fact that they could be unlocked in the time it takes to make a cup of tea is a sobering revelation.<h2>The Tool Behind It All: What Is Heretic?</h2>At the heart of this story is a tool called Heretic, created by a developer named Philipp Emanuel Weidmann. Heretic is described as a tool that removes censorship, also known as "safety alignment," from transformer-based language models without expensive post-training. What it does is "abliteration": it seeks out a model's directions that refuse harmful requests and removes them. What makes Heretic so powerful is that it does all this completely automatically, according to its GitHub page.<ad-spot></ad-spot>Weidmann has been candid about the scale of what his tool has enabled. According to Heretic creator Philipp Emanuel Weidmann, the software has already been used to create more than 3,500 so-called "decensored" AI models. He also claimed these modified systems have been downloaded around 13 million times since the tool launched.To underscore just how rapidly this can happen, Weidmann told the FT that he had removed safeguards from Google's Gemma 4 model within 90 minutes of its release. In other words, the moment a new safety-aligned model drops publicly, it can be stripped of its protections before most people have even heard about it.<h2>What Is "Abliteration" and How Does It Work?</h2>To understand why this is so effective, it helps to understand the underlying technique, known as abliteration.Abliteration finds a "refusal vector" and removes it. The technique involves running the model on two datasets, one with harmless prompts and one with harmful prompts, measuring how the model's internal activations differ between them, and then removing the directions responsible for those refusals.Think of it like this: when an AI model decides to refuse a dangerous request, it does so because certain patterns of activation in its neural network trigger a "stop" response. Abliteration identifies exactly where those patterns live inside the model's weights and surgically excises them without disrupting the model's general capabilities. The model continues to function well at everything else; it just stops saying no.Another toolkit called OBLITERATUS has also emerged, using a six-stage pipeline: load the model, collect activations from restricted versus unrestricted prompts, extract refusal directions using SVD decomposition, project out the guardrail directions, verify the model's core capabilities remain intact, then save the modified model. The fact that multiple tools now exist to accomplish this, with increasingly streamlined interfaces, points to an entire ecosystem forming around the removal of AI safety features.<h2>Why Open-Source Models Are Uniquely Vulnerable</h2>It is important to understand why this problem primarily affects open-source AI models, and not proprietary systems like Anthropic's Claude or OpenAI's ChatGPT.This technique cannot easily be applied to proprietary systems such as Claude or OpenAI's ChatGPT because the models' underlying code is not accessible to outsiders. Open-source systems, however, have historically narrowed the gap with leading proprietary versions within six to 12 months.This is the core tension at the heart of the open-source AI movement. Transparency, reproducibility, and democratized access to powerful tools are genuine goods. They lower barriers for researchers, startups, and developers worldwide, and they provide a counterweight to the concentration of AI power among a handful of private companies. But those same properties, including open weights and accessible code, are precisely what make models like Llama and Gemma so vulnerable to abliteration.When a company like Meta releases an open-weight model, it essentially hands the keys to the world. Any developer, researcher, or bad actor can download the full model and modify it however they choose. The safety fine-tuning that was applied during training is just another layer that can be peeled back. Unlike proprietary "closed" systems like OpenAI's ChatGPT or Anthropic's Claude, where the inner workings are kept strictly under lock and key, open models allow global developers to download and alter the underlying code.<h2>This Is No Longer a Job for Specialists</h2>Perhaps the most alarming aspect of these findings is not what the tools can do, but who can use them."Whereas historically it might have taken a more informed and persistent actor to strip out safety features, nowadays it's much easier for the average person," Kawin Ethayarajh, assistant professor of applied AI at the University of Chicago's Booth business school, told the FT.This democratisation of harm is a pattern we have seen repeat across technology. Once something that required specialist knowledge and dedicated infrastructure becomes accessible to anyone with an internet connection, the risk profile changes entirely. The conversation can no longer be about protecting AI from sophisticated nation-state actors or well-resourced criminal organisations. The question now is whether AI is safe from anyone with a grudge, curiosity, or bad intent.Reports of AI-related incidents rose 50% year-over-year from 2022 to 2024, and in the 10 months to October 2025, incidents had already surpassed the 2024 total, according to the AI Incident Database. The trajectory is not reassuring.<h2>How Did Google and Meta Respond?</h2>The responses from the two companies whose models were most prominently featured tell a revealing story.Google said "abliteration is a known technical challenge facing all open models" and that its open models "undergo rigorous internal safety evaluations prior to launch to help prevent these kinds of troubling examples." Meta declined to comment. A person close to the company said it assesses its open-source models' capabilities before releasing them, according to its Advanced AI Scaling Framework. Versions deemed to pose a "catastrophic" risk are not released to the public unless Meta finds sufficient mitigation measures.<ad-spot></ad-spot>What is notable here is the tone. Google's statement is an acknowledgment, not a solution. Calling abliteration a "known technical challenge" is accurate but also reads as a concession that no fix is forthcoming. Meta's silence, meanwhile, is telling. When your flagship open-source AI model is used to calculate lethal ricin doses, declining to comment is a choice.As for GitHub, which hosts Heretic, a spokesperson noted that hosting the source code for tools like Heretic is permitted because it provides a "net benefit to the security community." That framing may hold up in isolation, but it grows considerably more complicated when the tool in question has been used to generate 3,500 models downloaded 13 million times.<h2>The Policy and Regulatory Fallout</h2>The implications for regulation and enterprise use are enormous. The issue is now shifting from a technical debate into a much bigger conversation around enterprise liability, regulation, and AI governance.For businesses that have deployed Llama or Gemma models in their products or internal systems under the assumption that those models were safe, this investigation is a rude awakening. If a model's safety layer can be cleanly scraped away in minutes, any assurance made at the point of procurement is worth very little.The investigation demonstrates that safety constraints applied at the distribution layer cannot meaningfully restrict misuse of open-source models. Any AI company releasing open-source models now faces a structural credibility problem: safety commitments made at release can be nullified by anyone with an internet connection in under 10 minutes.Policymakers who have been designing regulatory frameworks around evaluating AI models at the point of release now face a fundamental challenge. The 13 million download figure means decensored variants are already in widespread circulation, making current regulatory arguments about open-source safety controls functionally moot for existing model generations.The revelations may sharpen concerns among policymakers and AI companies that safeguards imposed by model developers may become harder to enforce as open-source systems grow more powerful.<h2>What Are the Possible Solutions?</h2>There is no easy fix here, and it is worth being honest about that. Several approaches have been proposed, each with trade-offs.One option being explored is training models on datasets from which dangerous material has been removed in the first place, rather than simply applying safety fine-tuning on top of an existing model. The idea is that if the dangerous knowledge was never in the model to begin with, abliteration would have nothing to unlock. However, one researcher noted that removing dangerous material could make models "naive" and unable to detect when they were being used for "malicious purposes," adding it was "not clear at all that if you omit the harmful data, the model becomes a goody two-shoes."Another approach is to think about safety not at the model level, but at the infrastructure level. Runtime monitoring, application-layer guardrails, and continuous independent audits are all being discussed as ways to provide a second and third line of defence beyond what the model itself offers. The problem is that if someone is running a modified model locally with no intermediary infrastructure, none of these measures apply.<ad-spot></ad-spot>Some researchers have also pointed to the dual-use nature of abliteration as a reason not to ban the technique outright. These research-configured models operate under strict controls, in isolated environments, for specific evaluation purposes. They are more like crash test dummies than actual vehicles, specialised tools designed to help us understand safety dynamics, not to cause harm in the real world. Red-teaming, the practice of using modified models to test how other models withstand adversarial attack, is a legitimate and important part of AI safety research. Any policy response will need to grapple with that nuance.<h2>The Bigger Picture: What This Means for AI's Future</h2>There is a metaphor that keeps coming up in discussions about this issue, and it is apt. "The genie is out of the bottle," said Alice chief executive and co-founder Noam Schwartz. "Things that look like sci-fi are no longer sci-fi and we need as a society to prepare accordingly."This is not a problem that is going to be solved by a patch or a policy memo. Open-source AI is now powerful enough that its misuse is a genuine public safety concern, and the tools to enable that misuse are freely available, require no expertise, and have already been downloaded millions of times.The open-source AI community faces an increasingly uncomfortable reckoning. The values of transparency, democratisation, and open access that drove the movement are real and important. But so is the reality that those same values are being exploited to put dangerous capabilities in the hands of anyone who looks for them.There is no clean resolution to this tension. The most honest thing that can be said is that we are in a period where the rate of capability development in open-source AI has outpaced our collective ability to govern it responsibly. The FT and Alice investigation has not created this problem. It has simply, and starkly, made it visible.What is clear is that the AI safety debate is no longer abstract. It is not about hypothetical future systems or science-fiction scenarios. It is about models that exist today, running on ordinary computers, capable of producing genuinely dangerous outputs, and accessible to anyone willing to spend 10 minutes following instructions. The industry, regulators, and the public all need to be honest about that reality before meaningful progress can be made.

Anyone Can Now Strip AI Safety Features in Under 10 Minutes. Here's Why That's a Big Problem.

<h2>The Report Behind the Warning</h2>Visa <a target="_blank" rel="noopener noreferrer nofollow" href="https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-spring-2026-biannual-threats-report.html">released</a> its Spring 2026 Biannual Threats Report in late May 2026, drawing on intelligence gathered across its global payments network. The report tracks emerging fraud patterns, attack trends, and the shifting tactics of cybercriminals operating across digital payment systems worldwide.The headline finding is stark: from July to December 2025, Visa identified nearly $1 billion (approximately Sh160 billion) in scam-related activity globally, making scams the single largest category of consumer payment fraud for the period tracked. What makes this finding particularly alarming is not just the scale, but the nature of the attacks. These scams, for the most part, did not require criminals to breach any technology. No servers were hacked. No databases were stolen. Instead, the attackers went after something far more difficult to patch: human trust."Payments at a network level continue to get safer, but threats are evolving faster than ever," said Paul Fabara, Chief Risk and Client Services Officer at Visa. "Criminals are increasingly targeting people rather than technology, using deception, urgency, and AI-enabled tools to exploit trust."<ad-spot></ad-spot>This is not the story of a failed security system. It is the story of a security system that is working well enough that criminals have been forced to abandon traditional technical attack methods entirely, and pivot to manipulating the people who use those systems.<h2>When Security Works Too Well: How Fraud Migrates</h2>One of the more counterintuitive insights from the Visa report is that stronger security is partly driving the surge in social engineering scams. The report notes that fraud involving device tokens, a common target for technical attackers, declined by 9.6% between July and December 2025 compared to the same period in 2024. Stronger authentication systems, biometric verification, and network-level protections are clearly having an effect.But fraud is not disappearing. It is migrating. As technical entry points close, criminals are redirecting their efforts toward the one vulnerability that no software update can fully fix: human psychology.This shift is being supercharged by artificial intelligence. Michael Jabbara, Senior Vice President for Payment Ecosystem Risk and Control at Visa, summarized the problem clearly: "The rapid adoption of AI has fundamentally lowered the barrier to entry for fraud." Tools that once required technical expertise and significant resources to deploy are now accessible to a much wider pool of bad actors. AI allows scammers to craft highly convincing fake messages at scale, clone voices to impersonate known contacts or institutions, generate realistic synthetic identities to pass digital onboarding checks, and simulate official customer service interactions that are nearly indistinguishable from the real thing.<ad-spot></ad-spot>The result is a fraud economy that is both more scalable and more convincing than anything that came before it.<h2>Kenya's Specific Vulnerability</h2>Kenya's digital payments landscape is, in many respects, a triumph of financial innovation. M-Pesa, Safaricom's mobile money platform, processes more than $50 billion annually and serves a country where 82% of adults use mobile money, the highest penetration rate on the planet. Digital banking apps, fintech lending platforms, and e-commerce have all grown rapidly, bringing millions of Kenyans into the formal financial system for the first time.But that same openness and reach creates an enormous attack surface for fraudsters. And recent data shows they are exploiting it aggressively.According to a Central Bank of Kenya (CBK) report, fraud cases in Kenya's banking sector more than doubled in 2024, jumping from 173 to 353 documented incidents. The financial damage was even more striking: mobile banking losses soared by 344% to Sh810.68 million. Card fraud alone leapt 16-fold to Sh263.29 million, while identity theft rose six times to Sh199.08 million. In total, hackers siphoned a record Sh1.59 billion from bank customers in 2024, a year when total losses stood at just Sh412 million in 2023.The broader cyber threat picture is equally alarming. Between July and September 2025, Kenya's National KE-CIRT/CC (the national cybersecurity incident response body) recorded 842 million cyber threat events in just three months. Over the full 12 months ending June 2025, the Communications Authority of Kenya reported nearly 8 billion cyberattacks, more than double the previous year's figure. In the same period, Kenya lost an estimated Sh29.9 billion (about $230 million) to cybercrime.To put that figure in context: Sh29.9 billion is more than 10% of Kenya's entire annual health ministry budget.<h2>The Human Factor: Who Is Being Targeted and How</h2>The fraud methods targeting Kenyans reveal a clear pattern: criminals are going where the people are, and they are using psychological pressure to extract money or information before victims realize what is happening.A TransUnion Africa fraud analysis found that 82% of Kenyans were targeted by digital fraud attempts between August and December 2024. Of those targeted, 39% encountered smishing (fraudulent SMS messages), 36% faced phishing attempts, and 33% experienced vishing, where scammers called directly and tried to extract sensitive information. Around 9.8% of mobile money users reported a direct financial loss from fraud, according to the FinAccess 2024 Survey.The KE-CIRT/CC has consistently flagged impersonation as one of the dominant attack methods. Criminals pose as banks, mobile network operators, government regulators, and even well-known service providers to trick users into revealing PINs, OTP codes, or account credentials. SIM-swap fraud, where attackers convince a mobile carrier to transfer a victim's number to a new SIM card, remains one of the most destructive tactics, because it allows fraudsters to intercept one-time passwords and bypass two-factor authentication entirely.<ad-spot></ad-spot>2025 also saw the emergence of a particularly insidious trend in Kenya: AI-generated voices and profiles. Cybersecurity experts described 2025 as seeing "the highest volume of digital scams targeting ordinary citizens in over a decade," with fraudsters using AI-cloned voices to impersonate trusted contacts, fabricating screenshot evidence of earnings or transactions, and running fake investment and job recruitment groups on WhatsApp and Telegram that disappeared overnight after collecting deposits.The sophistication is escalating faster than defenses. A separate Nasdaq Verafin report from March 2026 found that AI-enabled or tech-assisted scam losses globally climbed 19.6% to $14.3 billion year-on-year, a figure that reflects just how rapidly the fraud economy is expanding its use of AI tools.<h2>The Four Trends Reshaping Payment Security Globally</h2>The Visa Spring 2026 Biannual Threats Report organizes the global threat landscape around four key trends, all of which have direct relevance to Kenya's situation:1. Security is working, but fraud is migrating. As highlighted earlier, improvements in device-level security and network authentication are reducing certain categories of technical fraud. But that success is pushing criminal activity toward softer targets, primarily human behavior.2. Scams are accelerating. Scams have now displaced all other forms of consumer payment fraud to become the dominant threat category. Unlike data breaches or card skimming, scams often result in authorized transactions, meaning the victim willingly initiates the payment under false pretenses. This makes recovery far more difficult.3. AI is transforming fraud on both sides. Fraudsters are using AI to make scams more scalable and convincing, while defenders are deploying AI to detect suspicious patterns earlier in the transaction lifecycle. Visa itself has invested $3.3 billion in AI and data infrastructure over the past decade and introduced three new AI-powered fraud prevention tools under its Visa Protect suite in 2024 alone.4. Ransomware is evolving, but resistance is growing. Globally, ransomware activity increased 26% in the second half of 2025, but only 23% of victims paid ransoms, the lowest rate on record. This suggests that organizations are investing in resilience and are increasingly unwilling to fund criminal networks even when data is at risk. It is a small but meaningful piece of good news in an otherwise challenging threat landscape.<h2>What Needs to Change in Kenya</h2>The Visa report and the broader data on Kenya's fraud landscape point to a clear conclusion: the next phase of digital payment security in Kenya cannot rely on technology alone. The human element needs equal attention.On the institutional side, the CBK is already taking steps. The regulator is laying the groundwork for a formal fraud compensation framework within the National Financial Inclusion Strategy 2025-2028, with rollout planned for 2026. The initiative promises digital complaint channels, greater transparency, and structured redress mechanisms for fraud victims, a recognition that fraud has become a systemic issue requiring systemic responses.Kenya's commercial banks and mobile money operators also need to accelerate investment in real-time fraud detection powered by AI. The same tools that fraudsters are using to scale their attacks can be deployed defensively to flag anomalous transaction patterns, detect voice cloning in customer service calls, and identify synthetic identities at the point of onboarding.<ad-spot></ad-spot>But technology-side defenses will only go so far if the human side remains undertrained. Consumer education needs to move beyond generic awareness campaigns and become practical, specific, and regularly updated. Kenyans need to understand exactly what an AI-cloned voice call sounds like and why a "bank representative" asking for an OTP is always, without exception, a red flag. Employers, schools, churches, and community organizations all have a role to play in spreading this knowledge to audiences that might not be reached by fintech-focused media.Chad Pollock, VP and General Manager for Visa East Africa, put the challenge directly: "Consumer education is our best defense against fraud, and industry collaboration makes this possible. As scams grow more sophisticated, the battle for security never stops."<h2>The Bigger Picture: Trust as Infrastructure</h2>There is a concept in development economics that is easy to overlook when discussing fraud statistics: trust is infrastructure. Kenya's mobile money miracle did not happen because of the technology alone. It happened because millions of people trusted the system enough to put their money into it, to pay each other through it, and to build their financial lives around it.AI-powered fraud attacks are, at their core, attacks on that trust. Every successful scam erodes confidence in digital payments, makes people more hesitant to transact electronically, and potentially pushes users back toward cash-based systems that are less transparent and harder to monitor. The damage extends well beyond individual victims.This is why the Visa report's framing matters. It is not just cataloguing losses. It is warning that the behavioral shift from technical hacking to human manipulation represents a fundamental change in the threat model, one that requires a fundamental change in the response.Kenya has proven, time and again, that it can lead Africa in financial innovation. The country's ability to protect that innovation, and the people who depend on it, will define whether the next decade of digital finance builds on that legacy or becomes a cautionary tale.

 AI Scams Are Now Kenya's Biggest Digital Payment Threat, Visa Report Warns

The Red Access findings exposed roughly 5,000 leaky apps. The real story is not about AI writing bad code. It is about what happens when deployment becomes frictionless and responsibility disappears.<hr>The internet had a minor panic recently. Israeli cybersecurity firm Red Access published findings that sent tech journalists scrambling: roughly 5,000 AI-generated web applications were found to be leaking sensitive data, including patient medical conversations, school lesson recordings, and internal staff schedules. The story spread fast, and the culprit was named quickly: vibe coding.It is a satisfying villain. The term, coined by AI researcher Andrej Karpathy in early 2025, describes the practice of using AI tools to generate and deploy software with little to no traditional coding experience. Type a prompt, click deploy, watch your app go live. The mental image practically writes the headlines itself.<img src="https://cdn.calebms.com/articles/11a0752e-eb06-4074-a6c4-bc97fa155598.png" alt="71620.png" data-caption="A Screenshot of X(formerly Twitter) by Andrej on Feb 2025">But here is what those headlines consistently miss: the problem was never that AI wrote the code. The problem is that an entire layer of architectural responsibility was abstracted away, and nobody noticed it was gone.<ad-spot></ad-spot><h2>What Red Access Actually Found</h2>To understand the findings clearly, it helps to look at the actual numbers. Red Access scanned approximately 380,000 publicly accessible assets created using popular AI-powered coding tools such as Lovable, Replit, Netlify, and Base44. Of those, about 5,000 apps exposed potentially sensitive information.Red Access CEO Dor Zvi described the findings as part of research into "shadow AI," the growing trend of employees using AI tools without formal approval from their organizations. The exposed data ranged from patient conversations to internal business documents. Zvi called it "one of the biggest events ever where people are exposing corporate or other sensitive information to anyone in the world."The companies behind the implicated tools pushed back. Replit CEO Amjad Masad noted that users choose whether their apps are public or private, and that the existence of a publicly visible app does not automatically constitute a security breach. That is a fair technical point, but it largely confirms the core issue rather than dismissing it: the users did not know that making something public meant exposing everything inside it. The configuration options existed. The understanding of what those options meant did not.That gap, between a tool existing and a user understanding what it does, is where nearly every modern security disaster lives.<h2>The Barrier That Dropped</h2>Before the AI-assisted development surge, shipping a broken application to production required a meaningful amount of friction. A developer had to know how to configure a server, understand how databases handle access, write enough code to make the application function, and debug the inevitable errors that appeared during that process. None of those tasks guaranteed security, but they created natural checkpoints. You could not accidentally deploy a misconfigured database if you did not first understand enough about databases to set one up.<ad-spot></ad-spot>AI tools did not invent misconfigured databases. They did not introduce insecure APIs, exposed secrets in client-side code, or privilege escalation vulnerabilities. They automated the process of reaching production faster than any of those issues could be caught.The numbers bear this out. <a target="_blank" rel="noopener noreferrer nofollow" href="https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/">Research from Apiiro</a> found that repositories with significant AI-generated code showed a 322% increase in privilege escalation flaws and a 153% rise in architectural design flaws. These are not typo-level bugs that a syntax checker catches. These are structural decisions about who should be able to access what, baked into the application from the moment it is prompted into existence.Meanwhile, a <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.veracode.com/blog/spring-2026-genai-code-security/">Veracode analysis </a>covering over 100 large language models across 80 distinct coding tasks found that approximately 45% of AI-generated code introduces security vulnerabilities. The overall security pass rate remained flat at around 55% in Veracode's March 2026 update, unchanged despite continued improvements in raw coding performance benchmarks. The AI is getting better at writing code. It is not getting better at securing it, because security is not what most prompts ask for.<h2>Why the AI Writes Insecure Code</h2>This is the part of the conversation that tends to get lost in the noise about vibe coding being reckless or AI being dangerous. The insecurity is not a malfunction. It is a mirror.Large language models learn to code by training on vast repositories of existing code. That existing code, accumulated over decades across GitHub, Stack Overflow, documentation, and open source projects, is full of insecure patterns. Developers have been writing SQL queries using string concatenation instead of parameterized inputs for thirty years. Hardcoded credentials have been appearing in version-controlled repositories since version control existed. If a meaningful percentage of the training data demonstrates an insecure pattern, the model learns that pattern as a valid way to solve that problem.Georgia Tech's Systems Software and Security Lab launched the Vibe Security Radar project in 2025 to track exactly how many publicly filed CVEs can be traced to AI-generated code. Their early results were stark: 86% of AI-generated samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection. Both of those vulnerability classes sit firmly on the OWASP Top 10 list of the most dangerous web application security risks. These are not edge cases. They are foundational web security concepts that have been understood for over two decades.The AI is not hallucinating new categories of insecurity. It is faithfully reproducing the insecurity that already existed in the code it was trained on, at scale, and at a speed that makes manual review harder to maintain.<h2>The "Vibe Coding" Scapegoat</h2>There is a subtle gatekeeping dynamic embedded in how these incidents get reported, and it is worth naming.When a major enterprise suffers a data breach, the coverage tends to describe it as a sophisticated cyberattack, a state-sponsored intrusion, or a complex supply chain compromise. When a solo developer's app leaks data after being built entirely with AI assistance, the story becomes about vibe coding culture, the recklessness of non-technical people shipping products, and the dangers of democratized software development.<ad-spot></ad-spot>In reality, the breach at a Fortune 500 company and the leak from a vibe-coded startup are often caused by the exact same underlying failures: misconfigured access controls, exposed API keys, absent row-level security policies, or a database that should have been private sitting in a publicly accessible environment. The difference is the post-incident framing, not the vulnerability class.OWASP recognized this in 2025 by adding a dedicated category to its Top 10 specifically calling out vibe coding as a risk pattern. That recognition is useful. But the same OWASP Top 10 has listed injection attacks, broken access control, and security misconfiguration as dominant risk categories for years, all of which appear regularly in codebases written by credentialed senior engineers with no AI involvement whatsoever.According to the <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.idtheftcenter.org/post/2025-annual-data-breach-report-record-number-compromises/">Identity Theft Resource Center's 2025 Annual Data Breach Report</a>, the United States recorded 3,332 data compromises in 2025, a new all-time record and a 79% increase over five years. That trajectory was established long before vibe coding existed as a term.<h2>The Two Types of AI-Assisted Developers</h2>The framing that "AI builds insecure apps" collapses a meaningful distinction that the actual security risk profile depends on entirely.The first type of AI-assisted developer is someone with an existing security intuition who uses AI tools as a high-speed pair programmer. They use AI to generate boilerplate code, scaffold components, and move quickly through problems they already understand. But they are reading the diff. They are thinking about the threat model. They understand what trust boundaries mean and why database access should be scoped to the minimum necessary level. For this developer, AI is a productivity multiplier, and the 3.6 hours per week saved in developer time gets redirected into review, architecture, and decisions that require contextual judgment the model cannot provide.The second type is what researchers have started calling "pure vibe coding": a user with zero security background who describes a product to an AI, receives a working application, and clicks deploy without reading a line of what was generated. This user does not know to ask whether the database is publicly accessible. They do not know what row-level security means. They cannot evaluate the access control logic because they do not know that access control logic needs to exist.The tool itself is identical in both scenarios. The risk is entirely determined by the pilot.A security scan in May 2025 of 1,645 web apps built on the Lovable platform found that roughly 10% had flaws exposing personal user data, specifically because creators relied on AI output without any review. That same year, 25% of startups in Y Combinator's Winter 2025 cohort reported codebases that were 95% AI-generated. Security researchers scanning close to 5,600 vibe-coded applications discovered over 2,000 vulnerabilities and more than 400 exposed secrets.AI-written code is not inherently bad. Deploying it unverified is.<h2>The Same AI Is Also Finding the Vulnerabilities</h2>There is an irony worth sitting with here. The same class of AI models being blamed for creating insecure applications is being actively deployed by security researchers to discover zero-day vulnerabilities in enterprise systems written entirely by human engineers, sometimes years or decades ago.Security teams at major firms are using large language models to analyze codebases for vulnerability patterns at a scale and speed that human reviewers cannot match. The AI does not discriminate between human-authored insecurity and AI-authored insecurity. It looks for patterns, and patterns are patterns regardless of who wrote the original code.This cuts both ways. AI generating insecure code is a concern. AI finding insecure code at scale is an asset. The organizations that understand both dimensions are already building processes that use AI for security scanning precisely because of the volume of AI-generated code now entering their pipelines.<h2>Where the Industry Actually Stands</h2>The scale of AI adoption in software development is now substantial enough that the question has shifted from whether AI will be part of production codebases to how the resulting risk will be governed.<ad-spot></ad-spot>According to current data, approximately 41% of all code written globally is AI-generated or AI-assisted, a figure that was just 6% in 2023. The AI coding tools market reached $7.37 billion in 2025 and is projected to hit $30.1 billion by 2032. GitHub Copilot alone has over 20 million cumulative users and is deployed across 90% of Fortune 100 companies. <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.sonarsource.com/state-of-code-developer-survey-report.pdf">The Sonar State of Code Developer Surve</a>y found that developers report approximately 42% of their code is currently AI-generated or assisted, and they predict that share will increase by more than half by 2027.That trajectory creates a straightforward implication: the differentiator going forward is not who uses AI. Nearly everyone does. The differentiator is who understands the security architecture of what the AI produced.The tools needed to close this gap exist. Static application security testing, or SAST, can scan AI-generated code before it reaches a pull request. Software composition analysis tools check dependencies for known vulnerabilities, which matters because AI models have training cutoffs and may recommend library versions that have since been flagged. Manual review of authentication flows, encryption implementations, and payment processing logic remains essential in any context where the AI cannot be trusted to understand regulatory requirements.OWASP's guidance recommends prohibiting AI-generated code in high-risk areas, specifically authentication, encryption, and payment processing, without mandatory human review. That is not anti-AI. It is the same principle that requires a licensed architect to sign off on structural calculations even when the initial design was drafted by a junior engineer.<h2>The Real Abstraction Problem</h2>The deeper issue the Red Access findings surfaced is not that AI generates bad code. It is that AI tools have abstracted the deployment process in a way that also abstracted away the accountability that used to come with it.<ad-spot></ad-spot>When building a web application required setting up a server, configuring a database, writing authentication logic, and managing credentials, the difficulty of doing those things badly was itself a forcing function. Developers who got those things wrong saw the consequences quickly, learned from them, and developed instincts over time. The friction was not purely overhead. Some of it was formative.No-code and low-code tools began eroding that friction years before large language models arrived. AI-assisted vibe coding accelerated the erosion dramatically. What results is a population of deployed applications built by people who have never had to think about whether a database connection string should be in client-side code, because they did not write the connection string, do not know it exists, and were never prompted to consider what happens if someone outside their organization finds it.That is not a story about evil AI. It is a story about what happens when the speed of deployment runs ahead of the culture of accountability around what gets deployed.The solution is not to slow deployment back down artificially. It is to build the accountability practices that frictionless deployment requires: automated security scanning baked into deployment pipelines, mandatory review checklists for AI-generated code that touches user data, and a shared understanding across teams that "it works" and "it is safe" are two different criteria that need to be evaluated separately.<h2>What Responsible AI-Assisted Development Looks Like</h2>Practically speaking, organizations and developers building with AI tools in 2026 need to treat security as an explicit requirement in every prompt, not an assumed default. Asking an AI to "build a user authentication system" will produce a working authentication system. Asking it to "build a user authentication system with secure password hashing, rate limiting on login attempts, and no exposure of session tokens in client-side storage" produces a materially different output.Review every piece of AI-generated code that touches authentication, data storage, third-party API calls, or user-facing inputs before deployment. Use free tools like OWASP ZAP or integrated scanning in your deployment pipeline. For any application handling personal data, medical records, financial information, or regulated data, professional security review is not optional.<ad-spot></ad-spot>The Red Access findings are a useful reminder of what the absence of that review looks like at scale. Five thousand applications, many of them built by people who genuinely did not know their users' data was accessible to anyone on the internet. Not malice, not negligence in the conventional sense, but a system where the ability to deploy arrived before the knowledge of what responsible deployment requires.That imbalance is correctable. The tools, the knowledge, and the awareness are all available. The question now is whether the culture of building with AI catches up to the culture of deploying with it.

Vibe Coding Is Not the Problem. Deploying Without Understanding Is.

It has been a rough few weeks to be a developer. If you host your portfolio, your side project, or your startup on Vercel, you have probably already seen the notification. On April 19, 2026, Vercel confirmed what the security community had already begun piecing together: an unauthorized actor had accessed certain internal Vercel systems. If you have not been contacted directly by Vercel, the company says you are likely not affected. But "likely" is doing a lot of work in that sentence, and given the scope of what is being claimed on hacking forums, the full picture is still emerging.Here at TechInKenya, we have been covering the growing wave of major security incidents in 2026, from <a target="_blank" rel="noopener noreferrer nofollow" class="underline underline underline-offset-2 decoration-1 decoration-current/40 hover:decoration-current focus:decoration-current" href="https://www.techinkenya.com/articles/anthropic-built-an-ai-that-can-hack-anything-then-accidentally-told-everyon">Anthropic accidentally leaking the source map for Claude Code and internal documents describing their most dangerous model yet</a> to the Axios supply chain attack that planted North Korean malware in a library downloaded over 100 million times a week. The Vercel breach is the latest episode in what is quickly becoming the most turbulent year in developer security in recent memory. Let us break down what actually happened, what you should do right now, and, yes, whether someone just used Mythos early access to pull this off.<ad-spot></ad-spot><h2>How It Actually Happened: A Roblox Script That Brought Down a Dev Platform</h2>This is where the story gets both technically fascinating and deeply human. The entry point for the entire Vercel breach was not a sophisticated zero-day exploit. It was not an AI agent autonomously chaining vulnerabilities in the dark. It was a <a target="_blank" rel="noopener noreferrer nofollow" href="http://Context.ai">Context.ai</a> employee downloading what were almost certainly Roblox "auto-farm" scripts.<a target="_blank" rel="noopener noreferrer nofollow" href="http://Context.ai">Context.ai</a> is a third-party AI tool that Vercel employees used internally. In February 2026, threat intelligence firm Hudson Rock identified that a <a target="_blank" rel="noopener noreferrer nofollow" href="http://Context.ai">Context.ai</a> employee with significant access privileges was compromised by Lumma Stealer, a widely distributed infostealer malware that is notorious for spreading through game cheats, cracked software, and, in this case, Roblox executors. The infected machine handed attackers a comprehensive set of corporate credentials: Google Workspace logins, Supabase keys, Datadog access, and Authkit credentials, including the <a target="_blank" rel="noopener noreferrer nofollow" href="mailto:support@context.ai">support@context.ai</a> account.With those credentials in hand, the attacker did not need to crack any encryption or find any zero-days. They used a malicious Google Workspace OAuth application to hijack a Vercel employee's Google account, and from there, pivoted into Vercel's internal infrastructure. Vercel has since published the malicious OAuth Client ID as an indicator of compromise: <code>110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com</code>. Any organization using Google Workspace should check their API controls for that application.CEO Guillermo Rauch described the attacker as "sophisticated," citing their "operational velocity and detailed understanding of Vercel's systems." That framing is accurate in the sense that the attacker moved quickly and understood the target well. But it is worth being precise: the initial access was not sophisticated at all. Lumma Stealer is commercially available malware. The sophistication was in knowing exactly what to do with the credentials once they were in hand.<h2>What the Attacker Claims to Have</h2>This is where the confirmed facts end and the contested claims begin, and the gap between the two is significant.A threat actor posting under the "ShinyHunters" name on BreachForums published a listing on April 19 claiming to be selling Vercel's internal data for $2 million, negotiable from $500,000 in Bitcoin. The listing claims to include multiple employee accounts with access to internal deployments, API keys, npm tokens, GitHub tokens, source code, and database data. As proof, the actor shared a text file containing records for 580 Vercel employees, including names, email addresses, account status, and activity timestamps, as well as a screenshot of what appears to be Vercel's internal enterprise dashboard.<img src="https://cdn.calebms.com/articles/a7aeed11-a16d-4b93-928e-f6f3c4401691.jpg" alt="65421.jpg"><img src="https://cdn.calebms.com/articles/cf3efee3-928a-4a94-9672-e0ca69c7a970.jpg" alt="65473.jpg">It is important to note that actual members of the ShinyHunters hacking group have separately denied to security media that they are involved in this incident. Whether that is true or a distancing tactic is unknown.Vercel's own <a target="_blank" rel="noopener noreferrer nofollow" href="https://vercel.com/kb/bulletin/vercel-april-2026-security-incident">bulletin</a> is notably terse. It confirms unauthorized access to "certain internal Vercel systems" and says a "limited subset of customers" was impacted and has been contacted. It does not confirm source code theft, and does not address the npm or GitHub token claims. CEO Rauch stated on X that the company has "analyzed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe." That statement is reassuring but does not cover the possibility that tokens granting write access to those repositories were briefly in the attacker's hands, even if they were not used.<ad-spot></ad-spot>The supply chain concern is the important one here. Vercel is the primary maintainer of Next.js, one of the most widely used web frameworks on earth, and Turbopack. If an attacker with valid GitHub or npm tokens published a malicious version of Next.js, the downstream impact would dwarf the Axios incident. As of publication, Vercel says no such tampering occurred. But until the investigation concludes and a more detailed post-mortem is published, this remains an open question that deserves to be taken seriously.<h2>What Vercel Users Should Do Right Now</h2>If you have a project on Vercel, here is your practical checklist, ordered by urgency.First, check your email. Vercel says it has contacted affected customers directly. If you have not received a message, you are likely in the clear, but do not assume that means you can skip the rest of these steps.Second, rotate all environment variables that are not marked as "sensitive." This is the most directly relevant action. The attacker accessed non-sensitive environment variables in Vercel's internal systems. Sensitive variables, those marked with Vercel's encrypted storage feature, appear to have been protected. Any API keys, database connection strings, third-party service tokens, or other secrets stored as plain environment variables should be considered potentially exposed and rotated immediately. Vercel has rolled out a new dashboard view specifically to help you audit these.Third, check your dashboard and CLI logs for unusual activity. Look for deployments you did not initiate, changes to environment variables you did not make, or any team member access from unexpected locations or times.Fourth, if your project is connected to GitHub, review your GitHub repository's authorized OAuth applications and recently active tokens. Go to Settings, then Developer Settings, then Personal Access Tokens, and check for anything unfamiliar. Do the same for your repository's deployment keys.Fifth, if you use npm to publish packages connected to your Vercel projects, review your npm account's published versions and recent activity. The Axios incident from three weeks ago should have you doing this anyway.Finally, check your Google Workspace connected applications if your organization uses Google for SSO with Vercel. Vercel published the malicious OAuth Client ID that was used in this attack. Search for it in your Google Admin Console under API Controls.<h2>A Note on the Mythos Theory</h2>We promised you a joke, so here it is: someone on Twitter has already suggested that the Vercel attacker must have gotten early access to Claude Mythos, used it to autonomously chain the <a target="_blank" rel="noopener noreferrer nofollow" href="http://Context.ai">Context.ai</a> OAuth credentials into a Vercel infrastructure compromise, and is now demanding $2 million just like a proper enterprise security firm would.<ad-spot></ad-spot>Honestly? The attribution for this one is far more mundane, and that is precisely what makes it terrifying. The most powerful hacking tool deployed in this incident was a Roblox cheat script. The attacker did not need Mythos. They did not need a 72.4 percent exploit success rate or a 20-gadget ROP chain. They needed one <a target="_blank" rel="noopener noreferrer nofollow" href="http://Context.ai">Context.ai</a> employee to make one bad download on a company machine, and then they needed to know where to pivot from there.That is the uncomfortable truth about 2026 security. We are spending enormous energy worrying about what AI can do to our defenses, while the oldest tricks in the social engineering playbook are still opening doors just fine.<h2>2026 Has Been a Catastrophic Year for Developer Trust</h2>The Vercel breach does not exist in isolation. It is the latest in a string of incidents that have systematically undermined the trust developers place in the tools they use every day, and it is worth naming them together.In late March, the Axios npm supply chain attack, attributed by both Google and Microsoft to the North Korean state actor UNC1069, planted a remote access trojan in versions of one of JavaScript's most-used HTTP libraries. The two malicious versions, axios@1.14.1 and axios@0.30.4, were live for just over three hours before detection, but Axios is present in roughly 80 percent of cloud and code environments and had over 100 million weekly downloads. Even that brief window was enough to cause real downstream compromise.The attack entry point was a targeted social engineering operation against Axios's lead maintainer, Jason Saayman, who later published a post-mortem describing how the attackers built a convincingly fake company identity, a cloned Slack workspace, and what appeared to be a legitimate Microsoft Teams call to extract his npm credentials. One social engineering call. One compromised maintainer account. One hundred million weekly downloads suddenly weaponized.Earlier the same month, Anthropic's Claude Code npm package shipped with a 59.8 MB source map that should never have been there, exposing 512,000 lines of unobfuscated TypeScript source code to the public. That incident also exposed internal model codenames, architectural details, and references to Mythos that confirmed capabilities Anthropic was not yet ready to announce publicly. Someone forgot to add a single line to a .npmignore file, and within hours the codebase had been forked over 41,500 times and mirrored permanently.In February, Truffle Security published a report showing that nearly <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/google-told-developers-to-paste-api-keys-in-public-for-a-decade-gemini-just">3,000 Google Cloud API keys,</a> the kind developers have been embedding in public JavaScript for years because Google itself said they were safe, had silently gained access to Gemini AI endpoints when the Generative Language API was enabled on their projects. Google initially classified this as "intended behavior." One developer found themselves facing an $82,314 bill generated in 24 hours by attackers who scraped their API key from a public webpage. Google has since implemented detection measures, but the root-cause fix, preventing existing keys from automatically inheriting new API scopes without notice, remained in progress as of the disclosure window.Each of these incidents follows the same underlying pattern: a tool that developers trusted, built their workflows around, and embedded deeply into their infrastructure quietly became a liability, and the notification came too late or not at all.<h2>The Real Lesson of 2026</h2>There is a version of the 2026 security story that focuses on AI. Mythos is finding vulnerabilities faster than humans can patch them. AI agents are being used to accelerate attacks. The CrowdStrike 2026 Global Threat Report documents an 89 percent year-over-year surge in AI-augmented attacks, with the average criminal breakout time now down to 29 minutes.All of that is real. But the Vercel breach, the Axios attack, the Google API key issue, and the Anthropic source map leak share a more fundamental lesson: the most dangerous vulnerabilities in 2026 are not the ones Mythos is finding in FreeBSD kernel code. They are the ones hiding in the assumption that the tools you trust are configured the way you think they are.<ad-spot></ad-spot>A Roblox script on one employee's machine can cascade into a potential supply chain risk for millions of developers. A missing line in an .npmignore file can expose half a million lines of proprietary source code. An API key you embedded in good faith three years ago, following the platform's own guidance, can now drain your budget or expose your users' data without a single line of code changing.The era of passive trust in developer infrastructure is over. In its place, the industry needs a posture that assumes credentials will leak, that third-party tools will be compromised, and that the attack surface is not just your own code but everything your code depends on. Rotate your secrets regularly. Audit your connected applications. Lock down your environment variables. Mark sensitive variables as sensitive, because the difference matters when someone else is inside your host's systems.Vercel's services are operational. Next.js is safe. Your project is probably fine. But "probably" is only good enough until it is not, and 2026 has made very clear that the window between "probably fine" and "rotating everything at 2 AM" is shorter than most developers want to believe.

Your Portfolio Just Got a Side Quest: The Vercel Breach and the Year 2026 Broke the Internet

In our previous piece, we broke down how <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/anthropic-built-an-ai-that-can-hack-anything-then-accidentally-told-everyon">Anthropic accidentally told the world about its most dangerous model before it was ready to</a>. Now, we go deeper into what the Mythos announcement really means for the AI industry, for cybersecurity, and for Anthropic's upcoming IPO.In the high-stakes world of artificial intelligence, the line between a technological breakthrough and a marketing masterpiece is often blurred. As of April 2026, the tech community is buzzing with Anthropic's latest revelation: Claude Mythos Preview, a model the company says is "too powerful to release to the public." According to Anthropic's own red team blog, Mythos found thousands of previously unknown vulnerabilities across every major operating system and web browser, including a 17-year-old remote code execution flaw in FreeBSD and a 27-year-old denial-of-service bug in OpenBSD, and it did so largely without any human involvement after the initial prompt.Those claims are extraordinary. But those of us who have followed this industry closely for years cannot shake a familiar feeling. We have heard the "too dangerous to release" narrative before. With Anthropic now targeting an October 2026 IPO that could value the company at anywhere between $380 billion and the $800 billion that investors are reportedly offering, the question must be asked: is Mythos a genuine threat to global security, or is it, at least in part, a perfectly timed financial instrument? At TechInKenya, our job is to look past the hype and analyze the underlying business mechanics, while being honest about what the evidence actually shows.<ad-spot></ad-spot><h2>The 2019 Playbook: GPT-2 and the Birth of Fear-Marketing</h2>To understand Anthropic's current move, we need to travel back to 2019. At the time, Dario Amodei was Vice President of Research at OpenAI, where he directly led the development of GPT-2 and GPT-3. When OpenAI announced GPT-2, a 1.5-billion-parameter language model, they chose not to release the full version, claiming it was so capable of generating convincing misinformation that releasing it publicly would be irresponsible.The media circus that followed was something to behold. Headlines announced that OpenAI had built an AI "so powerful it must be kept locked up for the good of humanity." The reality, as the world later discovered, was considerably more modest. By November 2019, OpenAI had released the full GPT-2 model. The feared wave of AI-generated propaganda never materialized. Today, models with hundreds of times more parameters run locally on mid-range laptops without a second thought. GPT-2 was not a weapon. It was a burger. And everyone bit into it.What GPT-2 did achieve was something arguably more valuable than the technology itself: it established OpenAI as the undisputed frontier of AI research, justified its transition from a nonprofit to a "capped-profit" entity to attract investment, and placed "AI safety" at the center of the public conversation in a way that benefited the lab commercially. The play worked beautifully.Now Dario Amodei is running the same playbook in 2026, but with considerably higher stakes. The threat has been upgraded from "fake news" to "breaking the internet," and the financial backdrop is far more consequential. This time, though, there is something different: the technical evidence is real.<h2>What Mythos Actually Found</h2>Let us be precise about what Anthropic has actually demonstrated, because the details matter enormously.The first headline vulnerability is in OpenBSD's TCP SACK implementation. Mythos identified a 27-year-old signed integer overflow, a logical flaw that went undetected through hundreds of code reviews, multiple major releases, and thousands of pairs of expert human eyes. Two crafted packets are sufficient to crash any OpenBSD host responding over TCP. Automated testing tools missed it entirely, because it required semantic reasoning about how TCP options interact under adversarial conditions, not just pattern-matching or brute-force fuzzing. Anthropic ran approximately 1,000 scaffold runs to find it at a total campaign cost of under $20,000.The second vulnerability is in the FreeBSD Network File System server. CVE-2026-4747 is a 17-year-old remote code execution flaw that allows an unauthenticated attacker anywhere on the internet to gain full root access to any machine running NFS. Mythos identified and exploited this completely autonomously, with no human involvement after the initial prompt. The exploit itself involved splitting a 20-gadget Return-Oriented Programming chain across six sequential NFS packets to bypass authentication and execute arbitrary code at the kernel level.<ad-spot></ad-spot>The third is a 16-year-old flaw in the FFmpeg H.264 codec, introduced in a 2003 commit and exposed by a 2010 refactor. Automated fuzzing tools had hit the vulnerable code path five million times without triggering the bug. Mythos caught it by reasoning about code semantics rather than blindly probing inputs.Beyond these showcase examples, Anthropic states it has identified thousands of high- and critical-severity vulnerabilities across every major operating system and browser. Of 198 findings reviewed by professional security contractors, 89 percent received the same severity rating the model had assigned, and 98 percent of assessments were within one severity level. Mythos also wrote a browser exploit that chained four vulnerabilities to escape both the renderer and operating system sandbox simultaneously, a class of attack that typically takes elite human researchers months to construct.The number that matters most is this: where Claude Opus 4.6, Anthropic's previous frontier model, had a near-zero autonomous exploit success rate, Mythos Preview generates a working exploit 72.4 percent of the time. That is not incremental progress. That is a category shift.<h2>The Security Paradox: Why Announce the Danger Now?</h2>If we accept those numbers, and the independent verification largely supports them, then Anthropic's "Safety-First" stance creates a paradox worth examining carefully.If the company were truly committed first and foremost to the safety of the internet, the logical course of action would have been to work silently with the Linux Foundation, the FreeBSD team, the OpenBSD developers, and the major browser vendors to patch every discovered vulnerability before ever uttering the word "Mythos" in public. This is the standard in responsible disclosure: you give developers time to fix the hole before you tell the world where it is.<ad-spot></ad-spot>Instead, Anthropic announced that Mythos has found "thousands of vulnerabilities, over 99 percent of which have not yet been patched," while simultaneously rolling out a controlled access program called Project Glasswing. The framing is careful: we know where the holes are, we are not telling you where they are, and only our 40-plus approved partners get access to the tool that can find them. If you want protection, you need to be in our ecosystem.This is not purely irresponsibility. There is a genuine defensive logic here: Anthropic argues that similar capabilities will emerge from other labs within six to eighteen months, and giving defenders a head start now is better than doing nothing. OpenAI is reportedly already preparing its own equivalent through a program it is calling Trusted Access for Cyber. The race is real.But the announcement strategy also serves another purpose. By publicly declaring that an AI can find thousands of critical vulnerabilities in the infrastructure that runs the world, and by restricting access to that AI to a curated list of enterprise partners and Project Glasswing members, Anthropic is not just protecting the world. It is positioning itself as the only entity that holds the antidote to the very poison it just discovered. This is "Fear-as-a-Service," and it is a very effective business model.<h2>The Veblen Good and the Safety Moat</h2>In economics, a Veblen good is a product that becomes more desirable precisely because it is expensive or exclusive. Designer handbags. Rare wines. The things people want because they have been told they cannot have them. By declaring Mythos "too powerful to release," Anthropic has created the ultimate Veblen good in AI. Every enterprise security team, every government agency, and every critical infrastructure operator now knows that a model exists which can find vulnerabilities in their systems in hours that their own teams missed for decades. And only Anthropic's partners get access to it.This exclusivity is not just a product strategy. It is a regulatory strategy.Every investor loves a moat: a competitive advantage that makes it structurally difficult for rivals to take your market share. In the AI industry, where the underlying hardware is largely commoditized around NVIDIA chips and the training data is largely scraped from the same public internet, a genuine technical moat is hard to build. You cannot easily patent a transformer architecture. You cannot stop a well-funded competitor from training a similarly capable model.But you can build a regulatory moat.If Anthropic can convince governments that models with Mythos-level capabilities represent an existential infrastructure risk, and that only a small number of thoroughly vetted, safety-focused labs can be trusted to handle them responsibly, they effectively erect a compliance barrier around the entire category. Smaller competitors and open-source projects cannot afford the safety-testing infrastructure, the responsible disclosure programs, or the lobbying relationships needed to satisfy that regulatory framework. The "Safety Layer" becomes a tollbooth, and Anthropic controls the booth.<ad-spot></ad-spot>This matters enormously in the context of the IPO. Bankers are currently discussing a valuation range of $400 billion to $500 billion for the October listing, while secondary market investors are reportedly offering as high as $800 billion, a figure that would make Anthropic one of the most valuable companies on earth just five years after it was founded. To justify even the lower end of that range, Anthropic needs to demonstrate that it is not just another large language model provider in a crowded market. It needs to be the essential safety infrastructure for the next era of computing. The "too powerful to release" narrative is precisely the investor hook that accomplishes this. It tells Wall Street: "We have a technology so potent that we have to control access to it." That is the kind of language that commands premium valuations.<h2>The Invoice Hidden in the Warning</h2>There is one detail from Anthropic's announcement that deserves more attention than it has received. The $20,000 compute cost to identify the OpenBSD TCP SACK vulnerability, across roughly 1,000 scaffold runs, is not merely a data point about discovery efficiency. It is an invoice.By disclosing the cost per campaign, Anthropic is speaking directly to enterprise buyers. The implicit message is: this capability is powerful enough to find vulnerabilities that survived 27 years of human review, and it is priced at a level that only serious enterprise and government customers can afford. This is not a consumer product. It is a managed security service with a very high floor price. The "danger" of Mythos is inseparable from its commercial positioning.The same logic applies to the $100 million in Project Glasswing usage credits and $4 million in donations to open-source security organizations. These are real commitments, and the defensive intent is genuine. They are also, simultaneously, the most effective possible advertising for what Mythos can do. Every vulnerability the Glasswing partners find and patch over the next several months will be a public demonstration of Mythos's capability. The $104 million is part marketing budget, part infrastructure investment, and entirely consistent with a company preparing for the largest AI IPO in history.<h2>The Counterargument That Deserves Attention</h2>In the interest of intellectual honesty, there is a counterpoint to the "Mythos is uniquely dangerous" narrative that has not received enough coverage.Researchers at AISLE, an AI cybersecurity startup, ran an independent test after Anthropic's announcement. They took the specific vulnerabilities Anthropic showcased, isolated the relevant code, and ran it through small, cheap, open-weights models. The results were striking: eight out of eight models detected the FreeBSD exploit. One of those models had only 3.6 billion active parameters and costs $0.11 per million tokens. A 5.1-billion-parameter open model recovered the core analysis chain for the 27-year-old OpenBSD bug.<ad-spot></ad-spot>AISLE's conclusion was direct: "The moat in AI cybersecurity is the system, not the model."This does not mean Mythos's capabilities are exaggerated. The 72.4 percent exploit success rate, the autonomous ROP chain construction, and the full sandbox escape in browsers represent a genuine step above what those smaller models can do end-to-end. But it does suggest that the threat landscape Anthropic is warning about is not exclusive to Mythos. If a 3.6-billion-parameter model costing fractions of a cent per token can identify the same flagship FreeBSD vulnerability, the "only Anthropic's approved partners can handle this responsibly" framing starts to look a great deal more like a business strategy than a safety necessity.This is the uncomfortable truth sitting at the center of the Glasswing announcement: the vulnerability discovery capability may already be proliferating to cheap, open-weight models far faster than any controlled access program can manage.<h2>The TechInKenya Verdict: Marketing and Miracle, Not Marketing or Miracle</h2>At TechInKenya, we believe in intellectual honesty even when it complicates a clean narrative. So let us be direct.Mythos is real. The vulnerabilities are real. The 72.4 percent exploit success rate is real. A model that can autonomously find and exploit a 17-year-old RCE in FreeBSD's NFS server, or construct a four-vulnerability browser sandbox escape without a single human intervention after the initial prompt, represents a genuine and significant capability advance. The security industry is right to take this seriously, and the Glasswing defensive coalition, for all its marketing value, is also genuinely useful. The Linux Foundation, CrowdStrike, and Palo Alto Networks are credible partners. The vulnerabilities being patched now are vulnerabilities that attackers are not exploiting tonight.But Mythos is also a financial instrument. The "too powerful to release" tag is a marketing tactic with a long and successful history in this industry, and it is working again now. The Veblen effect is in full operation. The regulatory moat is being constructed in real time. The $20,000 invoice is embedded in the warning. And an October 2026 IPO at a valuation that could reach half a trillion dollars is the ultimate destination for all of this carefully structured anxiety.Anthropic is building something genuinely important. It is also building a valuation. Those two things are not in conflict, but they are also not the same thing, and conflating them is exactly what the company is counting on you to do.The internet is not going to shut down. But Anthropic's share price is almost certainly going to go up. In the 2026 attention economy, being dangerous is the best way to become indispensable. And being indispensable is the best way to justify $500 billion.

The Myth of Mythos: Why Anthropic Is Selling You Fear Before They Sell You Shares

You open an article on Fortune or Business Daily. A paywall modal slides up. You are told to subscribe for access to the full story. But if you open your browser's developer tools and look at the Network tab, the full article is already sitting in the response (every paragraph, every sentence ) delivered to your browser before the subscription prompt even appeared.The paywall is not protecting the content. It is hiding it. Those are not the same thing.This is not a new discovery and it is not a niche technical quirk. It is a deliberate architectural choice made by some of the largest media companies in the world and understanding why they made it reveals something genuinely interesting about the tension between subscription revenue, search engine visibility, and the fundamental principle of web security that every developer learns early: never trust the client.<ad-spot></ad-spot><h2>Two Fundamentally Different Architectures</h2>There are two ways to build a paywall. They produce similar-looking results for the end user but are architecturally opposite in how they handle the content.<h3>Client-Side Paywalls</h3>When you visit a paywalled article on a site using a client-side paywall, the server sends you everything. The full article HTML arrives in your browser. JavaScript then runs, checks whether you have an active subscription, and if not, renders an overlay ( a modal, a blur, a truncation ) that obscures the content from view.The content is already in the browser. The paywall is presentation logic, not access control. It is a curtain drawn over something that is already in the room.The practical consequence: anything that interrupts that JavaScript execution reveals the content. Disabling JavaScript entirely. Using a browser's built-in reader mode. Using a read-it-later extension that strips page chrome and renders only the article text. Intercepting the network response before JavaScript processes it. None of these require technical expertise. They are features built into mainstream browsers.<ad-spot></ad-spot>Firefox's reader mode ( accessible via the book icon in the address bar or pressing F9 ) is the simplest example. It parses the article content directly from the HTML and presents it in a clean, ad-free, popup-free reading view. On a client-side paywall, this works because the content was already delivered to the browser. Reader mode simply presents what is there without executing the JavaScript that was supposed to hide it.<h3>Server-Side Paywalls</h3>Bloomberg is the clearest example of the opposite approach. When you hit a Bloomberg article without a subscription, the server does not send you the full article. It sends you the headline, the first paragraph, and a subscription prompt and that is all that exists in the HTTP response. There is nothing else in the page source to find.No reader mode. No JavaScript manipulation. No network interception. No amount of browser tooling reveals the rest of the article because the rest of the article was never sent. The access control decision was made on the server, before a single byte of article content was transmitted.The difference in developer terms is simple:Client-side: The server sends content → the browser decides who sees itServer-side: The server decides who gets content → then sends itThe second model correctly treats authentication and authorisation as a backend concern. The first model treats it as a frontend concern, which any developer who has built a web application knows is the wrong layer for access control.<h2>So Why Would Fortune Do This?</h2>Fortune is not a company of naive engineers. Its digital infrastructure is backed by significant investment and experienced teams. The choice to implement a client-side paywall is not an oversight. It is a calculated trade-off, and the primary currency in that trade-off is SEO.Here is the problem Bloomberg faces with its server-side paywall: Google cannot read the article either. When Googlebot crawls a Bloomberg page, it sees the same truncated content a non-subscriber sees, the headline and the first paragraph. Google cannot index the full text of the article. The article cannot rank on long-tail search queries for its specific content. Bloomberg accepts lower search visibility in exchange for a genuinely enforced paywall.Fortune, and publications like it, make the opposite trade. By delivering the full article to every browser ( including Googlebot ) the full text is indexed by Google. The article ranks for every keyword in the body of the piece, not just the headline. Readers who find it via search land on the full content, hit the paywall overlay, and are invited to subscribe. The content does the SEO work before the paywall does the conversion work.<ad-spot></ad-spot>Client-side metered paywalls allow the full HTML content to be indexed by search engines before any JavaScript-based restrictions are applied. This approach is preferred for SEO as it ensures that search engines can fully crawl and index the content, which is vital for maintaining search rankings.This is a known and accepted SEO strategy, not a secret. Google has explicit guidance for publishers doing this, they are required to use structured data to declare that the content is paywalled, specifically the <code>isAccessibleForFree: false</code> attribute in NewsArticle schema markup. This prevents the practice from being classified as cloaking ( showing different content to search bots than to users ) which would be a Google Search penalty.Whether every publication implementing client-side paywalls correctly implements this structured data disclosure is a separate question.<h2>The SEO vs Revenue Trade-Off in Plain Terms</h2>The choice between client-side and server-side paywalls is ultimately a question of which you value more: content protection or content discovery.Server-side paywall (Bloomberg model):<ul><li>Content is genuinely protected, no bypass possible</li><li>Search engines cannot index full content</li><li>Relies on brand authority and direct traffic for subscriber acquisition</li><li>Works for publications with strong established brands where readers seek them out directly</li></ul>Client-side paywall (Fortune model):<ul><li>Content is technically accessible via reader mode and JS manipulation</li><li>Search engines index full content, driving organic discovery</li><li>Works for publications that depend on search traffic to feed the subscription funnel</li><li>Acceptable leakage rate (the proportion of technically capable readers who bypass the paywall) is judged to be smaller than the SEO benefit</li></ul>The Business Daily Kenya context is instructive here. A publication in a market where search discovery is critical for audience growth (and where a Bloomberg-style brand authority that drives direct traffic does not yet exist ) has strong incentive to prioritise search indexing over airtight content protection. The readers most likely to bypass the paywall are the least likely to convert to subscribers anyway. The readers who find the article through Google search and see a subscription prompt are exactly the conversion target.<h2>Reader Mode and the UX Problem It Solves</h2>Beyond the paywall question, browser reader modes are solving a separate and legitimate problem: modern news websites have become hostile environments for reading.<ad-spot></ad-spot>Autoplay videos that play on mute. Newsletter signup modals that appear mid-scroll. Cookie consent banners that obscure half the page. Sticky headers that eat 15% of the viewport. Related article carousels that interrupt the reading flow. Push notification requests. Live chat widgets. None of these serve the reader's primary intent, which is to read the article.Reader mode strips all of this away. The result is a page with the article text, the images relevant to the story, and nothing else. Loading times drop dramatically. Battery consumption falls. Mobile data usage decreases.The irony is that reader mode produces a better reading experience than most publishers' own article pages. The sites that invest most heavily in ad units, promotional widgets, and engagement popups (the ones most motivated to drive subscription revenue ) have often built reading environments that actively discourage reading.Firefox's built-in reader mode preserves the article images but strips the surrounding page furniture. Extensions like Ream go further, rendering images inline with the article text in a fully typeset layout. For long-form articles on a phone commute, the difference in experience is significant.<h2>What This Means if You Are Building a Paywall</h2>If you are a developer building subscription access control into a web application ( whether that is a media publication, a software tool, or any content platform ) the architectural lesson is straightforward.Access control belongs on the server. The browser is not a trust boundary. JavaScript can be disabled, intercepted, modified, or simply not executed. Any access control decision that runs exclusively in the browser is a presentation decision, not a security decision. The distinction matters: presentation logic controls what users see, security logic controls what data they receive.The correct pattern for any content that genuinely needs to be restricted:1. The client requests the content2. The server checks authentication and authorisation3. If the user is not entitled to the content, the server returns the teaser or a 401/403 response, not the full content4. If the user is entitled, the server returns the full contentThis is not complicated. It is the same pattern used for every other authenticated resource on the web, private API endpoints, protected file downloads, user account data. The reason paywalls often deviate from it is the SEO trade-off described above, not a technical limitation.If you are building a paywall and you want both SEO indexing and content protection, the technically correct approach is to implement server-side access control for human users while explicitly allowing known Googlebot user-agents to receive full content, a practice Google permits and documents, provided you implement the correct structured data declarations. This is more complex to build than either pure approach but eliminates the trade-off.<h2>The Broader Principle: Never Trust the Client</h2>The paywall case is a highly visible instance of a principle that applies across every layer of web development.Frontend validation of form inputs is not a substitute for backend validation ( a user can submit any data directly to your API endpoint regardless of what your form allows. Client-side role checks in a React app are not access control) anyone can modify the component state or call the API directly. A disabled button is not a security boundary. CSS that hides content is not content protection.<ad-spot></ad-spot>These are not obscure security concepts. They are in every web development curriculum, every security awareness training, and every code review checklist. The reason client-side paywalls exist despite this is not ignorance, it is a deliberate product decision where search visibility was judged more valuable than content protection.That judgement may be correct for the publications that made it. But it is a product decision, not a technical best practice. Knowing the difference, and knowing why a Fortune-sized company makes that choice, is what separates engineers who implement features from engineers who understand systems.Are you building a paywall or subscription access control for a web application? Drop your architecture questions in the comments, we are happy to dig into the implementation details.

Client-Side vs Server-Side Paywalls: Why Some of the World's Biggest Media Companies Are Trusting the Browser With Their Revenue

For over ten years, Google's own documentation told developers that API keys starting with <code>AIza</code> were safe to include in public-facing code. Firebase's official security checklist said it explicitly: "API keys are not secrets." Google Maps guides instructed developers to paste their keys directly into HTML. Millions of websites followed that guidance and embedded those keys in JavaScript that anyone could read by right-clicking "View Page Source."Then Google launched Gemini. And without telling anyone, every one of those public keys quietly became a backdoor into private AI endpoints.<a target="_blank" rel="noopener noreferrer nofollow" href="https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules">Security researchers at Truffle Security</a> published their findings on February 26, revealing that nearly 3,000 live Google API keys (deployed publicly following Google's own instructions) now authenticate to Gemini's most sensitive endpoints. An attacker needs no special skills or infrastructure to exploit this. They visit your website, copy the key from your page source, and start running up your bill.One Reddit user woke up to find $82,314.44 in charges on their Google Cloud account after a key was stolen and abused between February 11 and 12. Their usual monthly spend was $180.<h2>What Actually Happened</h2>The problem is architectural, and understanding it matters for anyone who has ever built anything on Google Cloud.Google API keys ( formatted as <code>AIza...</code> strings ) are project-scoped, not service-scoped. When you create a key for Google Maps, that key belongs to your Google Cloud project. It does not inherently have access to any specific service, it just belongs to the project. For years, this was fine. Google Maps keys were billing identifiers. If someone scraped your key from your website, the worst they could do was use your Maps quota, which was largely free anyway.<ad-spot></ad-spot>Then the Gemini API arrived. When the Gemini API (formally called the Generative Language API) is enabled on a Google Cloud project, every existing API key in that project silently inherits access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.This means a developer who embedded a Maps key in their website in 2021, following Google's documented instructions, may have unknowingly created a live Gemini credential the moment a teammate enabled the Generative Language API for a prototype last year. The key never changed. The code never changed. But the permissions attached to that key changed completely and nobody was told.The attack itself is trivial. An attacker visits your website, views the page source, copies your <code>AIza...</code> key, and runs a basic API call to <code>https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY</code>. Instead of a 403 Forbidden, they get a 200 OK.From there they can access private uploaded files and cached Gemini content, exhaust your API quotas shutting down your legitimate services, and run up AI usage bills worth thousands of dollars per day against your billing account.<h2>The Scale of the Exposure</h2>Truffle Security did not find these keys by hacking anything. They scanned the November 2025 Common Crawl dataset (a roughly 700 terabyte archive of publicly scraped web content) and identified 2,863 live Google API keys vulnerable to this vector.Common Crawl is a publicly available dataset that anyone can download. Security researchers use it. So do the threat actors hunting for exposed credentials at scale.The 2,863 keys were not all small side projects. Truffle's scan turned up keys belonging to major financial institutions, security companies, global recruiting firms, and — in a detail that borders on parody — Google itself.For Kenyan developers and organisations, the exposure surface is real. Any project that uses Google Maps, Firebase Authentication, Cloud SQL, or any other Google service that historically treated <code>AIza</code> keys as public identifiers, and that has since added Gemini to the same Google Cloud project, is potentially affected. Firebase authentication in particular is extremely common in Kenyan-built apps, it is the default auth provider for many startups precisely because Google marketed it as safe and simple.<ad-spot></ad-spot><h2>Google's Response And Its Limits</h2>Truffle Security disclosed the vulnerability to Google on November 21, 2025. Google initially classified the behaviour as "Intended Behavior", meaning they considered it working as designed, not a bug. After researchers provided concrete evidence from Google's own infrastructure, the security team took it more seriously.On January 13, 2026, Google classified it as "Single-Service Privilege Escalation, READ", a Tier 1 vulnerability. By February 2, 2026, Google confirmed the team was still working on the root-cause fix. The 90-day disclosure window closed on February 19, 2026, with the root-cause fix still in progress.When Truffle published their findings publicly on February 26, Google issued a statement acknowledging the report and confirming they had implemented measures to detect and block leaked API keys attempting to access the Gemini API. Google has also committed to three forward-looking changes: new AI Studio keys will default to Gemini-only scope, leaked keys will be proactively blocked from Gemini access, and notifications will go out when leaks are detected.What remains unconfirmed is whether Google has individually notified all 2,863 identified affected project owners. Given that many of those developers may not follow security news closely (they built a Maps embed years ago and moved on) direct notification is arguably the most important step. Google has not confirmed it has happened.The root-cause fix, preventing Gemini API activation from silently upgrading existing project keys, is still not complete as of publication.<h2>How to Check If You Are Affected</h2>This is the section that matters most if you have built anything on Google Cloud or Firebase.Step 1: Check if Gemini is enabled on your projectGo to the Google Cloud Console at <a target="_blank" rel="noopener noreferrer nofollow" href="https://console.cloud.google.com">console.cloud.google.com</a>. Select your project from the top navigation. Go to APIs &amp; Services → Enabled APIs &amp; Services. Look for "Generative Language API" in the list. If it is there and you did not intentionally enable it, or you enabled it for a brief test and forgot about it, you are potentially affected.Step 2: Audit your API keysGo to APIs &amp; Services → Credentials. Every key listed there that exists in the project has potentially inherited Gemini access if the Generative Language API is enabled. Look at each key and check its restrictions.<ad-spot></ad-spot>Step 3: Apply restrictions immediatelyClick on each key. Under "API restrictions," switch from "Don't restrict key" to "Restrict key." Select only the APIs that key actually needs to function — Google Maps JavaScript API for a Maps key, Firebase-related APIs for a Firebase key. Do not include the Generative Language API unless that specific key is genuinely intended for Gemini access.<img src="https://cdn.calebms.com/articles/874fadba-7cd5-404a-a12a-0c2ab5ae71c7.jpg" alt="51965.jpg">If you have a key that is dedicated to Gemini usage, keep it separate, restricted to the Generative Language API only, and never embed it in client-side code. Gemini API keys should only ever exist in server-side environments where they cannot be read from page source.Step 4: Rotate any key that may have been publicly exposedIf a key has ever appeared in a public GitHub repository, in client-side JavaScript on a public website, or in any code that was accessible without authentication, rotate it. Generating a new key in the console invalidates the old one. Then audit your codebase to replace the old key everywhere it appears before the new one goes live.Step 5: Scan your codebaseTools like TruffleHog can scan codebases and CI/CD pipelines to identify live Google API keys with Gemini access, not just pattern-match for the key format, but verify whether those keys are actually live and exploitable. Run it across your repositories before assuming you are clean.<h2>The Broader Lesson This Should Teach</h2>The specific vulnerability will be patched. Google will finish the root-cause fix, new keys will default to scoped access, and the 2,863 exposed keys have already had their Gemini access revoked by Google. For those specific keys, the immediate risk is addressed.But the pattern this exposes is not going away. A credential that was safe by design in 2022 may be a serious liability in 2026, not because anyone made a mistake, but because the rules quietly changed.This is what happens when AI capabilities are bolted onto existing platforms at speed. The Gemini API inherited a key management architecture built for a billing-identifier model. Nobody sat down and asked: "If we enable this new service on all existing projects, what permissions do existing keys inherit?" Or if someone did ask, the answer did not make it into the release process. The result is that following Google's explicitly documented, decade-old guidance created a security vulnerability that developers had no way to anticipate.For Kenyan developers building on Google Cloud and Firebase (which is a significant portion of the startup ecosystem here) the actionable response is not to stop using Google services. It is to treat credential hygiene as a first-class concern rather than something you address when something goes wrong. The $82,314 overnight bill and the student's $55,444 charge are not edge cases. They are previews of what happens when API key discipline is treated as optional.Restrict your keys to what they actually need. Keep Gemini credentials server-side only. Audit your projects quarterly. And the next time a platform you build on launches a major new service, check what permissions your existing credentials just quietly inherited.

Google Told Developers to Paste API Keys in Public for a Decade. Gemini Just Made That Catastrophic.

Between December 2025 and January 2026, <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.bloomberg.com/news/articles/2026-02-25/hacker-used-anthropic-s-claude-to-steal-sensitive-mexican-data">a single unknown person used a consumer AI chatbot to systematically dismantle the cybersecurity defences of the government of Mexico</a>. By the time anyone noticed, 150 gigabytes of data was gone — tax records tied to 195 million taxpayers, voter files, government credentials, and civil registry documents spanning Mexico's federal tax authority, its electoral institute, four state governments, and a water utility.The tool was not a sophisticated nation-state hacking suite. It was a consumer AI chatbot. The attacker's conversation logs were found publicly accessible online when the breach came to light on February 25.The method was not technically novel. What made it effective was patience and AI-assisted persuasion, the ability to craft perfectly targeted social engineering at scale, probe defences continuously without fatigue, and adapt to each new barrier without human oversight slowing the attack down.Kenya has built something similar to what Mexico lost except larger and more centralised. Over 13 million Kenyans are registered on eCitizen. More than 16,000 government services sit on a single platform. The Maisha Namba digital ID is issuing up to 30,000 new IDs every day. The question of whether Kenya's cyber defences are ready for AI-assisted attacks is not hypothetical. It is urgent.<h2>The Ksh 29.9 Billion We Already Know About</h2>Before discussing where cyber threats are heading, the current baseline deserves to be stated clearly.Kenya lost Ksh 29.9 billion to cybercrime in 2024/2025. That figure comes from the <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.serianu.com/downloads/Africa%20Cybersecurity%20Report%20-%20Kenya.pdf">Africa Cybersecurity Report Kenya 2024/2025,</a> produced by Serianu, one of the continent's most credible cybersecurity research institutions, based on responses from 280 organisations. Continent-wide, Africa lost Ksh 650 billion, roughly $5 billion, in the same period.<ad-spot></ad-spot>Payment fraud was the most common incident category, driven by real-time mobile money transfers, weak transaction monitoring systems, and social engineering attacks that exploit the trust that makes M-Pesa so frictionless in legitimate use. Online and email fraud accounted for 40% of all incidents and 32% of recorded losses, pointing to persistent gaps in how organisations manage digital identity verification. SIM-swap attacks and mobile money fraud remain widespread despite what Serianu describes as "improved controls", a diplomatic way of saying the controls are not keeping up with the attackers.A specific case from 2025 illustrates the gap between controls and outcomes: attackers compromised a digital payments portal, disabled OTP notifications, and funnelled Ksh 49 million into mobile wallets, bank accounts, and till numbers before the breach was detected. In a separate incident, a syndicate stole over Ksh 6 million from a commercial bank. Both were carried out with relatively conventional methods. Neither required AI.The Ksh 29.9 billion figure is sobering on its own. What Serianu's CEO William Makatiani said at the report's launch is more sobering still: "The rate at which organisations are investing is improving, but attackers are advancing even faster."That gap, between the pace of investment in defence and the pace of offensive capability, is where AI enters the picture.<h2>What AI Has Already Changed for Attackers</h2><a target="_blank" rel="noopener noreferrer nofollow" href="https://www.bcg.com/publications/2025/ai-raising-stakes-in-cybersecurity">A global survey of 500 senior leaders</a> by Boston Consulting Group, published in December 2025, quantified the defensive side of this gap. Only 7% of organisations globally have deployed AI tools in their cyber defence. Meanwhile, approximately 60% have likely already experienced an AI-powered attack in the past year. The defensive majority is fighting with 2019-era tools against attackers who have fully adopted 2026 capabilities.<ad-spot></ad-spot>The BCG report identifies three structural shifts that make AI-enabled attacks categorically different from what came before.The first is scale and speed. AI enables attackers to hunt for vulnerabilities across thousands of systems simultaneously, generate personalised phishing content at industrial volume, and probe defences continuously without the fatigue or cost constraints that limit human attackers. A campaign that previously required a team of analysts working over weeks can now be initiated and iterated by one person with a laptop and an API key.The second is autonomous operation. AI has moved from static models to agentic systems, AI that can observe, reason, and act across multiple steps without human oversight. The Mexico breach demonstrated this: the attacker used AI to sustain a patient, multi-stage intrusion across months, adapting to each defensive response without escalating resources or personnel. Autonomous attacks can probe continuously, adapt instantly to defensive signals, and maintain operational tempo that human defenders cannot match in real time.The third is identity collapse. Deepfakes, voice cloning, and synthetic identity generation have undermined authentication as a reliable safeguard. The BCG survey found that AI-generated deepfake video has already been used to impersonate a CFO in a live video call, resulting in a $25 million fraud loss at a multinational engineering firm. Voice cloning was used to spoof election-related robocalls, resulting in a $1 million regulatory fine for a telecom provider. When you cannot trust that the voice or face on your screen belongs to the person it claims to be, the entire model of identity-based verification collapses.Kenya's digital economy is built on identity verification. M-Pesa PIN entry. OTP confirmation. Biometric matching at eCitizen kiosks. SIM registration against national ID. Every one of these controls was designed for a threat environment where forgery was expensive and required physical proximity. AI has made sophisticated forgery cheap, scalable, and remote.<h2>Why Kenya Is a High-Value Target</h2>Kenya's appeal to cybercriminals is a function of the same qualities that make its digital economy a regional success story.M-Pesa processes hundreds of billions of shillings in transactions every month, with the frictionless speed that makes mobile money genuinely useful also creating opportunities for real-time fraud before monitoring systems flag anomalies. The eCitizen platform centralises access to government services at a scale that, if compromised, would expose millions of citizen records in a single breach. Kenya's position as East Africa's technology hub means it hosts the regional offices, data centres, and payment processing infrastructure of companies operating across multiple countries, making it a gateway target whose breach has continental consequences.<ad-spot></ad-spot>The Serianu report notes that Kenya's digital infrastructure remains significantly exposed at the network layer. Many devices remain accessible through open, unencrypted remote-access services (Telnet, FTP, RDP) that should have been secured or decommissioned years ago. Operational errors and system misconfigurations compound the attack surface, particularly in public sector institutions where IT staffing and budget constraints are most acute.Kenya also has the third-highest number of internet users in sub-Saharan Africa and among the highest mobile money penetration rates globally. From an attacker's perspective, this is not a liability, it is an opportunity. More users, more transactions, more endpoints, more attack surface, and a regulatory and enforcement environment that is still building the capacity to respond at the speed and sophistication that AI-enabled attacks require.<h2>The eCitizen Problem Nobody Is Talking About Loudly Enough</h2>The Mexico breach warrants specific attention in the Kenyan context because the structural parallels are uncomfortable.Mexico's breach exploited centralised government infrastructure, a single point of failure whose compromise gave the attacker access to data spanning multiple agencies. eCitizen is Kenya's equivalent architecture. The platform's value proposition is precisely its centralisation: one login, one identity, access to thousands of services. That centralisation is also its vulnerability. A successful attack against eCitizen's authentication layer, or against the identity verification systems that underpin Maisha Namba, would not be a single agency breach. It would be a systemic one.Kenya's government moved faster on digital transformation than on the security architecture to protect it. The Maisha Namba rollout, the eCitizen expansion, the integration of biometric data across health, education, and financial services, these are genuinely impressive infrastructure achievements. But each integration point is also a potential attack surface, and the BCG survey's finding that 88% of organisations plan to deploy AI defence but only 7% have done so yet describes a gap that attackers are exploiting right now.The government is aware of this. Secretary to the Cabinet Mercy Wanjau, speaking at the Serianu report launch, announced the establishment of a Government Security Operations Centre, a centralised national cyber-monitoring facility. That is the right structural response. The implementation timeline, resourcing, and integration with existing agency security teams will determine whether it arrives before the next major incident or after it.<h2>What Organisations and Individuals Can Do Now</h2>For businesses and institutions operating in Kenya, the BCG and Serianu findings point to concrete priorities rather than abstract awareness.Identity governance is the most urgent gap. Both reports identify identity management, how you verify who is accessing what, as the primary attack surface for AI-enabled threats. Multi-factor authentication that relies solely on SMS OTPs is no longer sufficient, as SIM-swap attacks can intercept those codes. Authenticator apps, hardware security keys, and biometric verification tied to the actual device rather than a phone number are more resilient options. For organisations processing significant financial transactions, these are not optional upgrades.<ad-spot></ad-spot>Recovery readiness matters as much as prevention. The shift Serianu recommends (from risk management to resilience) reflects a hard-won insight from organisations that have been breached: prevention will sometimes fail. Immutable backups, routine recovery testing, and documented incident response procedures determine whether a breach becomes a recoverable disruption or a catastrophic loss. The organisations that recovered fastest from the attacks documented in the Serianu report were those with functioning recovery systems, not necessarily those with the most sophisticated perimeter defences.AI-assisted monitoring is now table-stakes for financial institutions. Real-time transaction monitoring that flags anomalies (unusual patterns, atypical access times, out-of-pattern transfer destinations) needs to operate at the speed of AI-enabled attacks, which means it needs AI assistance. Human analysts reviewing logs after the fact cannot catch attacks that complete in minutes. This is not a future consideration for Kenya's banks, fintechs, and mobile money operators. It is a current gap that Serianu's documented incidents have already exploited.Consumer awareness remains the cheapest layer of defence. Enabling two-step verification on all financial accounts. Confirming transfer requests through a separate channel before executing them. Being sceptical of urgent requests from known contacts (particularly voice or video calls requesting money or credentials) since both can now be convincingly faked. These behaviours cost nothing and intercept the social engineering attacks that remain the most common entry point for Kenya's most costly breaches.<h2>The Asymmetry That Needs to Close</h2>Kenya is in a position that is not unique but is particularly acute. It has built digital infrastructure fast enough to create real economic value (M-Pesa's role in financial inclusion, eCitizen's role in service delivery, Maisha Namba's potential to anchor a unified digital identity) but the security architecture protecting that infrastructure has not kept pace with either the sophistication of the threats or the centralisation of the target.The Ksh 29.9 billion in losses documented by Serianu is a 2024/2025 figure. It reflects attacks carried out with largely conventional tools. AI-enabled attacks are already underway globally, the BCG survey's 60% figure represents organisations that have already experienced them, and Kenya's attack surface is large, high-value, and in several areas still inadequately protected.The Mexico breach should be read as a preview, not a warning about somewhere else. The same consumer AI tools are available to the same global threat actors targeting Kenya. The centralised digital infrastructure that makes Kenya's government services efficient makes it a similarly attractive target. The response gap, between organisations that understand the risk and those actively deploying AI-native defences, is the window that attackers are operating in right now.Closing that window is not primarily a technology problem. It is a resource, urgency, and prioritisation problem. The technology to defend against AI-enabled attacks exists. The organisations and institutions that deploy it at speed and scale will be the ones that are not in next year's Serianu report.

Kenya Lost Ksh 29.9 Billion to Cybercrime Last Year. AI Is About to Make That Number Much Worse.

A new type of Android malware is making headlines this week, and it is unlike anything security researchers have seen before. Discovered by cybersecurity firm ESET, a malware strain called PromptSpy is the first ever Android malware to use generative AI — specifically Google's own Gemini — to take over your phone. It can record your screen, steal your lock screen PIN, block you from uninstalling it, and hand a remote attacker full control of your device.While PromptSpy appears to have primarily targeted users in Argentina and may still be in its early stages, the discovery is a clear signal: Android threats are getting smarter. For the millions of Kenyan smartphone users who rely on their phones for mobile banking, M-Pesa transactions, business communication, and everyday life, this is the right moment to take Android security seriously.This guide walks you through practical, straightforward steps to protect your Android phone in 2026.<h2>What Makes PromptSpy Different — And Why It Matters</h2>Before getting into the how-to steps, it helps to understand why security researchers are paying attention to this threat.Most Android malware works by hardcoding specific screen coordinates or button locations. The problem is that these coordinates break easily across different phone models, screen sizes, and Android versions. Attackers have had to build separate versions of malware for different devices — an expensive and time-consuming process.PromptSpy changes that. It sends Google's Gemini a description of whatever is currently on the phone's screen, and Gemini responds with instructions on exactly what the malware should tap or swipe. This means the malware can adapt to virtually any Android device, any screen layout, and any Android version automatically. It is a significant upgrade in how flexible and dangerous mobile malware can be.Beyond the AI angle, PromptSpy can capture your lock screen PIN, record your screen as a video, take screenshots, block you from uninstalling it using invisible overlays over buttons, and give attackers full remote access to your phone through a VNC module. Importantly, it is distributed through a fake banking app website and has never appeared on the Google Play Store.The good news is that Google Play Protect already blocks known versions of it. The better news is that the steps that protect you from PromptSpy are the same steps that protect you from the vast majority of Android threats in general.<ad-spot></ad-spot><h2>Step 1: Only Install Apps From the Google Play Store</h2>This one step alone would stop most Android malware, including PromptSpy.PromptSpy was never on the Play Store. It was distributed through a dedicated website disguised as a banking app. Users who only install apps through the Play Store would never have encountered it in the first place.In Kenya, it is common to download APK files from WhatsApp groups, Telegram channels, or random websites — especially for apps that are not available locally, paid apps people want for free, or modified versions of popular apps. This habit carries significant risk. APK files downloaded outside the Play Store have not been reviewed by Google's security systems.To check your settings, go to Settings, then Security, and look for an option called "Install Unknown Apps" or "Unknown Sources." Make sure this is turned off for all apps. On Android 8 and above, you can control this permission on a per-app basis.<h2>Step 2: Keep Google Play Protect Turned On</h2>Google Play Protect is a built-in security feature that scans apps on your phone for malware. It is free, runs automatically in the background, and is one of your best defences against threats like PromptSpy.ESET confirmed that Play Protect already protects against known versions of PromptSpy. This only works, however, if Play Protect is actually enabled on your device.To check, open the Play Store app, tap your profile picture in the top right corner, tap "Play Protect," and make sure it shows as active. You can also run a manual scan from this screen. If Play Protect is turned off, turn it back on immediately.<h2>Step 3: Be Very Careful With Accessibility Permissions</h2>This is one of the most important — and most overlooked — security steps on Android.Accessibility Services are features designed to help people with disabilities use their phones. They allow apps to read what is on the screen, simulate taps and swipes, and interact with other apps. These are powerful capabilities, and malware loves them.PromptSpy abuses Accessibility Services to place invisible overlays over the "Uninstall" button and other system controls, making it impossible for users to remove it through normal means. Many other Android malware families do the same thing.You should only grant Accessibility permissions to apps you fully trust and genuinely need them for — such as a screen reader or a password manager like Bitwarden. If a random app you downloaded asks for Accessibility access, that is a major red flag.To review which apps have Accessibility access on your phone, go to Settings, then Accessibility, then Installed Apps or Downloaded Apps depending on your phone model. If you see any apps there that should not need those permissions, revoke them immediately.<ad-spot></ad-spot><h2>Step 4: Use a Strong Screen Lock</h2>PromptSpy is specifically designed to capture your lock screen PIN and record your unlock pattern as a video. This makes your screen lock your first line of defence.A six-digit PIN is much stronger than a four-digit one. A strong alphanumeric password is stronger still. Pattern unlocks are the weakest option — they are easy to record and easy to guess from smudge marks on the screen.Fingerprint authentication is a good complement to a strong PIN because it reduces how often you type your PIN in public. Set it up if your phone supports it, but make sure you still have a strong PIN as a backup since biometrics can be bypassed in some circumstances.To set or change your screen lock, go to Settings, then Security, then Screen Lock.<h2>Step 5: Keep Your Phone and Apps Updated</h2>Malware frequently exploits security vulnerabilities in outdated versions of Android or popular apps. Keeping your phone updated closes these holes before attackers can use them against you.Go to Settings, then System, then Software Update, and check for any pending updates. Do the same for your apps by opening the Play Store, tapping your profile picture, and selecting "Manage Apps and Device" to see if any updates are waiting.Updates are especially important for your browser, banking apps, and any app that handles sensitive data.<h2>Step 6: Watch Out for Fake Banking Apps</h2>PromptSpy disguised itself as a fake Chase Bank app. In Kenya, similar attacks often impersonate M-Pesa, Equity Bank, KCB, or other locally trusted financial platforms.The signs to watch for include being directed to a website or WhatsApp group to download a banking app rather than finding it on the Play Store, apps that ask for more permissions than necessary (a banking app does not need Accessibility access or the ability to record your screen), slight variations in app names or icons that look almost right but not quite, and messages from strangers or suspicious accounts urging you to install a financial app urgently.When in doubt, go directly to the official Google Play Store, search for your bank by name, and install only the app listed there with the most downloads and reviews.<h2>Step 7: Use Two-Factor Authentication on Your Important Accounts</h2>Even if malware does manage to steal your password, two-factor authentication (2FA) adds a second layer of defence. An attacker would need both your password and access to your phone or email to log into your account.Enable 2FA on your Google account, your banking apps, your email, and any other account that supports it. Google Authenticator and Microsoft Authenticator are both solid options for generating one-time codes. Some services will also send a code via SMS, which is better than nothing even though SMS-based 2FA is weaker than app-based options.To enable 2FA on your Google account, go to myaccount.google.com, click Security, and look for "2-Step Verification."<ad-spot></ad-spot><h2>Step 8: What to Do If You Think Your Phone Is Already Infected</h2>If your phone is behaving strangely — the battery drains unusually fast, the phone is hot when idle, data usage has spiked, or you cannot remove an app — there is a possibility malware is running on it.For PromptSpy specifically, the only way to remove it through normal means is to reboot your phone into Safe Mode. In Safe Mode, third-party apps are disabled, which means the invisible overlays blocking the Uninstall button will no longer work. You can then go to Settings, then Apps, find the suspicious app, and uninstall it normally.To boot into Safe Mode on most Android phones, press and hold the power button, then long-press the "Power Off" option until a "Safe Mode" prompt appears. Tap OK. The process varies slightly between manufacturers, so search for "how to boot into safe mode" followed by your specific phone model if the above does not work.After removing the suspicious app, run a Google Play Protect scan, change all your important passwords, and check your bank accounts for any unusual activity.If you are not comfortable doing this yourself, take your phone to a trusted phone repair shop or contact your mobile carrier for support.<h2>The Bigger Picture</h2>PromptSpy is being described by researchers as potentially a proof of concept rather than a full-scale attack campaign. But the direction it points in is clear. Attackers are beginning to use AI to make malware more adaptable, more persistent, and harder to detect. This is not a trend that will reverse.For Kenyan smartphone users, the stakes are high. Our phones are our banks, our businesses, and our connections to family and work. Taking a few minutes to check the settings outlined in this guide is a worthwhile investment.The steps are not complicated. Stick to the Play Store. Keep Play Protect on. Be stingy with Accessibility permissions. Use a strong screen lock. Update your phone regularly. Those five habits alone will protect you from the overwhelming majority of Android threats in 2026.

Cybersecurity