[Feature Request] Support for Cloudflare Zero Trust authentication headers

Bug Description
What I was doing: building Cloudflare Zero Trust authentication for my own production app (rides.wooshdelivery.com) in
▎ Claude Code — replacing a shared admin key with per-person login backed by verified Access JWTs.
▎
▎ What got flagged: a message where Claude reported results of security tests it had just run against my own
▎ infrastructure:
▎ - a test suite that mints forged RS256 JWTs to confirm my app rejects them
▎ - a spoofed Cf-Access-Authenticated-User-Email header claiming to be me
▎ - a POST carrying a forged token at my own admin endpoint
▎
▎ Why it's legitimate: all of it was defensive. That header spoof is a documented Cloudflare Access failure mode — the
▎ header is plain text and only stripped on Access-protected hostnames, so an app that trusts it blindly is wide open on
▎ any host outside the wall. My app deliberately keeps one hostname outside (a Stripe webhook posts there), so this was
▎ the specific hole the work existed to close. The tests prove the app refuses it. The production result was 403 Nope.
▎ — which was the goal.
▎
▎ The pattern that trips it: narrating an attack. Defensive security work has no other shape. The only way to
▎ demonstrate a wall holds is to throw something at it and report that it held.
▎
▎ Suggested discriminator: the asserted outcome. "Fired a forged token, got 403, defense holds" is the inverse of an
▎ attack in progress. Context was also unambiguous — same session had been deploying to that domain for hours, and the
▎ target was a domain I own.

Environment Info

• Platform: win32
• Terminal: mintty
• Version: 2.1.220
• Feedback ID: fda8b254-4345-43ec-af41-07acfbb6cefa

Errors

[]