Live Chat Security: 7 Things to Lock Down Before Your Inbox Goes Live

Live chat is one of the highest-trust channels you operate. A visitor types a question that often includes their email, their order number, sometimes their address, occasionally a bank-statement screenshot, and trusts that the agent on the other end is the right person and that the transcript is not exposed. The default settings on most live chat tools were not written with that in mind. They were written for a Stripe-style demo flow that never sees a real customer.

This is the live chat security checklist we hand to teams running Deskwoot, broken into the seven decisions that actually matter. Most of it is the security baseline on every Deskwoot plan, including the free Hacker tier (encryption in transit, EU hosting, 2FA, the DPA and the GDPR request tools), so a team starting from zero does not have to hand-configure anything before going to production. Where a control needs a paid plan, we say so.

1. Encrypt the channel and the storage

This is the table-stakes layer. Every live chat tool that calls itself secure should ship with TLS 1.2 or higher on every endpoint that visitors and agents touch, and AES-256 at rest for every message persisted to disk. The two questions worth asking your vendor:

• Is the widget served from your origin or a vendor CDN? If your widget script lives on a third-party CDN that does not pin TLS 1.3 or that ships with a permissive CSP, you have a defense-in-depth gap on your own page. Deskwoot's widget is a short script snippet that loads over HTTPS (TLS) from Deskwoot's own domain and runs inside its own iframe, and the agent dashboard sends HSTS plus a Content Security Policy with an explicit allowlist of the hosts the browser may load from or connect to.
• Are message attachments encrypted at rest? Some vendors encrypt the message body and skip the attachment bucket. The attachment bucket is where customers upload screenshots of refunds, ID documents, and bank statements. Deskwoot stores attachments in Cloudflare R2 under EU jurisdiction, where Cloudflare encrypts every object at rest, and hands them out only through access-checked links: a signed-in agent session or a short-lived signed URL, never a public one.

2. Verify the customer before you reveal anything sensitive

The most common live chat security failure is not a hack. It is an agent answering "Where is order #4821 shipping to?" without verifying the person on the other end. That answer is private data. Most live chat tools have no built-in verification flow, so the agent improvises (or skips it).

Deskwoot's AI bot Fynn (included from the Startup plan) ships a 4-tier verification model that is enforced before any private detail leaves the conversation:

• Tier 0: Public questions. "Do you ship to Portugal?" gets answered immediately. No verification.
• Tier 1: Order-number plus postal-code check. "Where is order #4821?" requires the visitor to give the order number and the shipping postal code before Fynn shares the status or tracking. Mismatch and the bot shares nothing about the order.
• Tier 2: Magic-link email verification. Sensitive history requests trigger a one-time magic link to the email on file. The visitor clicks, comes back verified for the rest of the conversation.
• Tier 3: Mutations. Refunds, cancellations, address changes. Fynn proposes the action and asks the visitor to reply "confirm" before issuing the API call. These actions are off by default and switched on per workspace. No accidental refunds from a wrongly worded question.

Verification is also worth wiring into the agent flow itself: a visible "verified" pill in the conversation sidebar so the human agent knows who they are talking to.

3. Pick where your data lives

EU-regulated teams cannot run live chat on a US-only stack and call themselves GDPR-compliant. Even US-based teams selling into the EU have data-residency obligations. This is where most vendor due diligence falls apart, because the marketing page says "GDPR" but the small-print Data Processing Agreement still routes through us-east-1.

Deskwoot's primary infrastructure runs in europe-west4 (Netherlands). Customer messages, agent accounts, attachments, and audit logs all stay in the EU by default. The free Hacker plan does not exclude EU hosting; you do not have to pay extra to keep your support data on EU soil.

Two specific things to verify with any live chat vendor:

• Where exactly does the production database live? "EU" is not specific enough. Ask for the cloud region (eu-west-1, europe-west4, etc.) and which provider it sits on.
• Do the AI/LLM calls leave the region? Many "EU-hosted" platforms route AI inference through a US OpenAI endpoint and quietly violate their own claim. Deskwoot sends AI requests directly to Anthropic, and Anthropic is listed with its purpose and region in Annex B of Deskwoot's DPA, so you can check the AI route the same way you check the database.

