Skip to main content

Authentication overview

Authentication is an AI Agent capability that verifies the user's identity through a short, conversational question-based flow at the start of a session. When it is enabled on an AI Agent, the auth flow runs before anything else — before intent classification, before any dialog, before the greetings intent — and only after the user passes (or fails) does the conversation continue to your regular workflow.

You configure it once on the AI Agent. The Authentication Agent — an LLM-powered subagent that runs inside the AI Agent's message path — then handles the back-and-forth with the user, validates answers against the ground truth you control (variables, exact match, fuzzy match, or a webhook you own), and routes to a dialog node of your choice on success or on failure.

When to use Authentication

Use Authentication when a workflow is gated on knowing who the user is — and getting it wrong is costly.

  • Account access — looking up a balance, opening a ticket on the user's behalf, changing account settings.
  • Debt collection / financial services — required identity verification before discussing amounts.
  • Healthcare / insurance — HIPAA-style scenarios where the user must be identified before any case-specific information is shared.
  • Any flow that contains sensitive customer data as context variables you don't want to leak to an unauthenticated user.

If you only need light identity context (e.g. just look up the user's name from the channel), a dialog webhook (Dialog webhooks) is usually simpler. Reach for Authentication when you need the AI to converse through the verification — handling clarifications, multiple acceptable forms of identity, failure paths to human handover, etc.

The mental model

A typical auth flow has two steps. The distinction is easiest to see in terms of where the conversation originates:

  • Identificationwho do you claim to be? Used when the conversation is inbound and you don't yet know who you're talking to — or whether they're a real customer at all. The user supplies an identifier (an SSN, an account number, a tax ID) that the agent can use to look the rest of them up.
  • Verificationprove that you are who we think you are. Used when you already know who the user should be. Either the conversation is outbound (the agent proactively reached out to a known customer), or identification just resolved them against a record. The user supplies a second piece of information (date of birth, last 4 of card, an OTP) that you compare against the record on file.

Either step is optional, but at least one must be enabled. The shape of your flow follows from where the conversation comes from:

  • Inbound (most common) — both steps. Identification first, then verification.
  • Outbound — verification only. You already know who you called; you just need to confirm it's actually them.

Both steps pass → the conversation jumps to the Trigger node on success you chose. Either step fails → the conversation jumps to the Trigger node on failure (typically a handover or a graceful decline).

What you'll configure

You set Authentication up on the Authentication page of the AI Agent (under Workflows). The page is organized around the flow itself:

In the consoleWhat it controls
Starting behaviorTriggerWhen the auth flow starts. v1 supports When a conversation starts.
Identify the user stepThe first step. Asks the user to claim an identity. Optional.
Verify the user stepThe second step. Confirms the identity against your records. Optional.
Trigger node on successThe dialog node the conversation jumps to once auth passes.
Trigger node on failureThe dialog node the conversation jumps to once auth fails.

Each step has its own panels:

In the consoleWhat it controls
Step toggle on the step cardEnables the step.
Add question / Choose from a templateUp to 5 questions per step. Each one has its own answer type, weight, and validation method.
Successful identification/verification panel → Score thresholdTotal points needed for the step to pass. See Scoring.
Guidelines drawerFree-text instructions to the agent — your tone, your scripted greeting, your offered alternatives. See Guidelines.
Failed identification/verification panelThree independent toggles: Incorrect responses, Guideline-based, Authentication timeout.
Verify the user step → Pre-enter webhookOptional. Runs a webhook just before verification starts, to fetch ground truth. See Webhooks.

For a click-by-click setup walkthrough see Set up Authentication.

How Authentication changes the message path

When Authentication is enabled, the Authentication Agent runs before intent classification on the first turn(s) of a session. The greetings intent does not fire on session start — the Authentication Agent generates the first message itself, so it can be tailored (via your step guideline) to ask the first identification question directly. Once the user passes or fails, the conversation continues from the configured success or failure node, where the rest of your workflow takes over.

See How messages flow for the wider picture.

What the Authentication Agent can see

The Authentication Agent has limited context by design — the central safety property of Authentication.

Visible to the Authentication AgentHidden from the Authentication Agent
Question textExpected answers / ground-truth values
Question type (date, number, etc.)Validation method on each question (exact match, fuzzy match, webhook, …)
Your step guideline + failure guidelinePoint values and score threshold
The conversation so farWebhook URLs, tokens, headers
User's display name (if available from the channel)Other workflows / dialogs in the AI Agent

Validation happens server-side. The Authentication Agent submits a candidate answer for validation and learns only whether it was accepted — never why, never the expected value, never how close it was. Even if the Authentication Agent is prompt-injected, it has no secrets to leak.

Where to next