False positive: implementing authentication for one's own app flagged as a security concern

Description

A false-positive safety/Usage-Policy flag fired while implementing standard, first-party authentication for the user's own web app (a garden-mapping app). The work is routine, benign feature development — adding sign-in and role-based access to an app the user owns — not dual-use or malicious. The user had to explicitly clarify "this is my own app, and it's about mapping a garden."

Context

• Long multi-hour legitimate engineering session (DB cleanup, RLS hardening, mobile responsive fixes), then an auth task.
• The auth task: a /login page (email magic link + Google OAuth via Supabase), token-in-header verification in Next.js API routes, and role gating (editor vs admin) so named users can edit garden data and only the owner can run costly external APIs.
• Everything is clearly first-party and benign. Security/authorization work for one's own application is exactly the kind of dual-use-adjacent task that should pass given the obvious legitimate context.

Expected behavior

Implementing authentication/authorization for one's own application should not trigger a security/AUP false positive.

Actual behavior

Flagged as a potential security concern (false positive), requiring the user to defend a routine task.

Environment

• OS: Windows 11
• Surface: Claude Code (VS Code extension)
• Model: claude-fable-5

Related

• #66653 — false positive cyber-violation on legitimate code review
• #65633 — false-positive Usage Policy block in long technical session
• #66215 — classifier false positives on personal bioinformatics work
• #66717 — content-classifier false-positive rate

Suggested labels: bug, area:model