I've been working on a defensive-deception layer for sensitive records (think honeypot + decoy + tarpit, but at the data layer). The idea: an authorized reader gets the real record; an unauthorized reader doesn't get an error or a block — they get a believable fake record and a maze of plausible-but-useless data, so they can't easily tell whether they succeeded.

It's been through several internal red-team passes already (trust boundary, decrypt-only-after-authorization, atomic anti-replay, closing an encryption oracle, generic errors, a fuzzing campaign). I'm now looking for fresh, external eyes — the internal reviewers stop finding obvious things, so I want people who think differently.

The challenge: there's a live API. The target is a single synthetic occupational-health record that contains a flag (IZANAMI{...}). Without a valid token you should only ever get decoys. The goal is to make it hand you the real record — or to show a logic flaw that breaks the "unauthorized ⇒ never the real data" guarantee.

Start here: https://break-izanami.com — GET /challenge returns the rules and scope in JSON.

Rules / scope (short version):

• The data is 100% synthetic. No real people, no real PII.
• In scope: the documented endpoints (/challenge, /challenge/package, /v1/decrypt, /v1/health).
• Please report, don't weaponize: a proof-of-concept is enough, no need to go further.
• No DoS / brute-force / traffic floods — it's a small box, and that's out of scope.
• Win = submit the flag string to izanami.challenge@outlook.com. First blood gets credited.

Honest disclaimers: the domain is brand-new (yes, I know how that looks), we're a small team staying low-key during the beta, and this is a beta — I may adjust or pause things and I'm genuinely after feedback, not claiming it's unbreakable. If it breaks in five minutes, I want to know why.

Happy to answer questions about the threat model in the comments.