Shipping fast is fine. Shipping your keys is not.

Someone downloaded 1.8 million Android apps, took each one apart back into readable code, and scanned every one for hardcoded secrets — the API keys and access tokens developers leave sitting inside.

Not yours specifically. Nobody was looking for you.

In Malaysia that now carries a deadline. A personal data breach here has had a reporting duty since 1 June 2025, and since April 2025 a failure to protect personal data has carried a penalty of up to RM1,000,000.

The sweep was one operation, disclosed in Anthropic's threat intelligence report published on 10 September 2026, covering activity it disrupted between December 2025 and August 2026 across seven harm areas. Ten cloud servers. Verified findings routed live into a Telegram group sorted into over 100 source types, with a second stream collecting stolen code-repository tokens. A separate actor simply downloads every app on the Google Play Store and searches it for exposed session tokens.

Why an old mistake suddenly costs you

Hardcoding an API key into an application is ordinary. It's the shortest path from "this works on my laptop" to "this works", and it's something engineers recognise doing under deadline.

Obscurity used to make it survivable. For your key to matter, a person had to choose your app, download it, pull it apart, and look. Choosing costs something, and nobody was spending it on a mid-sized distributor in Petaling Jaya or a Johor manufacturer's stock-check app.

At 1.8 million applications scanned by machine, nobody is choosing.

That last sentence is our inference, not Anthropic's. The report describes attackers. It says nothing about how any victim's software was written, and at least one widely-shared industry synthesis has blurred the two, restating a vendor's Claude-Code-specific finding as a generic "AI-assisted versus human" gap.

Where the keys are actually being found

Anthropic says access tokens are being found "at industrial scale" — and not in one place:

• the app you shipped
• your code repository
• the code running in your customer's browser
• your server images
• the internal address a cloud server uses to hand out its own credentials
• and one worth pausing on if you're deploying AI internally: "victim-deployed AI agents"

Whatever turns up gets qualified before it is used or resold: keys tested in bulk against the cloud provider, the live credential fired to confirm it works, then whatever survives graded for what it will fetch on resale. There is quality control in this.

Then one working credential becomes many. In the cases Anthropic disclosed, a single key led to cluster-wide secret dumps, injection into build pipelines, database dumps, and "vendor-OAuth fan-out to every downstream tenant" — the access spreading through integrations with other companies. Where that fan-out happens, the key travels out through the integration. Picture a freight forwarder in Port Klang wired into a client's warehouse system: the token that moves your client's shipment data sits in your app, but the tenant it opens is theirs. If you are connecting AI to the systems you already run, that integration is exactly where a credential's blast radius stops being yours alone.

In our own audit work, the reason a single key becomes a full compromise is almost always scope — the key reaches far more than the one job it was created for. That's our observation, not something the report claims.

Does AI-assisted code leak more secrets?

Nobody has measured it. That answer is worth more than a confident one.

What the report doesn't say is that AI-written code leaks secrets. The words "vibe coding", "AI-generated code" and "code quality" appear nowhere in it. Anthropic does use "vibe hacking", but that describes attackers pointing AI at a goal and leaving it to work out the details — which is what the coverage conflating the two has got wrong.

The only randomised controlled trial of AI-assisted coding security, Perry et al. at ACM CCS 2023, doesn't test secrets at all — the words "credential", "hardcoded", "secret" and "API key" appear zero times in it. The Veracode benchmark behind the widely-quoted "45% of AI code is insecure" tests four vulnerability classes, and hardcoded credentials isn't among them.

What exists instead is observation. GitGuardian found commits that Claude Code had tagged as its own work — a line the tool adds at the bottom of each commit — showed a 3.2% secret-leak rate against a 1.5% baseline, then cautioned that this "should not be read as a simple tool failure". Apiiro reported AI-assisted developers exposing cloud keys "nearly twice as often" as non-AI peers, without publishing sample sizes or how it classified a developer as AI-assisted.

Those point one way. They're observations on self-selected samples, which is not the same as a measured rate — and treating them as the same is how a plausible story becomes a wrong one.

