Home ClaudIA Features How ClaudIA Validates User Identity

How ClaudIA Validates User Identity

Last updated on Aug 03, 2026

When to Use

  • Your company's security team asks how user identity is verified before ClaudIA delivers sensitive data.

  • You will enable sensitive operations in automated service — check statements or balances, view registration data, change account information.

  • You need to decide between verifying identity via an agent or through a Controlled Flow.

  • You want to identify what needs to be built on your API side before enabling this type of operation.

Prerequisites

  • An existing communication channel — web widget, WhatsApp, email, etc.

  • For the web widget: identity validation via signature (HMAC) enabled on the channel.

  • For token step-up: two APIs on your side — one to trigger the token and one to validate the provided token.

Releasing sensitive operations on open channels without the token step-up described in this article exposes the user's data to anyone with access to the device. Do not enable this type of operation before having the two APIs described in the section "What needs to exist on your API side".

About this article

The answer to "how do you know it's really him?" varies by channel, and this is the part that often gets lost in a rushed explanation. In a logged-in channel, identity arrives signed by your own application. In an open channel, the origin number is the first factor, and the second factor is a token generated, delivered, and verified by your company.

ClaudIA guides the conversation. The decision to release sensitive data always rests with your application.

How it works

Identity assurance varies by channel

Each channel provides the user with a different level of certainty about who they are. The token step-up is the layer shared by both channels: recommended where identity is only assumed, optional where it is already verified.

Web widget, in logged-in area: verified identity at origin

When service occurs within the web widget inside your logged-in area, the user has already completed all login challenges before reaching the chat. Your application signs their identity, and the widget verifies this signature via HMAC.

This has two properties relevant to risk analysis. First, that the signature can be required as mandatory on the channel: without a valid signature, the chat does not open — it's not an optional field someone forgets. Second, that the validation result is recorded in the contact-channel link and remains consultable after the service, making the verification auditable.

Practically, every conversation arriving via this channel is inherently verified.

WhatsApp, in open channel: presumed identity by the channel

On WhatsApp, ClaudIA knows which number the message came from. Possession of this number — the device or a WhatsApp Web session — is a legitimate first factor, proof of possession.

However, it does not cover scenarios like an unlocked device or a web session accessible to a third party. Possession of the number doesn't distinguish the owner from someone holding the device.

Therefore, before performing a sensitive operation on this channel, the token step-up below is required. Similarly, if you want a second factor even in the web widget — because the computer might be left open — the same step-up applies.

The token step-up, step-by-step

The example below uses account statement inquiry but applies to any operation you classify as sensitive.

  1. User requests sensitive operation. ClaudIA has already identified the user via the number and has the tool to deliver the data.

  2. ClaudIA does not deliver the data immediately. It requests verification. The agent is instructed to explain that a token will be sent and ask the user to return it.

  3. ClaudIA calls your API to dispatch the token. ClaudIA does not generate the token — your application does that and sends it.

  4. Your application delivers the token via the channel deemed most secure. For example, email. One-time use. From this point, there are two factors across channels: WhatsApp number and email inbox.

  5. User inputs the token in chat.

  6. ClaudIA calls your validation API. "Did this user provide this token — does it check out?" Your application responds. ClaudIA does not validate the token.

  7. With confirmation, data is released.

In the process, the token does not pass through Cloud Humans. It goes directly from your application to the user's second channel. ClaudIA only sees the value at step 5 when the user types it in the chat.

Who does what

Your application:

  • generates the token;

  • chooses the delivery channel;

  • delivers the token to the user;

  • validates the token entered;

  • decides to release the sensitive data.

Cloud Humans:

  • guides the conversation and instructs the agent;

  • transports the token entered by the user in the chat.

Determinism: what is guaranteed and what is not

In the standard flow, the decision to trigger verification before a sensitive operation is made by a language model, based on instructions given to the agent. This is nondeterministic, and it's important to clarify exactly what is not guaranteed.

There is no failure mode "ClaudIA accepted an invalid token." Token validation is handled by your API — ClaudIA cannot validate and thus cannot accept invalid tokens.

There is a failure mode "the agent failed to trigger verification before a sensitive operation." This is a narrow scope and addressable.

The three ways to close the gap

In order of increasing guarantee.

Specialist Agents + Tools, the standard path: Verification is an instruction given to the agent. We use advanced models and have no record of incidents of this type, but the guarantee here is statistical, not structural. This is suitable for most operations; for formal security controls, the distinction matters.

Controlled Flows, the deterministic alternative: Verification becomes a scripted step, based on tree logic, without a language model in the decision. Deterministic by design. The trade-off is user experience: interactions become more rigid, so this is not the default recommended. It can be applied only to the sensitive part, preserving natural conversation elsewhere.

What's needed on your API side

  • Token dispatch. Receives the user's identifier — number, email, or internal ID — and sends a one-time token via the channel you deem secure.

  • Token validation. Receives the identifier and token from the user, responds whether it is valid. The decision is yours.

  • Recommended. The API that returns the sensitive data should check the verification status beforehand. This turns the instruction check into structural control.

Notes

  • Verification persistence. Configurable: can last for the entire session or be required again for each sensitive operation. Your choice, defined in the agent's instruction.

  • Token remains in chat history. The token that the user types is a message in the chat and remains in the history, like any other message. Therefore, it should be one-time use and short-lived. ClaudIA does not treat it as a credential, does not reuse it, and does not accept it as proof of identity for subsequent interactions.

  • On SMS as token channel. The flow works the same if your application sends the token via SMS. Evaluate risks such as SIM swap and delays beforehand — many security teams exclude SMS as a second factor for these reasons.