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

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

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

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

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

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

How to Secure Your Android Phone in 2026: A Complete Guide for Kenyan Smartphone Users

The "Guaranteed Win" Illusion: Inside Kenya's Betting & Forex Prediction Scams