Conversational Identity: Access, Resets & Verification by Chat & Voice

Conversational identity is the practice of requesting and completing identity outcomes, such as unlocks, password resets, access requests, and approvals, by conversation, in the channels people already use, with the same policy, approvals, and evidence as the self-service portal. The conversation is the interface. It is never the authority.

That second sentence carries the whole design. Employees already live in Microsoft Teams, Outlook, chat, phone calls, and AI assistants, and would rather type "I'm locked out" than hunt for a portal. Meeting them there is easy. Doing it without opening a softer path around identity controls is the engineering problem. This hub covers the definition, the channels, the requests people actually make, the verification problem conversational channels create, and how the evidence and pricing work. Two companion pieces go deeper: requesting access in Microsoft Teams walks through one channel end to end, and what an Identity Continuity Layer is covers the deviceless verification that keeps the pattern working when phones fail.

What conversational identity is

Conversational identity has three properties, and a system that lacks any of them is something else.

The unit is an outcome, not a ticket. A chatbot that collects details and files a help desk ticket is a front end for a queue. Conversational identity completes the work: the account is unlocked, the password is changed, the access request enters its approval chain. Avatier's term for these completed, verified, policy-compliant results is Secure Outcomes, covering authentication, password resets, account unlocks, identity verification, access approvals, policy enforcement, and lifecycle changes.

The rules do not change with the channel. A reset requested in Teams passes the same identity check, password policy, and directory synchronization as a reset in the portal. An access request made to an AI assistant goes to the same approver a request form would have reached. The practical test is simple: if any conversational channel can complete an action the portal would have refused, the design has a bypass.

The record is the same, plus the channel. Auditors should be able to see that a change happened, who verified it, which policy allowed it, and that it arrived by conversation. Conversation is a new initiating experience, not a reason for a thinner audit trail.

The comparison below puts the portal and the conversation side by side. The experience changes. The controls do not.

The portal and the conversation differ only in how the request is made. Verification, policy, approvals, and the evidence record should be identical.

The channels, in 34 languages

Avatier's Identity Anywhere platform names nine channels where identity requests arrive:

• Web and Mobile: the familiar portal and app experiences.
• Microsoft Teams and Outlook: where knowledge workers already spend the day.
• Chat: a multichannel chat assistant embedded wherever the organization offers support.
• Voice and Phone: AI voice and call-center flows, including the service desk line people call when nothing else works.
• APIs: for applications and workflows that trigger identity outcomes programmatically.
• MCP-compatible AI: assistants such as Claude, Claude Code, Microsoft Copilot, and Avabot, connected through the Model Context Protocol, the open standard Anthropic introduced in November 2024 that lets assistants reach tools and data through MCP servers.

Not every organization needs all nine on day one. What matters is that each new channel plugs into the same identity layer instead of getting its own logic, approver list, and log. Channels built separately drift apart, and attackers look for the one with the weakest check.

Language is part of the same principle. Avatier supports 34 languages across every conversational channel, which covers the graphical interfaces, chat, and voice, and the printed Identity Challenge Card™ ships in the same 34 languages, including right-to-left Arabic and Urdu and the Chinese, Japanese, and Korean scripts. A worker in São Paulo, Warsaw, or Riyadh should be able to request, verify, and complete a reset in their own language through whichever channel they have open. The Password Portal pillar describes the self-service side of the same multichannel, 34-language design.

Nine channels, one identity layer. Each new channel should inherit the same policy, approvals, and evidence rather than ship its own.

What people ask for: example requests by module

Conversational identity is easiest to understand through the requests themselves. Avatier Actions, an MCP connector, exposes more than 50 identity outcomes as tools across eight modules. The table maps everyday requests to the module that completes them and the control that has to pass first.

