Skip to main content
Clerk provides identity to the Lucia Admin operator, Lucia Fieldwork and Eval Labs, but each product owns its own authorization contract. Sign-in alone never grants property access, cross-user evidence access, or a privileged product role.

​
Lucia Admin: every admin door checks the operator

Verified in Engine dev source at e2166b86ac6794a1423c7b2ce1b293a3dba505c4 (the admin gate, LUCI-171):
  • every /admin/* route family, reads and writes, requires the verified Clerk operator session the operator-attention and resolve-action gates already required, on every method;
  • reads need the operator’s read permission, writes need the mutate permission with impersonation rejected;
  • an anonymous or unverified caller receives 401 (admin_unauthorized); OPTIONS passes so CORS preflight keeps answering;
  • the same gate covers the legacy /lucia guest reads that once served guest name, email and phone to anonymous callers.
The source records the reason in its own words: phase 01 gated the writes, phase 04 “closed the reads, which served full guest PII to anonymous callers.” Verified on Development on 2026-09-03: writes without a session answered 401 at engine dev b95a83c, and every /admin/* read joined the gate at ed073c5 the same day (LUCI-171, In Review at the time of this read; the founder’s own live proof is not on the record). It is written here as the served source contract at the named commit, not as a Linear status. Fieldwork is unchanged by this gate. On the admin side, every request to the Engine carries the operator’s Clerk session token centrally (admin dev 4ebdb5d, 2026-09-03). Lucia Admin holds no Clerk secret; the Engine decides.

​
Lucia Fieldwork boundary

Verified in the Fieldwork App/API source:
  • the App presents the Clerk-backed sign-in and session experience;
  • the API verifies the Clerk session and authorized party;
  • the API carries the active Clerk organization, role, and permissions into a server-owned authorization context;
  • organization membership is resolved against the configured organization-to-property profile; and
  • missing, ambiguous, unconfigured, or unauthorized property membership fails closed.
The browser may display or submit a property identifier, but it is never authority on its own. The Fieldwork API resolves the authorized property on the server before conversation and workflow access. This source verification did not include a new authenticated production interaction on 2026-09-10. It does not prove current Clerk dashboard settings, organization membership, or access for a particular person. See What is Lucia Fieldwork for the product ownership map.

​
Maintenance Inbox operator identity

Messages sent from the Maintenance Inbox to a Fieldwork employee must display a real name from the signed-in operator’s Clerk identity. That identity is presentation evidence for who sent the message; it does not grant a new role, widen property access, or turn the message into an approval or completed action. If a trustworthy Clerk name is unavailable, the system must fail the compose requirement rather than invent an operator identity. See Messages and replies for the per-item thread workflow.

​
Eval Labs boundary

Eval Labs resolves a server-validated product role from the signed-in Clerk identity and recognizes:
  • owner
  • admin
  • evaluator
  • tester
Missing or unknown values fail closed for protected routes. Current source boundaries: Client route/action gates and Supabase RLS are separate layers. A visible route or button is not durable authorization; the relevant database operation must also succeed under the signed-in identity. Use the canonical Role and Access Model and Roles and Access Matrix for exact surface grants.

​
Scope limit

This page does not infer Clerk configuration for the Guest Agent or any surface not named above. It also does not publish tenant identifiers, user identifiers, organization identifiers, authorized-party values, secret keys, session tokens, or provider-console settings.

​
Evidence rule

For a current access claim, capture:
  1. the owning source commit;
  2. the intended Clerk role or organization membership;
  3. the authenticated route/action result;
  4. the server-side authorization result;
  5. the durable RLS-backed operation when applicable; and
  6. the verification date and environment.

​
See also