Screen-Sharing Privacy for Customer Support: Protect Customer Data on Support Calls

When a support or success agent shares their screen — to walk a customer through their account, co-browse a settings page, or show a fix in Zendesk or Intercom — the same console also exposes other customers in the queue, internal notes, and payment data that were never meant for this call. The safeguard is to blur everything except the one account you're helping before you share, so a stray scroll, a ticket list, or an admin lookup can't leak another customer's data. Your tool's own permissions won't do this: on a screen share, the customer sees whatever *you* can see.

What customer data leaks during a support screen share

• Other customers in the queue — the ticket list, saved views, and search results in Zendesk or Intercom name people you're not helping, along with their subject lines and status.
• Contact PII on the current ticket — the requester's name, email, phone number and account or organization ID, sitting in the sidebar of the record you *are* discussing.
• Payment and billing data — card last-four, plan, invoices, refund history and MRR shown in a billing tab or an embedded Stripe panel.
• Internal notes and macros — private comments, tags, escalation notes, sentiment flags and internal knowledge-base snippets written for staff, not for the customer to read.
• **Admin-panel data of *other* customers** — an internal admin or back-office tool where searching one account surfaces adjacent accounts, feature flags, impersonation links or org-wide metrics.

How to present one customer's account without exposing the rest

1. 1

   Share a single window or tab

   Present only the browser window with Zendesk, Intercom or Service Cloud open — keep Slack, your email and other tabs out of frame entirely.

2. 2

   Box-blur the queue and navigation

   With BlurFirst, drag a box over the ticket list, the views sidebar and the global search bar so other customers never appear as you move around. The box stays anchored as you scroll.

3. 3

   Element-blur PII, billing and internal notes

   Click the requester's email, phone, account ID, the card-on-file field or an internal note to frost just that element — the rest of the record stays readable for your walkthrough. Click again to reveal.

4. 4

   Scan a dense admin panel before you co-browse

   On an internal admin view packed with data, run Scan (Pro) to auto-detect and blur emails, phone numbers, card numbers and API keys locally in one pass, then reveal only the setting you're changing together.

5. 5

   Keep the panic shortcut ready

   If you open the wrong ticket or a search flashes up other accounts, press Ctrl/⌘ ⇧ H to blur the whole page instantly, fix your view, then reveal.

Why your Zendesk or Intercom permissions don't protect the audience

Support tooling is deliberately built so one agent can see many customers — that's how you clear a queue. Roles, groups and access policies control *which records you can open*, not *what an audience watching your screen can read*. During a screen share the logged-in user is you, so everything your role grants is exactly what reaches the call. Blurring works at the presentation layer instead: it controls what the viewer sees, independent of your own access. That's also why redacting an export or masking a staging database doesn't help here — the live console still renders real, fully-decrypted data on your screen.

Co-browsing has the same blind spot

Co-browsing feels safer than a raw screen share because you're steering the customer through *their* page — but the moment you switch to your own admin view to check something, or a notification slides in, the exposure is identical. Treat any live session where your console is visible the same way: blur the structural areas (queue, nav, other-customer data) once, keep the panic shortcut on hand, and only reveal the field you're actively explaining. Because a support workflow repeats, save the structural blurs as a per-site profile so they auto-apply next time (Pro) — you'll only blur the per-ticket PII each session, and the blurs survive the single-page re-renders these apps constantly trigger.