What the person says	Avatier Actions module	What must happen before it completes
"I'm locked out of my account."	Password Management (unlock)	Verify the person, then unlock and record it
"I forgot my password."	Password Management (forgot password, change password)	Verify, check the new password against policy, synchronize
"Reset this caller's password."	Help Desk (verify user, assisted reset)	The caller is verified; the agent sees pass or fail
"I need access to the finance reporting app."	Lifecycle Management (request access and roles)	Policy check, then route to the approver
"Add Priya to the project group until March."	Group Management (membership, expiration)	Requester's authority over the group is confirmed
"What's waiting for my approval?"	Workflow Approval (pending requests and history)	Only the approver's own queue is shown
"Disable this contractor's account today."	User Management (enable, disable, account expiration)	Requester holds the authority to disable
"Launch the quarterly access review."	Access Governance (campaign management and review)	Campaign owner permissions apply
"Show me dormant accounts in sales."	Reports	Scoped to what the requester may see

Two things stand out. The requests span self-service and administrative work, so an employee unlocking their own account and a manager disabling a contractor share one conversational surface but face very different authority checks. And the right-hand column never says "the assistant decides." Authority comes from the identity platform the organization already runs.

For builders, a tool invocation behind one of these requests looks roughly like this illustrative sketch.

# Illustrative only: not the real Avatier Actions API schema
tool: request_access
requester: verified session (Microsoft Teams)
application: "finance-reporting"
justification: "Quarter-close reporting"
result:
  policy: checked
  approval: routed to application owner
  status: pending approval

The Teams version of this flow, from the first message to the approver's decision, is covered step by step in request access in Microsoft Teams.

The security problem: verify the person before acting

Conversational channels make one question harder: who is actually asking?

A portal forces the question up front with a login page. Conversations arrive with weaker or borrowed context. A Teams message comes from a signed-in session, but that session proves a device was signed in at some point, not that the person at the keyboard should be allowed to reset credentials right now. An AI assistant acts on behalf of a user, so it inherits whatever the user's session proves and nothing more. A phone call arrives with no authentication at all, only a voice and a story.

The vishing problem at the help desk

Voice at the service desk is the sharpest version of the problem. Vishing, or voice phishing, targets the moment a human agent decides whether to trust a caller. The attacker sounds urgent, knows the employee's name and manager, and may use a cloned voice. Knowledge-based questions can be researched. Texting a code to the caller's phone assumes the phone belongs to the caller and not to an attacker who already controls it. Agents under pressure make exceptions, and each exception is a reset handed to the wrong person. Avatier Ledger's security-team briefing tracks the vishing surface at the help desk for exactly this reason.

AI voice agents and chat assistants do not remove this risk. They can widen it, because an automated channel that accepts a persuasive story can be tried again and again. The same rule has to apply to human and automated channels alike: the channel is not the credential.

How verification works: verify, then act

Every conversational identity request should run through the same sequence, whichever channel it arrived on:

1. Resolve the request to an approved capability. "I'm locked out" becomes an unlock action, not an open-ended instruction. Anything that doesn't map to an approved capability is refused.
2. Establish who is asking. Use the MFA and adaptive authentication the organization already runs, including OTP, TOTP, FIDO2 security keys, passkeys, and biometrics, and step up the challenge when the action is sensitive or the context looks risky. The adaptive authentication and step-up authentication guides cover how to size the challenge to the action.
3. Fall back to deviceless authentication when devices fail. Lost phones, dead batteries, no signal, shared workstations, and frontline workers without a work phone are all common. Here the Identity Challenge Card takes over. The system or agent names a coordinate, the person reads back the matching word from their printed card and adds a private PIN, their directory identity anchors the challenge, and that coordinate value is spent. It works by voice as well as on screen, which is why it fits the service desk call. It is the fallback layer described in what an Identity Continuity Layer is: authentication that persists when device-dependent systems fail.
4. Check policy and route approvals. The requester's authority, the target resource's rules, and any approval chain apply exactly as they would in the portal.
5. Act. Only now does the unlock, reset, or access change execute.
6. Record. The outcome is written with who asked, how they were verified, what ran, and which policy allowed it.

For assisted work, Avatier's Assisted Reset pillar adds one more safeguard: the challenge goes to the user, not the agent, and the agent only sees pass or fail. The agent cannot be talked into skipping a step they never controlled. The recovery channel gap piece explains why this recovery moment, not the login page, is where many attacks now land.

