Identity and Verification overview

The identity layer governs when the AI 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 AI 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

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 + possession is the canonical combination in v1.

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: a tenant who attaches a lookup tool in their workspace settings sees that tool used by the verification specialist regardless of which channel the caller chose.

The implementation is split across three layers:

1. 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 Python mirror under voice-runtime-svc re-implements the same shapes so the audio runtime can run them in-process.
2. A central agent definition (system_verification in agent_definitions) that defines the verification specialist’s system prompt, tools, and rejection templates. Tenants override these per workspace.
3. Per-channel execution: Pipecat for voice, two-message email flow for inbound-svc, websocket frames for the chat-widget. Each channel resolves a token bundle from the central agent definition + identity-runtime helpers and runs the same state machine.

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. Tenants 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 (forthcoming via the Verification Federation API v1.1+); v1 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, tenant range 3-84, platform max 84).
GDPR Art. 17 (right to erasure)	DELETE endpoint at conversation-svc; logged in identity_event_purges.
ATIS-1000074 / RFC 8588 (STIR/SHAKEN)	Telnyx adapter extracts attestation level; persisted as a risk_signal for audit.
ISO/IEC 27018 (PII in public cloud)	Identity events are encrypted at rest, segregated per tenant, and subject to the retention + erasure surface above.

The full standards reference is in the internal architecture docs at docs/identity/03-standards-reference.md.

Where tenants integrate

Integration on the tenant side is via three surfaces:

• The workspace’s Identity & Verification dashboard panel — operator-facing, no API call required to configure.
• The MCP Hub Tools table per-tool assurance dropdown — operator-facing, in the existing connection-detail page.
• The /api/workspaces/:id/verification-config REST endpoint — programmatic configuration via the API; mirror of the dashboard panel.

The identity layer itself is a platform-internal concern; tenants do not author verification specialists or KBV questions directly. The LLM does that work from the tools the tenant attached.

Identity event schema

Every identity transition writes a row to the identity_events table at conversation-svc. The wire schema is in services/conversation-svc/src/db/schema.ts and the corresponding TypeScript type is at packages/api-types/src/audit.ts (AuditIdentityEvent).

Tenants who mirror their audit log to a SIEM can poll GET /api/workspaces/:id/identity-events?from=&to=&type=&contact=&limit= and consume the events stream. The endpoint is dual-auth (Kinde or API key) but currently undocumented in the public API; documentation lands when the cross-channel cutover ships.

Verification Federation API (v2)

The platform is designed to support upstream identity providers (banks, telcos, government eID) that the tenant has independently integrated with. A tenant can mint a federation token via a v2 endpoint and present it to the platform; the platform validates the token signature against the tenant-configured trust anchor and mints the corresponding factor without running KBV. This is the strict-conformance path for NIST §5.1.3 (pre-enrolled authenticators).

v2 is not in v1 of the rework but the API contract is fixed; see the next page in this section for the contract.