Security

Access Control Model

Arc uses a layered security model:

1. Email allowlist — only pre-approved emails can create accounts
2. Row Level Security (RLS) — all database queries are scoped to the authenticated user's team memberships. It is not possible to access another team's data through the API.
3. Role-based permissions — Owners and Members have different capabilities within a workspace
4. Super admin isolation — the /admin panel is only accessible to users with app_metadata.role = "super-admin"

Destructive Action Verification

Certain irreversible actions require email verification before proceeding:

• Deleting a team workspace
• Deleting a personal account

A one-time verification code is sent to your registered email. You must enter the code to confirm the action.

This requires a working SMTP provider. If you see an error sending the code, contact your system administrator to configure email.

Session Security

• Sessions are tied to a secure cookie and expire after a period of inactivity
• Signing out on one device does not invalidate sessions on other devices
• Supabase manages JWT tokens and refresh cycles automatically

Data Isolation

All candidate data, jobs, interviews, and pipeline state are associated with a specific team account. RLS policies ensure:

• A user can only read data for teams they are a member of
• A user can only write data to teams they are a member of
• Admin operations (bypassing RLS) are only possible with the service role key, which is never exposed to the client

Webhook Security

Inbound webhooks from Cal.com, Tavus, Unipile, and Retell are validated using HMAC signatures. Requests without a valid signature are rejected before processing.