Audit an authenticated page with AIdenID

Recipe for running Jules Tanaka's frontend audit on a page behind login using an ephemeral AIdenID identity.

  • how-to
  • aidenid
  • jules
  • authenticated-audit

Audit a page behind login — e.g. `/dashboard` or `/billing` — without using a real test account.

Step 1 — Provision an ephemeral identity


IDENTITY=$(sl ai provision-email --tags "audit,signup-flow" --ttl 3600 --execute --json | jq -r '.identity.id')

EMAIL=$(sl ai identity show "$IDENTITY" --json | jq -r '.email')

echo "Using: $EMAIL"

TTL is 3600s (1 hour). After that the identity auto-squashes with a tombstone record.

Step 2 — Trigger signup/login

You can drive this manually via curl or via a Playwright script:


# Example: POST to your app's signup endpoint

curl -sS -X POST https://app.example.com/signup \

  -H "Content-Type: application/json" \

  -d "{\"email\": \"$EMAIL\"}"

Step 3 — Wait for the OTP


OTP=$(sl ai identity wait-for-otp "$IDENTITY" \

  --timeout 60 \

  --min-confidence 0.8 \

  --json \

  | jq -r '.code')

echo "Got OTP: $OTP"

`--min-confidence 0.8` means the extractor must be at least 80% confident before returning. If regex fails, an LLM fallback runs; if the LLM fails below the threshold, the command returns an error.

Step 4 — Complete authentication


curl -sS -X POST https://app.example.com/verify \

  -H "Content-Type: application/json" \

  -d "{\"email\": \"$EMAIL\", \"code\": \"$OTP\"}"

Your app should now have a session cookie for `$EMAIL`.

Step 5 — Run the frontend audit


sl audit frontend \

  --url https://app.example.com/dashboard \

  --email "$EMAIL" \

  --stream

The `--email` flag tells Jules to use the AIdenID credentials for login during the audit. Jules will inspect:

  • Cookie security flags (HttpOnly, Secure, SameSite)
  • CSP headers on authenticated pages
  • Console errors after login
  • DOM structure for common accessibility issues
  • Authenticated-only JavaScript bundle size

Step 6 — Revoke the identity


sl ai identity revoke "$IDENTITY"

A tombstone record is written; the email address is permanently unavailable for any future use.

Best practices

  • **One identity per audit run.** Do not reuse identities across audits — it breaks the "ephemeral" invariant.
  • **Short TTLs.** Default to 3600s unless you are testing a multi-hour flow.
  • **Tags matter.** Every identity should be tagged with the audit purpose so tombstones are traceable.
  • **Never combine with production user data.** AIdenID is for ephemeral test identities only.

Related

  • [AIdenID agent workflows](/docs/aidenid/agent-workflows) — 5 recipes
  • [Identity lifecycle](/docs/aidenid/identity-lifecycle)

Structured Answers

Can I use AIdenID for multi-factor flows that require a hardware key?

No. AIdenID only handles email-based OTPs. Hardware keys (WebAuthn, FIDO2, TOTP) require dedicated testing infrastructure.

What confidence threshold should I use for OTP extraction?

0.8 (80%) is the default and works for most flows. Drop to 0.6 for weird OTP formats, raise to 0.95 for high-value production auth tests.