> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rallied.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity Verification

> Require employees to verify their identity before sensitive actions.

For sensitive operations — password resets, admin account creation, permission changes — the agent can require the requesting employee to verify their identity via multi-factor authentication before executing. This ensures the person asking for a sensitive action is actually who they say they are, not just anyone who got their hands on the originating ticket, call, or chat.

## How it works

When the agent determines that a requested operation is sensitive, it pauses execution and initiates an identity verification challenge with the employee's MFA provider. The employee must approve a push notification on their authenticator app before the agent proceeds.

<Steps>
  <Step title="Agent detects a sensitive operation">
    As the agent builds its plan, it identifies that one or more steps require elevated assurance — for example, resetting a Microsoft 365 password or creating a new admin account.
  </Step>

  <Step title="Agent initiates verification">
    The agent calls the identity verification service, which sends a push notification to the employee's authenticator app (Microsoft Authenticator or Duo Mobile, depending on your configuration). The agent tells the employee on the source ticket, call, or chat that they will receive a verification push and should approve it.
  </Step>

  <Step title="Employee approves the push notification">
    The employee opens their authenticator app and approves the push notification. This confirms their identity.
  </Step>

  <Step title="Agent receives the result">
    The backend monitors the verification result automatically — either by polling the provider or receiving a webhook callback, depending on the provider. The agent does not need to ask the employee anything further.
  </Step>

  <Step title="Agent proceeds or stops">
    If the employee approved the push:

    * The agent proceeds with the sensitive operation and confirms completion on the source ticket, call, or chat.

    If the employee denied the push or the verification timed out:

    * The agent reports the failure on the source ticket, call, or chat and does not execute the action. The employee can resubmit their request if they want to try again.
  </Step>
</Steps>

## Supported providers

<Tabs>
  <Tab title="Microsoft 365">
    When your Microsoft 365 integration is connected, the agent triggers MFA through the user's registered method — typically a push to **Microsoft Authenticator**, but it falls through to whatever the user has configured.

    * The employee receives a standard Microsoft Authenticator push, identical to the ones they already use for Microsoft 365 sign-ins.
    * The result is resolved automatically through Microsoft Graph — no action required from your technicians.
  </Tab>

  <Tab title="Duo">
    When your Duo integration is connected, the agent sends a push notification through the **Duo Mobile** app on the employee's enrolled device.

    * The employee receives a standard Duo push notification.
    * Duo notifies the backend of the result via webhook when the employee responds.
    * No action is required from your technicians — the verification result is resolved automatically.
  </Tab>

  <Tab title="Traceless">
    When your [Traceless](/integrations/traceless) integration is connected, the agent sends a verification request to Traceless, which routes the push to the employee's existing authenticator — Microsoft Authenticator or Duo Mobile — based on the **Default Push Method** you selected when connecting.

    * Traceless reconciles the employee's work email against the connected MFA system to find the right device.
    * The backend polls Traceless every few seconds for up to 5 minutes until the verification resolves.
    * Use Traceless when your end users have mixed MFA tools and you want a single connection that covers all of them.
  </Tab>
</Tabs>

## Configuration

Identity verification does not require any configuration beyond connecting your MFA integration. Once Microsoft 365, Duo, or Traceless is connected, the agent automatically triggers identity verification whenever it determines an operation is sensitive.

<Info>
  Credential resets, admin privilege changes, and permission grants always trigger identity verification. The agent classifies the request automatically — you don't define which operations qualify.
</Info>

## What happens when verification fails

<AccordionGroup>
  <Accordion title="Employee denies the push notification">
    The agent immediately stops. It reports the denial on the source ticket, call, or chat and does not execute the action. The employee can resubmit their original request if they want to try again.
  </Accordion>

  <Accordion title="Verification times out">
    If the employee does not respond to the push notification within the provider's timeout window (up to 3 minutes for Microsoft 365; up to 5 minutes for Traceless; Duo uses its own configured timeout), the verification expires. The agent reports the timeout on the source ticket, call, or chat and does not execute the action.
  </Accordion>

  <Accordion title="Employee has no enrolled device">
    If the employee has no MFA device enrolled with the connected provider, the push cannot be delivered. The agent reports that verification could not be completed and escalates the request to your technicians for manual handling.
  </Accordion>
</AccordionGroup>

<Warning>
  If verification fails or times out, the agent never executes the sensitive operation — regardless of other approvals that may already be in place. A fresh verification is required for each new attempt.
</Warning>