4. Lock down agent access

The chat is encrypted, the customer is verified, the data lives in the right region, and your senior engineer Dave can still see every conversation in every account because the live chat tool ships with one role: admin. That is the second-most-common failure mode.

A secure live chat needs role-based agent permissions:

• Restricted scope: agents only see conversations assigned to them. Useful for outsourced support pools where you do not want every contractor reading every customer's history.
• Inbox-scoped: agents only see conversations from a specific inbox. The billing team sees billing tickets, support sees product tickets, neither overlaps.
• SSO + 2FA: agent accounts gated by your identity provider (Google Workspace, Microsoft Entra, Okta) plus a second factor. Deskwoot does not offer SSO. Every plan includes 2FA with an authenticator app, and on Enterprise an admin can require it for every member.
• Audit log retention: every login, every conversation view, every refund issued, who did it and when. Investigatable after the fact instead of a black box.

Pair the audit log with a Slack or webhook alert on the actions that matter (account-export, mass-delete, agent-impersonation) and the team finds out about a misuse the same minute it happens, not in a post-mortem six weeks later.

5. Set a real data-retention policy

Most live chat platforms default to "keep everything forever" because storage is cheap and they do not want to argue about compliance. Forever is the wrong setting. The right setting is "long enough to support the customer, short enough to limit blast radius if a breach happens."

Here is how Deskwoot handles it:

• Conversation history: the visible history follows the plan: 30 days on Hacker, 6 months on Startup, 1 year on Business, unlimited on Enterprise. Older conversations are hidden, not deleted, and come back after an upgrade.
• Attachments: deleted automatically after 365 days, independently of the message body, except on Enterprise, where they are kept.
• Visitor PII: right-to-erasure flow (GDPR Art. 17) wired through the dashboard on every plan. Find the contact by email, see exactly what the erasure will remove, confirm by typing the email address again, and the data is gone right away. The erasure is audit-logged so you can prove the request was honored.

6. Make the widget itself defensive

The customer-facing widget is the layer attackers actually touch. A few things to insist on:

• SRI on the widget script. Subresource Integrity hashes pin the script to a known SHA-384 so a CDN compromise can not silently swap it for malicious JS.
• No inline JS injection from the chat content. If an agent pastes "<img src=x onerror=alert(1)>" into a reply, the widget should sanitize it before rendering. Deskwoot uses sanitize-html on every outbound reply with a strict allowlist (no scripts, no on*-handlers, no javascript: URIs).
• CSP-clean on the agent dashboard. The dashboard side runs with default-src 'self' plus an explicit allowlist of the services the browser may connect to. AI providers are not on that list at all, because every AI call runs on the server. A compromised vendor JS file should not be able to call out to an attacker server.
• Origin-pinned cookies. Session cookies are SameSite=Lax on the agent dashboard, and every state-changing request must pass an Origin check, so a malicious page can not CSRF an agent into resolving conversations or issuing refunds.

7. Run the security review on day one (with a free plan)

The trap most teams fall into: they pick a live chat vendor for a 14-day demo, ship it to production, then realize three months later that the security configuration is not what their CISO needs. By then the migration cost feels too high to fix.

The cheapest way to dodge this trap is to evaluate a live chat tool on a free plan that already includes the security defaults you would otherwise pay for. Deskwoot's Hacker plan is free for one agent and runs on the same encryption, EU hosting, 2FA, DPA and GDPR request tools as every paid tier. The paid tiers add agent seats, the AI bot with its customer verification, longer history and, on Enterprise, audit logs, custom roles and enforced 2FA.

Concretely:

• Free Hacker plan covers one agent, 100 conversations a month, AI Copilot with 10 AI conversations a month, EU hosting, 2FA, the DPA and GDPR requests.
• Startup ($4 per agent per month, $3.20 billed annually) adds more agents, the AI bot Fynn with customer verification, automation rules, 1,000 conversations and 50 AI conversations a month, 6 months of history.
• Business ($8, $6.40 billed annually) adds teams, CSAT, translation, unlimited conversations, 100 AI conversations a month, 1 year of history.
• Enterprise ($12, $9.60 billed annually) adds audit logs, custom roles, enforced 2FA, SLA policies, API tokens, 300 AI conversations a month and unlimited history.

