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. The platform knows the inbound channel but has not linked the caller to a contact. |
identified | One verification factor minted. The caller has answered KBV correctly OR proven possession of an email on file. Platform floor for tools returning personal data. |
high-assurance | Two factors from different PSD2 categories. Platform floor for destructive or financially material tools. |
The mapping from level to factor count and category follows PSD2 SCA Article 4 (Commission Delegated Regulation (EU) 2018/389): two factors of different categories satisfy the strongest assurance. Knowledge plus possession is the canonical combination in the current release.
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:
- A shared pure-helpers package,
@standfast/identity-runtime, containing factor constructors, lockout-counter math, NIST §5.3.2 preference ordering, magic-link token signing, rejection-language templates, and the assurance derivation rule. A mirror in the voice runtime re-implements the same shapes so the audio runtime can run them in process. - 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-63-3 §5.3.2 (KBV procedure) | 4 questions, all-correct pass rule, 3-attempt cap by default. Operators can deviate; the posture footer marks the row “Aligned with” instead of “Follows.” |
| NIST SP 800-63B §5.1.3 (OOB authenticator principles) | Email magic-link possession factor. Strict §5.1.3 conformance requires pre-enrolled authenticators; the current release ships a signed email link. |
| NIST SP 800-63B §5.2.10 (PSTN OOB restricted) | SHAKEN-A/B attestation paired with KBV by default; standalone caller-ID identification is supported but flagged. |
| NIST SP 800-63B §5.2.2 (rate limiting) | Per-call 3-wrong cap, per-identity 5/24h cap, per-ANI 3-identities/24h. |
| PSD2 SCA Art. 97 (factor categories) | Adopted as vocabulary. Two factors from different categories satisfy high-assurance. NOT claimed as conformance for non-payment workflows. |
| GDPR Art. 12(2) (proportionate verification) | Tool calls returning personal data require identified assurance. Configurable below default with explicit operator action (flagged in posture). |
| 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 extracts the attestation level; persisted as a risk_signal for audit. |
| 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.
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.