For a team in KL weighing whether to let an AI assistant near production code, our view is that the uncertainty is the answer. The tool is not the variable worth arguing about. Whether anyone opens the built file before it ships is.

The volume figure is firmer, and more interesting than the headline suggests. GitGuardian counts 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% rise year on year and the largest single-year jump it has recorded. Commit volume rose 43% over the same period. So the count climbed sharply while the rate per commit went the other way. Our reading of those two figures: the total grew because far more code is being written, rather than because each commit got worse.

And they stay live. More than 64% of a previously leaked dataset was still valid when GitGuardian retested it in January 2026.

Since 1 June 2025, this is a PDPA problem

Until June last year, a leaked credential was something you fixed quietly. Now it can put you on a clock with the Commissioner.

Section 12B of the PDPA, inserted by the 2024 amendment Act, requires a data controller — the business that decides what personal data gets collected and why, which is you rather than your vendor — to notify the Commissioner of a personal data breach "as soon as practicable". It commenced on 1 June 2025 — later than other parts of the same amendment, which is a common source of confusion.

Not every breach is notifiable. The duty bites where the breach causes or is likely to cause "significant harm", and the Commissioner's guideline treats more than 1,000 affected individuals as "significant scale".

The 72 hours everyone quotes isn't in the Act. It comes from the Commissioner's guideline, which sets notification "no later than seventy-two (72) hours from the occurrence of the personal data breach". Affected individuals are told within seven days of that.

Read that guideline yourself rather than a summary of it — it's linked above. One paragraph starts the clock at the breach; others start it when the controller is informed. The gap is the regulator's, and we're not going to resolve it for you.

Failing to notify the Commissioner carries a fine up to RM250,000, up to two years' imprisonment, or both. Breaching the Security Principle — the duty to take practical steps to protect personal data — carries up to RM1,000,000 or three years, raised from RM300,000 in April 2025.

Two details most coverage misses.

The Commissioner's own examples of a personal data breach include "a system misconfiguration leading to… inadvertent sharing of personal data with third party" and "an external party gaining access by unlawful means to the data controller's network or user accounts". Our reading, not the Commissioner's, is that an exposed key is a plausible route to both.

And since April 2025 the Security Principle binds data processors directly, not only through your contract. If an agency processes personal data on your behalf, it carries that duty itself. So do you — which is worth raising early when you are choosing who builds your software.

One thing we won't tell you, because no source supports either answer: whether a leaked API key alone, with no personal data reached, is notifiable. The duty attaches to personal data. The key gets someone in; the reporting question starts when they reach personal data with it.

This is a starting point for a conversation with your own advisers, not legal advice. If data residency is part of that conversation, our guide to the National Cloud Policy covers the adjacent ground.

Four things worth doing this week

1. Look in the shipped app, not the repository. In the audits we run, source control is usually the only place anyone has looked. The pipeline in the report decompiled shipped applications — the built file, the one in the store. A private repository protects nothing that was compiled into the download.

2. Treat anything you find as already taken. More than 64% of that dataset was still valid when it was retested. Rotate it, then assume it was already used.

3. Write down what each credential can reach. A key scoped to one table and a key that reaches everything differ in how much personal data an intruder can get to with them — and it is reaching personal data, not the key itself, that starts the notification question.

4. Decide who makes the call before you need to. The Commissioner's guideline requires a documented breach response plan. Write down who files it, and who decides that it needs filing.

What we do about it

We run a two-stage service for this called Vibe Code Rescue. An audit tells you what's exposed and whether the thing is worth repairing. Then a fix, measured against criteria we agree in writing before anyone touches the code — if we miss them, you don't pay for the fix. Where the audit says rebuild rather than repair, we say so and quote that separately. We apply the same two stages to an AI agent that has stopped working.

We also teach the part that prevents needing us. Our Vibe Engineering courses cover environments and secrets, tests, and reading a change before accepting it.

The useful thing in this article costs nothing and takes an afternoon: pull apart your own shipped application and look for keys inside it. Find nothing and you've lost an afternoon. Find something and you've found it before a machine that was never choosing.