Verification comes before any change. When the phone is lost, dead, or out of signal, the deviceless card keeps the sequence intact.

Evidence: every conversation leaves a record in Avatier Ledger

A channel that completes work without evidence creates a new blind spot, so every completed outcome needs its own record from the moment it happens.

In Avatier Identity Anywhere 2027™, each Secure Outcome records six fields: the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. The "initiating agent or experience" field is what makes conversational work auditable, because it shows whether the reset came from the portal, a Teams message, a phone call, or an AI assistant.

Avatier Ledger, the second MCP connector alongside Avatier Actions, turns every outcome into evidence and every report into a question. It records who asked, what ran, under whose authority, and what policy allowed it, for human-initiated and agent-assisted actions alike. Persona Briefings then shape the same evidence for the person asking:

• CISO: applicable compliance frameworks combined with identity and password statistics, with remediation grouped into 0–30, 30–90, and 90-plus-day windows.
• CFO: cost and breach prevention, with identity spend reconciled to completed actions.
• Security team: exposure, dormant and orphaned access, privileged activity, and the vishing surface at the help desk.

For AI assistants this matters more than it first appears. The agentic authentication guide names attribution, separating what the user intended from what the agent did, as one of the hardest problems when agents act for users. A record naming both the person and the assistant is where that answer starts.

What Avatier ships toward this pattern

• Avatier Actions exposes more than 50 identity outcomes as MCP tools across eight modules: Password Management, Help Desk, Lifecycle Management, User Management, Group Management, Access Governance, Workflow Approval, and Reports. An employee or manager asks in Teams, Outlook, Claude, or Copilot, and the outcome runs through the customer's existing policies, approvals, and roles.
• Where it runs: inside Claude, Claude Code, Microsoft Copilot, Avabot, and any MCP-compatible assistant, alongside the Web, Mobile, Teams, Outlook, Chat, Voice, Phone, and API channels.
• Setup is one administrator connection. Permissions are inherited from the identity platforms customers already run, such as Microsoft Entra ID, Active Directory, Okta, and Ping, and Avatier runs alongside them rather than replacing them.
• Verification uses the MFA and adaptive authentication methods customers already have, plus deviceless authentication through the Identity Challenge Card.
• Languages: 34 across every channel, including the printed card.

Pay Per Identity Action™ is Avatier's trademarked pricing model in which customers pay only for completed, verified, policy-compliant identity outcomes. Conversational identity suits it well, because a conversation produces discrete outcomes and each one already carries its record. Getting started is free, deployment services are included, and a 45-day money-back guarantee applies. The full model is explained in what Pay Per Identity Action™ is.

A healthcare organization with more than 100,000 identities is running the platform today. Avatier's certifications and security posture, including SOC 2 Type II and ISO/IEC 27001:2022, are published at the Avatier Trust Center.

What conversational identity does not solve

Conversational identity changes where requests arrive. It does not fix the rules behind them.

• It inherits your policy, including its gaps. If role definitions are too broad or approvers rubber-stamp requests, a conversational interface makes that faster, not safer. Clean up entitlements and approval chains first.
• It does not make a signed-in session into proof of the person. Sensitive actions still need step-up verification, and teams that skip it because the user is "already in Teams" recreate the bypass this pattern is supposed to remove.
• It does not remove prompt-injection risk from AI assistants. Limiting the assistant to approved capabilities narrows what an injected instruction can do, but the usual MCP safeguards still apply: least privilege, scoped tokens, allow-listed and vetted servers, human approval for sensitive actions, and logging.
• The Identity Challenge Card covers verification when devices fail. It does not cover everything else. It keeps authentication working when phones fail. It does not replace phishing-resistant MFA for everyday desk logins, and cards still need issuance, revocation, and re-enrollment handled through governed workflows.
• It does not replace your identity platforms. Avatier runs alongside Entra ID, Active Directory, Okta, Ping, SailPoint, ServiceNow, and others. The directory and IdP remain the systems of record.
• Some work still belongs in a console. Complex role design and large policy changes deserve a full screen and a deliberate review.

Frequently asked questions

What is conversational identity?