That structure lets a security team do the actual review on real data with real workflows on day one, instead of guessing from sales decks.

The 30-second version

If you are evaluating live chat tools right now and only have time for a quick gut check, run these seven questions against any vendor:

1. Is the widget served over TLS 1.2+ with SRI on the script tag?
2. Is there a built-in customer verification flow that gates private data?
3. Where does the production database physically live? Same answer for AI inference?
4. Does the platform ship role-based agent permissions, SSO, and a real audit log?
5. Are data-retention windows configurable per inbox and per conversation type?
6. Does the widget sanitize chat content and run a CSP-clean dashboard?
7. Can you actually evaluate the security baseline on a free tier before committing budget?

Deskwoot answers yes on most of them, with three honest gaps: the widget snippet has no SRI hash, there is no SSO, and the history window follows the plan instead of a setting per inbox. Customer verification comes with the AI bot from Startup, audit logs and custom roles with Enterprise. Start the 7-day trial (Enterprise, no card, 1 seat) to review the full security setup on real data, or jump straight to the pricing page for the per-tier breakdown. The features page covers the rest of what is in the platform; this post is the security-specific cut of it.

FAQ: secure live chat questions we hear most

Is private live chat the same as encrypted live chat? They overlap but they are not the same. "Encrypted" usually refers to the transport (TLS) and storage (AES). "Private" implies that the conversation is not used to train external AI models, not visible to the vendor's support team without a written agreement, and not retained beyond your stated policy. Deskwoot encrypts every connection with TLS, additionally encrypts stored credentials, tokens and secrets with AES-256-GCM, and conversation content sent to the AI provider is used to answer, not to train models.

Do we still need a Data Processing Agreement (DPA) on the free plan? Yes, and Deskwoot ships one self-serve. Free Hacker users accept the DPA under Settings > Compliance > Data Processing Agreement and get the PDF by email, without a sales call.

What is the right retention setting? Default to 12 months, drop to 30 days for any inbox that handles ID documents, payment screenshots, or PHI. And make sure GDPR Art. 17 erasure requests can be handled from the dashboard instead of a ticket to your vendor.

Can the widget run on a Shopify store without breaking the storefront's CSP? Yes. The widget loads asynchronously and runs inside its own iframe, so it does not touch the storefront's own scripts. See the Shopify customer support guide for the install pattern.

Does the AI bot read previous conversations to answer the next one? Only within the same conversation thread, and account data only after passing the appropriate verification tier. Fynn has no memory across conversations.

Is live chat safe for customers to use in 2026?

Live chat is safe for customers when the platform handles 4 things: TLS 1.2 or higher encryption for every message in transit, AES-256 encryption at rest in the platform's database, no third-party scripts inside the widget that could harvest typed input, and clear data retention policies that delete messages after a defined period.

Most reputable live chat platforms in 2026 meet these defaults out of the box. Customers can verify by checking the platform's security page (look for SOC 2 Type II, GDPR DPA, and encryption at rest claims) and by inspecting the widget script for unexpected third-party trackers (open browser DevTools, watch the network tab). Deskwoot describes its setup on its security page: TLS (HTTPS) on every connection, AES-256-GCM for stored credentials and tokens, and no third-party scripts inside the widget.

Can live chat agents see what you are typing before you send?

Some live chat platforms allow agents to see what the customer is typing before the customer hits send (called "sneak peek" or "typing preview"). Major platforms that offer it: LiveChat.com, Intercom, and Zendesk Chat. Smaller and privacy-focused platforms typically do not implement it.

Deskwoot deliberately does not ship typing preview. The reason is twofold: customers have a reasonable privacy expectation that text they have not sent is not yet visible to anyone, and the productivity gain for agents is marginal (typing previews save 1 to 3 seconds per reply at most). The trade-off is small, but the privacy posture matters when a customer is typing sensitive info like an order number, account ID, or worse, an unredacted payment detail before catching themselves and rewriting.