Korea's 10% revenue fines: the flaw behind Coupang's breach

What the Korean decree changes

The enforcement decree of the revised Personal Information Protection Act takes effect on September 11, 2026:

• Fines up to 10% of total revenue for a leak of 10 million people or more, through intent or gross negligence.
• Notification within 72 hours as soon as the risk of exposure is high, even before the breach is confirmed.
• Up to a 40% reduction for companies that invest in data protection and detect or notify quickly.
• A stronger CPO: appointment and dismissal go through the board at large companies.

The text rewards two specific technical capabilities: preventing illegitimate access and detecting it early. Coupang failed at both.

The flaw: a signing key that outlived its holder's employment

According to what the regulator and the Korean press have published, a former developer on the authentication team had access, while employed, to a key used to sign access tokens. When he left, the key was neither revoked nor rotated. It was then used to mint valid tokens that the system treated as if they came from the real authentication server, with no additional check. The Korean government puts the number of affected accounts at 33.7 million.

Three failures stack up:

1. A long-lived signing key, copied outside its vault (investigators mention keys stored on developer machines).
2. No rotation when someone with access left.
3. No detection: abnormal access from abroad went on for several months before being spotted.

Why this is so bad with JWTs

With signed tokens such as JWTs, the server only checks that the signature is valid. It does not look anything up to confirm the token was actually issued. Whoever holds the private key (or the HMAC secret) can therefore mint any token, for any user, with any lifetime. Resetting user passwords does nothing: only rotating the key invalidates forged tokens. The classic token mistakes are covered in our guide to JWT expiration.

How to test it

These checks take half a day and need no exotic tooling:

1. Inventory your signing keys: HMAC secret, RSA or EC key of the auth server, webhook signing keys, service keys (Supabase service_role, cloud service accounts). For each one, record where it lives and who can reach it.
2. Look for copies: Git repositories (history included), shared .env files, tickets, wikis, laptops. Tools like gitleaks or trufflehog find keys in history; see our article on secrets in Git.
3. Check the last rotation date of each key against recent team departures. Any key older than the departure of someone who had access must be rotated.
4. Test revocation: sign a token with the old key after rotation and confirm the API rejects it (401). Also confirm the server rejects alg: none and tokens without exp.
5. Test detection: take a legitimate token, use it from an unusual IP at an abnormal volume, and see whether an alert fires. If nobody notices, you will not meet a 72-hour notification deadline.

How to fix it

• Keep signing keys in a KMS or HSM: signing happens through an API call and the private key never leaves the service.
• Rotate keys on a schedule and publish them through a JWKS with a kid, so one key can be retired without breaking the service.
• Add secret rotation to the offboarding checklist, alongside disabling the account.
• Bind tokens to a server-side session for sensitive operations (exports, email changes, bulk reads), so a forged token with no matching session is refused.
• Log and alert on token issuance and on bulk access to many different accounts from a single source.

What changes when an AI agent holds these credentials

An AI agent wired into your back office often holds a broad, long-lived service token stored in an environment variable. That is exactly the profile of the Coupang key. If the agent reads a booby-trapped email or document, a prompt injection can lead it to call its tools to read or export accounts in bulk, with a perfectly valid token, and nothing distinguishes the abuse from normal use. Narrow that token's scope, keep its lifetime short and put a human approval step on export actions. The principles are the same as for the most common authentication flaws.

The lesson for European teams

The GDPR caps fines at 4% of worldwide revenue, and the CNIL already sanctions basic security failures. Coupang shows that a massive breach can come from a missed process step. The useful question is simple: if a former team member kept a copy of a key, how long would it take you to notice?

To see concretely what an attacker or a hijacked agent could do with your product's credentials, the Agent Red Team Express tests these scenarios in five days and delivers the evidence.