Identity and Verification overview
The identity layer governs when the assistant is willing to call a tool on a caller’s behalf. Every tool is gated against one of three discrete assurance levels; until the caller has satisfied that level, the tool returns a typed deny decision and the assistant explains the situation in plain language.
This document describes the architecture for integrators evaluating the platform’s compliance and integration model. Operator-facing guidance lives on the help site under “Identity and Verification”.
Three assurance levels
Section titled “Three assurance levels”| Level | Meaning |
|---|---|
anonymous | No identification. oHallo knows the inbound channel but has not linked the caller to a contact. |
identified | One verification factor minted: the caller pressed the button on the page a one-time email link opens, called from the number on file or wrote from the address on file on a channel whose Caller ID or email sender address is set to “Identifies the customer”, or completed an eID verification. The default for tools that return personal data or change state. |
high-assurance | A completed national eID verification. The default for destructive or financially material tools. |
A tool’s risk classification supplies its default level, and an administrator sets a tool’s level above or below that default on the dashboard.
A national eID verification is the one method that reaches the strongest level. MitID and BankID are government-issued, scheme-proofed identities, so a single eid_verified factor (possession category) reaches high-assurance alone. The email link proves control of a mailbox and reaches identified; Caller ID and the email sender address corroborate and never compose toward high-assurance. The caller approves in their own scheme app, or follows a record-bound verification link, and the approval is bound to the caller’s record in the account’s own system through the designated identifier fields described on Returning a national identity number. Danish MitID verifies callers; which schemes a workspace can offer is derived from its own configuration and shown in the workspace’s National eID settings.
A tool declared to return a customer’s own records opens only for a caller tied to that record in the account’s own system. A national eID verification writes the tie wherever it runs: on calls, by email and in chat. On a tool set to identified, a caller who asks to see is also tied where national eID does not start: by the email link, sent to the address the customer’s own record holds and tied when its button is pressed (on email, only on email channels set up to receive mail directly); on an email channel that receives mail directly and whose email sender address is set to “Identifies the customer”, by a confirmed sender address that record holds; and on a voice channel whose Caller ID is set to “Identifies the customer”, by a call from the number on that record. A change on such a tool, and every such tool at high-assurance, needs a national eID verification. The fields each reads are described on The customer lookup contract.
Cross-channel by design
Section titled “Cross-channel by design”Identity is not a voice-only concept. The same three levels, the same factor types, and the same audit vocabulary apply on every channel (voice, email, chat). The configuration surface is single: an account that attaches a lookup tool in its workspace settings sees that tool used by the verification specialist regardless of which channel the caller chose.
The implementation is split across three layers:
- Shared identity rules, which the verification service and every channel apply, so each records identical factors, identity events and assurance levels: how a factor is recorded, the NIST §5.3.2 order in which data sources are asked about, how a verification link is signed, the wording of a refusal, and how the assurance level follows from the factors held.
- A central verification specialist definition that provides the system prompt, tools, and rejection templates. Operators override these per workspace.
- Per-channel execution: the voice runtime for calls, a two-message flow for email, and websocket frames for the chat widget. Each channel resolves a token bundle from the central definition plus the identity-runtime helpers and runs the same state machine.
Standards adherence
Section titled “Standards adherence”The platform cites a discrete set of standards in the operator-facing compliance posture. A summary of how each one is satisfied:
| Standard | Implementation |
|---|---|
| NIST SP 800-63B §5.1.3 (OOB authenticator principles) | A signed one-time email link, sent to the address on the caller’s record, is the possession factor. |
| NIST SP 800-63B §5.2.10 (PSTN OOB restricted) | Caller ID counts only on a voice channel set to “Identifies the customer”, where a call from the number on the customer’s record reaches identified and never composes toward high-assurance. |
| GDPR Art. 12(2) (proportionate verification) | Tool calls returning personal data require identified assurance. Configurable below default with explicit operator action. |
| GDPR Art. 5(1)(e) (storage limitation) | Daily retention sweep deletes identity-events older than the workspace’s identity_events_retention_months (default 24, range 3 to 84, platform max 84). |
| GDPR Art. 17 (right to erasure) | Erasure endpoint at conversation-svc; logged in identity_event_purges. |
| ATIS-1000074 / RFC 8588 (STIR/SHAKEN) | The telephony adapter reads the attestation level, and the verification service records it with the caller ID factor. |
| ISO/IEC 27018 (PII in public cloud) | Identity events are encrypted at rest, segregated per account, and subject to the retention and erasure surface above. |
Where integration happens
Section titled “Where integration happens”Verification is configured by operators, not authored in code and not improvised by the assistant. Configuration lives in two operator-facing surfaces:
- The workspace Identity and Verification settings panel. No API call is required to configure it.
- The MCP hub per-tool assurance control on the connection detail page.
An operator attaches business lookup tools as verification data sources; the platform runs a deterministic verification specialist against that configuration on every channel.
The one integration surface that involves your code is the customer lookup: a tool of yours that answers “who is this person” from an email address or a phone number and returns your own customer reference. It runs first on every inbound message, and everything above builds on it. The contract is on The customer lookup contract. When a workspace offers eID verification, the same tool’s answer also carries the identifier the scheme keys on; that half of the contract is on Returning a national identity number.
Identity events
Section titled “Identity events”Every identity transition writes a row to the platform’s identity-event log. Each conversation’s events are available through GET /api/conversations/:id/identity-events (scope conversations:read), which an integration can poll to mirror events to a security information and event management (SIEM) system. The field-level schema is documented on the Identity event schema page. The workspace-level identity-event view is an operator dashboard surface and is not part of the API-key interface.