Identity Verification

A session that mentions a known visitor's email or phone shouldn't automatically get full access to that visitor's history — otherwise anyone who guesses someone's email could harvest their prior conversations. The Identity Graph splits "claimed" from "verified" so the AI agent only sees cross-session context when we're confident this is really the same human on the same device.

Trust levels

Every session has an identity_trust level:

Level	What the AI sees
anonymous	Nothing — no identity has been claimed or verified.
claimed	Visitor's name and email/phone are surfaced, plus everything that happened in this session. No cross-session history.
verified	Full Identity Graph — past conversations, CRM context, extracted facts, mirrored bookings, behavioural signals across sessions.

Within a single session, anything the visitor shares in that session is always available to the AI in that session. Verification only gates cross-session reach.

Direct triggers (instant verify)

Nine direct triggers will immediately verify a session, regardless of policy:

1. First Person Profile — the visitor is being identified to your tenant for the very first time. There's no prior data to gate, so the first identifying session establishes the baseline and is treated as verified.
2. First-party form on your site — a form submission picked up by the website form intercept. Submitted on your domain by the visitor's actual browser, so it's as trustworthy as a form fill.
3. Pre-chat form in the widget — the visitor fills in the widget's pre-chat form before starting a conversation. The details they typed verify their identity on the spot.
4. Completed booking — the visitor books a meeting through the widget's booking flow. Completing the booking auto-verifies their identity.
5. CRM-tracked landing — visitor arrives carrying a HubSpot hubspotutk cookie (only after cookie consent) for a contact HubSpot already knows. The widget detects it at session bootstrap.
6. Tracked email link click — the visitor clicks their own personal ?kk= link from an email (Agent K, your CRM, or an email campaign). Bot and link-scanner clicks are filtered out. Because an email can be forwarded, the visitor's own form, chat details, or booking still override this identity.
7. Returning known device — the same browser session identifier is already on this visitor's verified set.
8. Inbound voice call — the inbound caller-ID matches a known phone for this visitor, and your tenant has caller-ID verification enabled.
9. Details shared in conversation — the visitor gives their name and email or phone in a chat conversation or on a call with your agent. Introducing yourself to the agent is treated like filling in the pre-chat form, so the details verify on the spot. (This covers details the visitor states themselves — identity merely extracted or guessed from a transcript by AI or enrichment stays an unverified claim.)

note

The pre-chat form only shows once per browser. After the visitor fills it in, their saved identity is re-asserted automatically on their next visits from that browser — so the AI can greet returning visitors by name across sessions without asking them to introduce themselves again.

Score-based verification

If no direct trigger fires but the session still claims an identifier, the verifier scores the session against the visitor's previously-collected signals:

Signal	Points
Same browser as a verified session	+100
FingerprintJS hash matches	+60
Soft browser signature matches	+25
Exact IP match within last 30 days	+20
/24 IP subnet match within last 30 days	+10
Email already known on this profile	+15
Phone already known on this profile	+15

The total score is compared against the policy threshold (below). If it clears the bar, the session is auto-verified and the audit log records why.

Recognition without re-identifying

A returning visitor doesn't have to type anything to be recognised. When a new visit arrives, the Identity Graph checks it against people who have verified before:

• Same browser — the widget remembers the browser the visitor used on your site before.
• Same device — the device fingerprint matches exactly one verified person, verified within the last 90 days. This works across every Knock Knock site, so a visitor verified on another site is recognised on yours.
• Same network — the visitor's public IP belongs to exactly one verified person, seen within the last 90 days. Shared networks are never used: VPNs, data centres, mobile carriers, and any IP that has carried many different devices recently (public Wi-Fi, office networks). Visitors from the EEA, UK, or Switzerland are never matched by IP while GDPR Protection is on.

A recognised visit starts as claimed: the visitor shows with the known name and the amber suspected-identity icon, and the AI doesn't greet them by it. The recognising signals are then scored against what your site already knows about that person, at the Strict threshold (80) whatever your policy — only Regulated switches this off. If they clear it (for example, the same device on the same home network), the visit becomes verified with full history, and the new network is added to the person's profile so future visits are recognised too. A device or network alone never clears the bar.

If a recognised visitor then identifies as someone else — they fill in a form or give their details in chat — their own details win. The wrong match is withdrawn, the shared device or network stops pointing at the other person on every site, and other visits that were matched to the wrong person the same way go back to anonymous. That device or network isn't used to recognise anyone for the next 90 days, so a shared family laptop stops switching between people. If a recognised visitor fills in a form with their own details, that confirms and verifies the match.

Per-tenant verification policy

Set by the super admin (see Admin Controls) — globally for every tenant, or as a per-company override:

Policy	Threshold	Right for
Permissive	Any claim verifies	Lowest friction; legacy behaviour. Default for existing tenants.
Moderate	Score ≥ 60	Recommended balance — returning visitors on the same Wi-Fi / same browser typically pass.
Strict	Score ≥ 80	New tenants by default. Requires multiple corroborating signals or a direct trigger.
Regulated	Direct triggers only	Healthcare / finance / regulated industries — score-based path is disabled entirely.

Inbound caller-ID verification can be toggled separately under the same screen. Off by default for tenants where caller-ID spoofing is a concern.

Conflicting claims

If a session is already verified for one Person and the visitor types another Person's email or phone (e.g. an attacker, or a co-worker on a shared device), the new claim is rejected:

• The session keeps its existing verified identity.
• The conflicting claim is recorded as an audit event on the second Person's profile (Conflict — session was already verified for <other-person-id>).
• The AI prompt remains unchanged; the typed identifier is in the chat history but no second Person's profile is exposed.

The one exception is a session verified only by recognition or a tracked email link: the visitor never told you who they were, so details they give themselves replace the recognised identity instead of being rejected.

You can review these on the per-Person Profile Identity Audit tab. The Person Profile card on the parent Person screen also shows an amber warning when any conflicting claims exist.

What this means for AI replies

• Returning verified visitor — AI greets them by name, references prior conversations and bookings, knows their CRM stage.
• Returning visitor recognised by device or network only — the session shows who they probably are, but the AI treats it as a fresh interaction unless the signals are strong enough to verify on their own (see Recognition without re-identifying). They can re-verify the next time they fill a form / share their details in a conversation / arrive via a CRM-tracked link or their own tracked email link / call from a known number.
• First-time visitor — AI sees only the current session's data: page they're on, traffic source, anything they've typed.
• Session already verified as someone else — typing another person's email or phone doesn't flip the session; the conflicting claim is rejected and audited (see above).