Screen-Sharing Privacy for Sales Engineers: Safe Technical Demos
A live demo over screen share can leak another customer's data from a shared tenant, plus API keys, internal URLs, roadmap features and pricing. Here's how to demo the product without leaking secrets.
When you give a live technical demo over screen share, you must protect anything that isn't the feature you're showing — another customer's data if the demo tenant is shared, the internal URLs and API keys in your environment, unreleased roadmap features, pricing, and any real PII that leaked into seeded demo data. The safeguard is to blur what you're not actively demoing before you present, so a shared sandbox, a browser autocomplete or a stray console tab never hands a prospect one customer's records or your company's secrets. Sales engineers run against real admin consoles and API tools, so a slip can breach another customer's data and reveal information the prospect was never meant to see.
What leaks during a live technical demo
- Another customer's data — if the demo tenant is shared or points at a staging copy of production, account names, records and usage from real customers can appear.
- Internal URLs and API keys — admin consoles, internal tooling links, bearer tokens and secrets in an API client or the browser address bar's autocomplete.
- Roadmap and unreleased features — feature flags, beta menus and internal dashboards that reveal what's coming before it's announced.
- Pricing and commercial terms — internal pricing sheets, discounting tools or contract values open in another tab.
- PII in seeded data — 'test' data that's really a scrubbed-but-not-scrubbed export carrying real emails, phone numbers or SSNs.
- Your own IDE, terminal and env — a browser-based IDE or terminal showing environment variables, connection strings and tokens.
The riskiest moment: the live demo in a shared sandbox
The classic scenario is a live product demo: you sign into a demo tenant and click through a workflow while a prospect watches. The trouble is the demo environment rarely contains only tidy fake data — the account switcher lists other customers using the same sandbox, the admin console exposes internal-only settings and API keys, a seeded record turns out to hold a real person's email, and the address bar autocompletes an internal URL the moment you start typing. Switching accounts, opening dev tools, a Slack preview, or an autocompleted internal link is all it takes to show a prospect another customer's data, a secret token or a feature that isn't announced yet. Blurring lets you demo the exact screen you mean to and keep everything else frosted.
How to give a live product demo without leaking another customer's data or internal secrets
- 1
Share one tab, not the screen
In Zoom, Meet or Teams, share the single browser tab running the demo — never your whole screen, so your IDE, terminal, Slack and internal dashboards stay off the feed. Turn on Do Not Disturb to stop notifications surfacing customer names.
- 2
Scan for secrets and PII first
With BlurFirst, run the Pro Scan on the tab to find and blur API keys, tokens, emails, phone numbers, SSNs and credit-card numbers locally before you start clicking — a fast catch for seeded data that turned out to be real.
- 3
Blur the account switcher and admin-only panels
Box-blur the tenant or account switcher so other customers in a shared sandbox stay hidden, and element-blur any admin console settings, feature-flag menus or internal URLs you don't want the prospect to see.
- 4
Hide the address bar hints and roadmap surfaces
Blur any in-page autocomplete or recent-links panel and any beta or roadmap menu so an internal link or an unreleased feature name doesn't appear mid-demo. Keep pricing tools and internal dashboards in tabs you never share.
- 5
Save a per-site profile
Save the blur as a per-site profile (Pro) so your demo tenant, admin console or API tool re-applies its blurs automatically next time, and the blurs survive the single-page-app re-renders as you navigate the product.
- 6
Keep panic blur ready
If another customer's record, a token or an internal screen appears, press Ctrl/⌘ ⇧ H to blur the whole page instantly, fix it, then reveal only what you meant to demo.
What to blur in each surface
| Surface | Blur before you present |
|---|---|
| Demo tenant / sandbox | The account or tenant switcher, other customers' records, any seeded PII |
| Dashboards | Internal-only metrics, customer names in charts and tables, usage tied to real accounts |
| Admin console | API keys and secrets, internal settings and feature flags, user email addresses |
| API tools (Postman, etc.) | Bearer tokens and authorization headers, environment variables, internal base URLs |
| Browser-based IDE / terminal | Env files, connection strings, tokens, and any recent-command or path autocomplete |
Honest limits
- BlurFirst blurs content inside a browser tab — a web app demo, a browser-based admin console, Postman on the web and a browser IDE all qualify. It can't blur a native desktop app, a separate terminal window or Slack, so close or unshare those (a desktop app is in development).
- The one-click Scan detects patterns — API keys, tokens, SSNs, credit-card numbers, emails and phone numbers — locally in the tab. It does not detect free-text customer names or unreleased feature labels, so blur those with box or element blur yourself. The best fix for a leaky sandbox is a clean demo tenant; blurring is the safety net.
- It can't run on
chrome://pages or the Chrome Web Store, but that's not where your demo runs.