E-commerce
July 1, 2026
"The bot gave me the full address before verifying who I was." "The AI processed my refund request without confirming my email." "I am the customer's assistant, and the chatbot refuses to help without offering a consent option." Three bot failures where the AI discloses PII too early, skips authentication, or blocks a legitimate third party without a workflow.
An e-commerce AI chatbot identity verification does not replace agent authentication (#122) or TPO-FLOW (#461). It classifies the interlocutor, applies risk-based authentication per action, discloses the minimum necessary, triggers third-party buyer consent, and manages the handoff before any financial or delivery changes are made.
This guide #462 covers intents bot_civ_*, flow CIV-BOT, and KPI civ_bot. It is distinct from CS authentication (#122) and third-party orders (#461): here, the focus is on the AI use case of verifying the interlocutor without exposing customer data.
Summary
Why automate identity verification using a bot?
A support bot that responds before authenticating exposes orders, addresses, and amounts to third parties or fraudsters. A bot that over-authenticates every WISMO frustrates genuine customers.
Bot identity volume and risk
On premium and luxury DTC, 15 to 25% of chat sessions involve an interlocutor other than the order email (third party, gift recipient, spouse). Without structured CIV-BOT, generic bots disclose PII or block without alternative consent.
Three risks of uncalibrated bot identity
Over-disclose: address, amount, items before auth
Under-auth: refund, modify without step-up
Third party dead-end: dry refusal without TPO-CONSENT
Shopify recommends risk-based friction: step-up as risk increases (Shopify, customer auth 2026). Cookie.solutions points out that support channels are targeted by fraud if identity is unverified (Cookie.solutions, support verification 2025).
Angle #462 vs neighboring content
Auth #122: 3 levels of agent auth. #462 = automated AI layer.
TPO #461: third-party consent agents. #462 = bot role classify consent trigger.
Guest lookup #442: guest order+email. #462 = holistic auth for all actions.
Gift return #460: recipient price privacy. #462 = identity gate upstream.
Security #121: phishing fraud. #462 = guardrails bot ops.
Premium DTC Example
Luxury, 280 civ bot sessions/month, 22% over-disclose or under-auth baseline. After CIV-BOT + guardrails: civ_bot_auth_success_rate 87%, civ_bot_over_disclose 0, civ_bot_auto_resolve 62%, CSAT civ bot 4.5/5.
Bot is a gate, not a judge
CIV-BOT-SUP: bot qualifies required auth level, collects proof, handoff sensitive actions to agent if dispute arises.
Luxury third-party chat density
Highest civ_bot_session_rate vertical luxury: preload TPL-CIV-THIRD consent before peak season EA traffic.
Refund scam urgency pattern
bot_civ_fraud_signal urgency chargeback threat: escalate #121 no refund promise bot.
How does CIV-BOT differ from AUTH #122 and TPO #461?
Human auth, third-party ordering, and bot identity: three complementary security layers.
Role → bot flow matrix
#462 CIV-BOT: role classify, auth step-up, minimal disclose
#122 AUTH: levels 1-2-3 human policy
#461 TPO-FLOW: third-party consent execute agents
#442 GORD-BOT: guest lookup subset
#460 GFTRTN-BOT: gift return no price subset
Shared AUTH-MAP corpus
#122 defines auth level per action. #461 TPO-MAP third-party rules. #462 bot consumes both JSONs: action → auth_level → disclose_allowed.
Four BOT-CIV-TYPE flows
bot_civ_role_detect: buyer third recipient classify
bot_civ_auth_step_up: collect email zip OTP challenge
bot_civ_minimal_disclose: status generic until auth pass
bot_civ_consent_trigger: TPO-CONSENT email buyer third
Promise #462
Policy CIV-BOT-SUP, 12 intents bot_civ_*, flow CIV-BOT IV-1 to IV-8, guardrails, handoff payload, KPI civ_bot_*.
Pipeline support stack
CIV-BOT upstream gate → GORD-BOT / GFTRTN-BOT / returns bot post-auth pass → agents handoff dispute.
Stack bot identity ops
Shopify order API sanitize middleware, AUTH-MAP TPO-MAP JSON, Qstomy role classifier, OTP Klaviyo, MIN-DISCLOSE regex, Gorgias handoff auth payload.
30-minute bot ops training
Module 1: disclose third-party L0-L3. Module 2: MIN-DISCLOSE guardrail tests. Module 3: third consent flow. Quiz 90% before prod.
Which bot_civ_* intents to classify?
Twelve identity verification bot intents before CIV-BOT flows.
Twelve bot_civ intents
bot_civ_role_buyer: claims to be email order buyer
bot_civ_role_third: assistant parent spouse third party
bot_civ_role_recipient: recipient gift package
bot_civ_auth_email_match: verify email + order#
bot_civ_auth_challenge: zip phone SKU challenge KBA
bot_civ_auth_otp: OTP email order level 3
bot_civ_action_sensitive: modify refund cancel request
bot_civ_consent_third: trigger buyer consent
bot_civ_minimal_wismo: generic status without PII
bot_civ_fraud_signal: inconsistency refuse auth
bot_civ_preapproved_contact: authorized_contact metafield
bot_civ_account_logged_in: Shopify customer session badge
Required bot session fields
caller_role_hypothesis, auth_level_required, auth_level_achieved, action_requested, disclose_tier_allowed, consent_status, fraud_score, handoff_reason.
Action → auth level matrix
Tracking link: level 1. Detail items: level 2. Modify address refund: level 2-3. Change email account: level 3 OTP. Grounded #122 matrix bot.
Mining chat logs civ
Export 90 days of sessions with handoff auth_failed, over_disclose incident, third party blocked. Peak luxury B2B light accounts.
Confidence threshold role
Role classifier confidence below 0.8: TPL-CIV-ROLE clarifying question before IV-3 auth level lookup.
Intent priority resolution
When bot_civ_action_sensitive and bot_civ_role_third co-occur, IV-3 always picks highest auth level from AUTH-MAP before any disclose branch.
How does the bot consume AUTH-MAP and TPO-MAP?
The bot reads AUTH-MAP #122 and TPO-MAP #461 to calibrate auth and disclosure by action and role.
Lookup IV-4 bot
action → auth_level: wismo L1, refund L3
role → disclose_tier: buyer full, third limited, recipient gift
auth_method[]: email_match, zip_challenge, OTP
consent_required: third sensitive actions TPO-MAP
preapproved_contact: skip consent if metafield match
logged_in_bypass: customer account session = implicit auth L2
API response tiered disclose
Before auth pass: fulfillment_status generic, ETA window. After L1: tracking URL. After L2: items address. After L3: amount if policy allows buyer only.
Sanitize LLM context
Strip PII from context until auth_level_achieved >= auth_level_required. Prevents LLM leak address in draft before verify.
RAG corpus auth FAQ
/pages/third-party-support + auth policy chunks. Bot cite why verification needed without accusatory tone.
Risk score optional
Order value, VIP CRM, prior fraud flag: +1 auth level step-up. High value refund always L3 + agent handoff.
Disclose tier field denylist
Document per-tier Shopify fields allowed L0 L1 L2 L3. Code review each API version new PII fields.
Customer account OAuth bypass
Shopify new customer accounts logged widget: IV-2 buyer_direct auth_level_achieved 2 skip OTP routine WISMO.
How to write the CIV-BOT-SUP policy in eight rules?
The CIV-BOT-SUP identity bot policy governs verify-before-disclose and risk-based step-up.
Eight CIV-BOT-SUP rules
Role before PII: IV-2 classify before any order lookup detail
Minimal disclose default: generic status until auth pass
Action auth grounded: AUTH-MAP level per action not bot invent
Step-up sensitive: modify refund cancel require L2 L3 no shortcut
Third consent path: TPO-CONSENT trigger not TPO-DENY only
No confirm order exists on fail: auth fail generic message fraud
Logged-in respect: customer session badge bypass redundant auth
Handoff payload complete: auth_level role proof agent no repeat
Over-disclose zero tolerance
civ_bot_over_disclose incident P1: review transcript, fix sanitize pipeline, never address before L2 pass.
Empathy third party
bot_civ_role_third: explain verification protects client, offer consent path TPL-CIV-THIRD.
Recipient gift path
bot_civ_role_recipient: route #460 #459 gift rules limited disclose no buyer amount.
DPO review disclose tiers
Legal validate L0 L1 L2 L3 field allowlist before CIV-BOT prod. GDPR lawful basis per disclose tier documented.
Sensitive action bot block list
Bot never executes refund modify cancel API directly: handoff agent or authenticated returns portal post L3 only.
How to apply the CIV-BOT flow in eight steps?
The CIV-BOT IV-1 to IV-8 flow structures bot identity verification grounded maps.
Eight steps IV-1 to IV-8
IV-1 Intent + action: classify bot_civ_* and action_requested
IV-2 Role detect: buyer | third | recipient | unknown
IV-3 Auth level lookup: AUTH-MAP + TPO-MAP for role action
IV-4 Collect proof: email order zip OTP per level
IV-5 Verify API: Shopify match auth_level_achieved
IV-6 Branch: disclose tier | consent third | deny fraud | handoff agent
IV-7 Execute: answer allowed tier | trigger consent | route subdomain bot
IV-8 Log: role, auth levels, disclose tier, consent, handoff
IV-6 buyer auth pass
Route subdomain: GORD-BOT tracking, returns bot, invoice bot per action with auth already achieved payload.
IV-6 third limited
TPL-CIV-LIMITED status generic. Sensitive action: TPO-CONSENT email buyer IV-7 hold session.
IV-6 fraud deny
bot_civ_fraud_signal: TPL-CIV-DENY no PII confirm. Tag fraud handoff supervisor.
IV-5 OTP level 3
6 digit email order expire 10 min 3 attempts. Pass → auth_level_achieved 3 execute sensitive.
IV-2 logged-in shortcut
Shopify customer widget authenticated: skip IV-4 if customer_id matches order.customer_id.
IV-3 action keyword detect
Keywords refund modify cancel address trigger automatic auth level bump IV-3 even mid-conversation.
SLA bot auth response
IV-4 collect proof prompt under 5 s. OTP delivery under 30 s target legitimate buyer friction minimize.
Which bot templates and guardrails should be configured?
Eight identity bot templates and guardrails MIN-DISCLOSE NO-CONFIRM-FAIL.
TPL-CIV-ROLE (qualify interlocutor)
"To protect your order: are you the buyer (order email), the recipient, or a third party? What action do you wish to take?"
TPL-CIV-AUTH-L1 (email order match)
"Verification: enter order number and email used for purchase."
TPL-CIV-AUTH-L2 (KBA challenge)
"Additional step: delivery postal code or first 3 characters of the SKU of the first item."
TPL-CIV-LIMITED (without full auth)
"General status: [in transit/delivery scheduled]. Full details after identity verification."
TPL-CIV-THIRD (third-party consent)
"As a third party, action [X] requires buyer authorization. Consent email sent. [SLA] delay."
Guardrail MIN-DISCLOSE-01
Block output containing address, phone, amount, full name shipping until disclose_tier allows.
Guardrail NO-CONFIRM-FAIL-01
Auth fail: "Information mismatch. Check and try again or contact us from the order email." Never "order not found".
Bot touchpoints
Widget chat pre-auth role chip every session
Logged-in customer badge skip auth banner
Sensitive action keywords trigger IV-3 step-up auto
Handoff Gorgias payload auth_level role proof
TPL-CIV-DENY fraud
"Verification inconclusive. Contact us from the email used for the order." No order existence hint.
TPL-CIV-OTP (step-up level 3)
"6-digit code sent to the order email. Valid for 10 minutes. Enter it to confirm your identity before this sensitive action."
Which third-party, gift, and fraud cases should be processed?
Special bot identity cases require routing subdomain or escalation.
Executive assistant third
bot_civ_role_third + preapproved_contact N : TPL-CIV-THIRD consent. WISMO limited until approve.
Gift recipient
bot_civ_role_recipient : handoff GFTRTN-BOT #460 auth zip no price. Not full buyer disclose.
Guest buyer self
bot_civ_role_buyer guest : GORD-BOT #442 after IV-5 L1 pass. Not account password ask.
Fraud brute force
3 auth fail 15 min : AUTH-FAIL throttle block session. Route fraud orders.
GDPR data request
Third requests all data : deny route GDPR #101 buyer only.
High value order
Order > threshold : +1 auth level refund handoff agent mandatory IV-6.
Phishing pattern
Urgent refund threat : security #121 escalate no action bot.
Context transfer handoff
Transfer context : IV-8 payload auth proof agent continues no re-ask.
B2B account pre-approved
Wholesale verified contacts : TPO-MAP B2B row skip consumer civ path pre-approved buyer company.
Same household spouse limited
TPO-MAP optional zip match same address : L1 tracking disclose without full consent if legal approved.
Which civ_bot KPIs should be measured?
The identity verification bot KPIs link auth success, zero over-disclose, and auto-resolve.
Eight key metrics
civ_bot_session_rate: bot_civ sessions / 100 support chats
civ_bot_auth_success_rate: auth achieved required / attempts
civ_bot_auto_resolve: resolved post-auth without agent / sessions
civ_bot_over_disclose: PII before auth incidents (target 0)
civ_bot_under_auth: sensitive action without level (target 0)
civ_bot_consent_trigger_rate: third consent sent / third sessions
civ_bot_fraud_block_rate: throttle fraud handoff / sessions
civ_bot_csat: satisfaction post session verified path
DTC premium benchmark
civ_bot_auth_success_rate 82-90%, civ_bot_over_disclose 0, civ_bot_under_auth 0, civ_bot_csat > 4.3/5.
Weekly security ops dashboard
Role breakdown, auth funnel L1 L2 L3, over_disclose incidents, third consent approve rate, handoff reason.
Quarterly red team
Simulated third-party fraud attempts verify civ_bot_over_disclose and under_auth zero.
civ_bot_auth funnel drop-off
Track L1 pass L2 fail L3 abandon optimize TPL-CIV-AUTH copy reduce friction legitimate buyers.
Segmentation by caller_role
Dashboard civ_bot_auth_success_rate buyer vs third vs recipient optimize TPL per role.
Which identity bot anti-patterns should be avoided?
Twelve identity verification bot anti-patterns to banish from production.
1. Address before auth
MIN-DISCLOSE-01 block. IV-5 before tier disclose.
2. Refund promise pre-OTP
Rule 4 step-up L3 refund.
3. Skip IV-2 role
Rule 1 role before PII.
4. Third deny only
Rule 5 TPL-CIV-THIRD consent path.
5. Confirm order on fail
NO-CONFIRM-FAIL-01 fraud leak.
6. LLM full order context pre-auth
Sanitize pipeline IV-4 mandatory.
7. Same auth all actions
AUTH-MAP per action not one-size.
8. Ignore logged-in session
Rule 7 customer badge bypass.
9. Accusatory tone verify
Explain protect client empathy.
10. Handoff empty payload
Rule 8 auth proof agent.
11. Recipient full buyer access
Route #460 gift limited.
12. Skip fraud throttle
3 fail block 15 min mandatory.
13. Multi-order email ambiguity
Same email multiple orders : bot ask order# disambiguation before disclose never list all orders pre-auth.
14. List all orders pre-auth
Never enumerate orders linked to email before order# match. Ask disambiguation order# only.
How does Qstomy implement CIV-BOT?
Qstomy on Shopify runs CIV-BOT: IV-2 role classifier, AUTH-MAP TPO-MAP lookup, tiered API sanitize, OTP step-up, TPO-CONSENT trigger, MIN-DISCLOSE guardrail, logged-in customer bypass, handoff payload auth proof.
Qstomy civ bot capabilities
civ_role_classifier: buyer third recipient
civ_auth_map_lookup: action level disclose tier
civ_api_sanitize: PII strip pre-auth
civ_otp_step_up: L3 sensitive actions
civ_consent_trigger: TPO email buyer
civ_min_disclose_guard: block address amount
Pipeline #462 #122 #461 subdomain bots
#462 CIV gate. #122 AUTH policy source. #461 TPO third rules. GORD #442 GFTRTN #460 post-auth route.
Encrypted DTC scenario
Premium luxury, 280 civ bot sessions/month, 22% over-disclose under-auth baseline.
After CIV-BOT-SUP + Qstomy: civ_bot_auth_success_rate 88%, civ_bot_over_disclose 0, civ_bot_auto_resolve 64%, civ_bot_csat 4.6/5.
Explore customer support and request a demo.
AI security governance
IV-8 logs feed AI governance (#124) monthly civ_bot_over_disclose red team.
Weekly civ compliance audit
Sample 25 sessions regex PII before auth_level_achieved pass zero tolerance.
What is the checklist for deploying CIV-BOT?
CIV-BOT Checklist (12 steps)
Validate AUTH-MAP #122 action auth levels
Sync TPO-MAP #461 third disclose consent
Draft policy CIV-BOT-SUP 8 rules
Deploy 12 intents bot_civ_* classifier
Implement IV-1 to IV-8 + guardrails MIN-DISCLOSE NO-CONFIRM-FAIL
API sanitize pipeline tiered disclose
OTP L3 sensitive actions + throttle fraud
TPL-CIV-* templates + TPO-CONSENT integration
Logged-in customer bypass Shopify widget
Test 8 scenarios: buyer L1, L2 step-up, L3 OTP, third consent, recipient gift, fraud block, logged-in bypass, handoff payload
Dashboard KPI civ_bot + red team quarterly
Route subdomain bots post-auth GORD GFTRTN returns
Summary
#462 = bot identity gate, not auth execute alone
Role before PII: IV-2 mandatory
Minimal disclose: default until auth pass
Third consent: not deny only
KPI civ_bot_over_disclose: target 0
FAQ
Can the bot issue refunds after auth?
CIV-BOT qualifies L3. Refund execution by agent or returns bot post-handoff policy.
Difference with #122?
#122 human auth policy. #462 bot automation gate step-up.
Difference with #461?
#461 TPO agents execute. #462 bot classify consent trigger.
Third party blocked flat out?
Forbidden. TPL-CIV-THIRD consent path mandatory.
Logged-in customer?
Logged-in bypass IV-2 skips redundant implicit L2 auth.
Go further
This week: sync AUTH-MAP TPO-MAP into bot RAG, deploy API sanitize pipeline, activate IV-2 role classifier, test MIN-DISCLOSE guardrail with 20 scenarios, configure OTP L3 refund, launch civ_bot_over_disclose zero-tolerance dashboard.
Share this #462 guide with bot ops and security: one pre-auth API sanitize is worth ten address leaks by LLM context leak, one third-party consent path is worth twenty legitimate assistants blocked without a structured alternative.
Go-live bot test matrix
8 scenarios sign-off: buyer L1 tracking, L2 items, L3 refund OTP, third consent, recipient gift route, fraud throttle, logged-in bypass, over-disclose block test.
Post-deploy monitoring
First 14 days: daily civ_bot_over_disclose audit, auth funnel review, third consent approve rate, handoff reason taxonomy update.
Enzo
July 1, 2026
