Clerk

Live audit of your Clerk instance — catches dev-key-in-prod, unverified email senders, and zero-MFA on production instances with real users.

Available on the Growth tier. Read-only API key — we never modify your Clerk instance, never read user data.

Why this matters

Clerk makes auth easy enough that founders ship it in a single afternoon. The two failure modes that hurt at launch: a dev instance still wired to production traffic (so anyone can sign up at any email and never verify it), or a production instance with real users where MFA is disabled across the board. Repo scanning can’t see either; the Clerk dashboard can.

Connect Clerk

Generate a backend API key.

Clerk dashboard → API Keys → copy the Secret Key for your production instance. (We read-only, but Clerk only exposes a single secret-key tier for backend access; we never write.)

Paste into PulseLight.

Project settings → Connected platforms → Clerk → paste the secret key + the instance name (e.g. acme-prod). KMS-encrypted at rest.

First scan.

Findings roll into the Secure pillar on the next scan.

What we verify

Production instance, not development
We check the instance kind. A repo whose code references a production-shaped Clerk publishable key (pk_live_*) but whose connected instance is in development mode → blocker. Dev mode lets anyone sign up with any unverified email; not a thing you want in production.
MFA enabled on prod with real users
For instances with >100 users, we check whether MFA is available as a login factor. Optional MFA on a busy production instance → warning. Required MFA never triggers a finding.
Email sender verified
Clerk lets you customise the sender domain for verification emails. If the sender domain DNS isn’t verified, emails land in spam. We surface as a warning.
Webhook signing secret matches code
Cross-references your repo (which we already scan) for Clerk-webhook handlers and confirms the webhook is configured on the Clerk side with a signing secret your code can verify against.

Common findings

CLERK-DEV-IN-PROD-001 — Development instance handling production traffic
  Repo:     references pk_live_* (production publishable key)
  Clerk:    instance kind = 'development'
  Why:      Anyone can sign up with any email, no
            verification required. Real users land on a
            dev-mode instance and the security posture is
            wrong.
  Fix:      Promote the instance to production in Clerk
            dashboard, or update env vars to point at a
            different instance.

CLERK-MFA-001 — Optional MFA on a busy production instance
  Users:    1,247
  MFA:      Available but optional
  Why:      A production instance with real users should
            consider requiring MFA on at least admin / paid
            tiers. Optional-only is a future incident.
  Fix:      Enable required MFA on Clerk's authentication
            settings, or require it for selected user roles.

What we don’t do

We never read user data, sessions, or tokens. We only call instance-metadata endpoints and the configured-factors API. The list of API calls we make is in our overview page.

Disconnect

From Settings → Connected platforms → Clerk, click Disconnect. You can also rotate the secret key from Clerk’s API Keys page directly.