Access Control

Access Control lets you decide who can use your AI app and how they authenticate. Choose from four modes ranging from fully open to restricted by email whitelist.

The Four Auth Modes

Configuring Access Control

How Each Mode Works

Open Access

User visits your app
  → No auth card shown
  → Greeting fires immediately
  → User chats anonymously

Users get instant access with zero friction. Optionally, you can use the collectEmail tool in your system prompt to capture emails during the conversation without requiring formal signup.

Encouraged Sign-up

User visits your app
  → Signup form shown (dismissible)
  → User can sign up OR dismiss and chat as guest
  → Either way, conversation starts immediately

The signup form appears as the first message in chat. Users who dismiss it see a small banner (“Sign in to save your progress”) but can still chat freely. Good for capturing contact info without blocking access.

Required Sign-up

User visits your app
  → Full-screen sign-in screen shown (not dismissible)
  → User signs up or logs in
  → Greeting fires and chat becomes active

Users must create an account or log in before they can send any messages. The chat stays hidden behind a full-screen sign-in screen until authentication completes.

Restricted Access

User visits your app
  → Full-screen sign-in screen shown (not dismissible)
  → User signs up with email
  → Email checked against whitelist/domain
  → If approved: access granted
  → If not: "This email is not authorized to access this application." error

Same as Required, plus email validation. Only pre-approved emails or emails matching your allowed domain can access the app.

HIPAA Compliance

When HIPAA Compliance is enabled in the Access tab, the auth mode is automatically restricted:

• Open and Encouraged modes are disabled
• Only Required or Restricted modes are available
• This ensures all interactions are authenticated for compliance

For HIPAA apps, Chipp holds BAAs with Google (Gemini models) and Anthropic (Claude models, excluding Claude Fable). Choose one of these BAA-covered models for your app’s chat — the HIPAA Compliance toggle enforces authentication and session controls but does not by itself limit which chat model you can pick. See HIPAA-Compliant Models for the full model list and what the setting does and does not guarantee.

Single Sign-On (SSO)

In addition to email/password, users can sign in with a third-party identity provider. Turn on Google Sign-In, Microsoft Sign-In, Salesforce Sign-In, or Clever Sign-In in the Access tab (not shown in Open mode). SSO providers appear as additional buttons on the auth card (for example, “Continue with Clever”). Turn on SSO-Only Login to hide the email and password form.

For K-12 school districts, Chipp supports Clever SSO: students, teachers, and staff sign in with their existing school Clever account. See the Clever SSO for Schools guide for setup instructions and prerequisites.

Bring Your Own Auth

If your application already authenticates users with its own login system (WorkOS, Auth0, Clerk, Okta, custom SSO, or signed links), your backend can sign them into Chipp directly — no Chipp login screen, and identity that follows the user across devices. This works with every auth mode and inside cross-origin iframe embeds. See the Bring Your Own Auth guide.

In-Chat Authentication

Authentication happens inside your app — there’s no separate login page. In Encouraged mode, the auth card appears inline in the chat. In Required and Restricted modes, the same auth form appears on a full-screen sign-in screen in front of the chat. The auth card supports:

• Signup with email and password
• Login for returning users
• OTP verification via email code
• Forgot password and reset flow

In Encouraged mode, the auth card appears as a synthetic assistant message, keeping users in the conversation flow.

Redirect After Signup

In the Redirect After Signup card, you can optionally set a redirect URL (an absolute https:// URL). After a new user signs up, they are sent to that URL instead of staying in the chat. Returning users who log in are not redirected. Useful for:

• Onboarding flows
• Terms of service acceptance
• Payment pages
• Custom welcome experiences

Use Cases