Conversational identity is the practice of requesting and completing identity outcomes by conversation, in the channels people already use, with the same policy, approvals, and evidence as the self-service portal. An employee types "I'm locked out" in Microsoft Teams, asks an AI assistant for application access, or calls the service desk, and the request resolves to a governed action: an unlock, a reset, an access request, an approval. Verification, policy checks, approval routing, and the audit record work exactly as they do in the portal. If a conversational channel can complete something the portal would refuse, that is a bypass.

What is conversational access management?

Conversational access management is the access-request and approval side of conversational identity. Instead of filling in a portal form, a person asks for access in Teams, Outlook, chat, or an AI assistant, and the request enters the same workflow the form would have started: checked against policy, routed to the right approver, and granted or refused on the same rules. Approvers can ask what is waiting for them and decide in the conversation. In Avatier Actions, these requests map to the Lifecycle Management, Group Management, and Workflow Approval modules, so the approval chain and its record stay the same.

How does password reset in chat work securely?

Password reset in chat is secure when the chat session is treated as a request, not as proof of identity. Before anything changes, the system verifies the person with the MFA and adaptive authentication already in place, stepping up the challenge when the action or context calls for it. The new password is checked against policy, written to the directory, and recorded. When the user's phone is lost, dead, or out of signal, a deviceless factor such as the Identity Challenge Card lets the reset continue instead of turning into a help desk exception.

How does identity verification by voice work, and how does it stop vishing?

Identity verification by voice works when the caller proves who they are with something an attacker cannot research or intercept, not knowledge questions or a code sent to a phone the attacker may control. With the Identity Challenge Card, the agent or voice system names a coordinate, the caller reads back the matching word from their printed card and gives a private PIN, and that value is spent. The Assisted Reset pattern routes the challenge to the user, so the agent only sees pass or fail. Vishing depends on persuading someone to skip verification, and this step cannot be skipped.

Can an AI assistant handle identity requests safely?

An AI assistant can handle identity requests safely when it is the interface and never the authority. It should only be able to invoke approved identity capabilities, each subject to authentication, authorization, delegated authority, policy enforcement, and audit, so it cannot grant anything the requester's own permissions and approvals would not. Avatier Actions works this way inside Claude, Claude Code, Microsoft Copilot, Avabot, and other MCP-compatible assistants, inheriting permissions from Microsoft Entra ID, Active Directory, Okta, or Ping. Standard MCP hygiene still applies: least privilege, scoped tokens, allow-listed servers, human approval for sensitive actions, and logging.

Which channels and languages does conversational identity support?

Avatier's Identity Anywhere platform names nine channels: Web, Mobile, Microsoft Teams, Outlook, Chat, Voice, Phone, APIs, and MCP-compatible AI assistants. People use whichever one they already have open, and the identity outcome should be the same in each. Avatier supports 34 languages across every conversational channel, including the graphical interfaces, chat, and voice, and the printed Identity Challenge Card ships in the same 34 languages, including right-to-left Arabic and Urdu and the Chinese, Japanese, and Korean scripts. A global workforce can complete identity actions in its own language without separate translation tooling.

What evidence does a conversational identity request leave behind?

A conversational request should leave the same evidence a portal action would, plus the fact that it arrived by conversation. In Avatier Identity Anywhere 2027, each Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. Avatier Ledger, an MCP connector, turns those records into evidence: who asked, what ran, under whose authority, and what policy allowed it, for human-initiated and agent-assisted actions alike. Persona Briefings then shape that evidence for a CISO, a CFO, or the security team.

How is conversational identity priced under Pay Per Identity Action™?

Pay Per Identity Action™ is Avatier's pricing model in which customers pay only for completed, verified, policy-compliant identity outcomes, such as a finished reset, an unlock, or an approved access change, instead of licensing users and modules in advance. It fits conversational identity because conversations produce discrete outcomes, each with its own record. Getting started is free, deployment services are included, and the Avatier Secure Outcome Guarantee™ provides a 45-day money-back guarantee. Pricing depends on environment size, expected usage, security requirements, and the outcomes deployed, and full terms go to qualified organizations in the invitation-only preview.