Don't Leak Secrets in Screen Recordings: A Pre-Flight Checklist

Picture a ten-minute tutorial that goes well until minute seven, when a Slack preview slides in with a customer's name and half an invoice number. You miss it while recording and while editing, and the video goes up. Or you run cat .env to explain configuration, and a live API key sits in the terminal for four seconds.

This guide gives you a three-stage checklist, a way to sort leaks by damage, a review routine using ffmpeg (a free command-line video tool) and OCR (software that reads text from images) to catch what your eyes skip, and a first-hour playbook for when something gets out anyway. The principles apply on any system. The settings are for a Mac and follow Apple's support pages for macOS Tahoe 26 and macOS 27 (Golden Gate), which use the same setting names for everything below.

What leaks from a screen, sorted by how much damage it does

Sort each possible slip by what a stranger could do with it.

The tiers decide your response later. A Tier 3 slip rarely justifies a takedown, unless the text names a person, client or unreleased project, which makes it Tier 2. A Tier 1 slip always justifies a rotation, even when you are sure nobody could read it.

Why Tier 1 earns that much suspicion

Meli, McNiece and Reaves scanned public GitHub commits for nearly six months and found leaked secrets in more than 100,000 repositories (NDSS 2019). They pushed a known string and timed their scanner: the median time to discovery was 20 seconds, and of the secrets they tracked for roughly two weeks, 81% were not removed. GitGuardian, which sells secret-detection software, retested credentials it had confirmed valid in 2022 and found the validity rate still above 64% in January 2026 (GitGuardian).

Both sources study text, and we found no study of how fast secrets in videos get harvested. But OCR is free: in one test on a clean synthetic frame, Tesseract 5.5 read an API-key-shaped line well enough to flag it. Assume a visible credential will be read, and that a valid one stays dangerous until someone revokes it.

Stage 1: build a recording setup where nothing sensitive exists

Give the recording its own accounts

• Chrome profile. Choose Add Chrome profile from the profile icon at top right and sign in only to demo accounts; each profile keeps its own bookmarks, history and passwords (Chrome Help). The Guest profile starts cleaner: Chrome deletes its history, cookies and site data when the guest window closes.
• macOS user. For a deeper reset, add a Standard user in System Settings > Users & Groups > Add User (Apple); your daily Dock and desktop stay behind.
• Cloud consoles. If the tutorial must show one, use a demo account or organization with test-mode keys and narrowly scoped users; a real production console leaks account IDs and customer data even when no key appears.

Silence the screen

• Turn on the Do Not Disturb Focus from Control Center (Apple), then set System Settings > Notifications > Show previews to Never as a second layer (Apple).
• In System Settings > Desktop & Dock, turn off Show Items "On Desktop" and "Show suggested and recent apps in Dock", and turn on "Automatically hide and show the Dock" (Apple).
• Quit chat, mail and clipboard-history apps. Phone and Chrome alerts need their own pass, which our 30-minute notification audit walks through.

Clean the terminal and the editor

These commands are for zsh, the default shell on current Macs. The first lists only the names of exported variables, never their values.

# 1. Names only (not values) of exported variables that look like secrets
print -rl -- ${(ko)parameters[(R)*export*]} | grep -i -E 'key|token|secret|password|credential'

# 2. A fresh shell: empty environment, empty history, neutral prompt
env -i HOME="$HOME" TERM="$TERM" PATH="$PATH" HISTFILE=/dev/null PS1='$ ' zsh -f

# 3. Placeholder values for the demo (demo.env holds only fake text)
set -a; source ./demo.env; set +a

We ran these on macOS 26.5.2. Plain zsh -f would still inherit every exported variable, so env on camera would print real secrets; env -i starts with only HOME, TERM and PATH, and the $ prompt keeps your hostname and git branch off screen. Use a new terminal window and a neutral folder such as ~/demo, because the title bar and pwd show your username and client folder names.

In demo.env, write lines like OPENAI_API_KEY=YOUR_API_KEY_HERE. An obviously fake placeholder beats an old real key. In the editor, close .env, credentials and key files, and show .env.example instead.

Treat "show once" dialogs as burn-after-recording moments

AWS reveals a secret access key only when it is created (AWS IAM docs), so cloud-setup tutorials put secrets on screen by design.

Tip: Adopt a burn rule: any real credential that appears on screen during a recording is revoked before you upload, whether or not you can see it in the footage. Use a throwaway, narrowly scoped demo account so revoking costs you nothing.

The rule works because it does not depend on your attention: you can miss a frame and still be safe.

Stage 2: rules while the recorder runs

1. Record a window or a region, not the whole display. Press Shift-Command-5. Record Selected Window needs macOS Tahoe 26 or later; on earlier versions use Record Selected Portion and drag a box (Apple). A window or tight region keeps the menu bar, Dock and desktop out of the file, but anything inside the frame still records.
2. Make a 20-second test recording and watch it full screen. Check the menu bar, window titles and tab strip, and listen for names and hostnames you say aloud. For how the audio sounds, see our budget microphone guide.
3. Never say or type a secret or a customer's name. Audio and auto-generated captions carry it as text. Use the placeholder.
4. Stop on any surprise. A notification, dialog or unexpected window means ending the take and redoing that step. Short per-step takes make this cheap, as we describe in how to record software tutorials people actually finish.

Stage 3: review the footage and redact the way an attacker would test it

Eyes miss things at normal speed, so run three passes. We tested the commands with ffmpeg 8.1.1 and Tesseract 5.5.2.

Pass 1: a contact sheet of the whole video

mkdir -p sheets
ffmpeg -i tutorial.mp4 -vf "fps=1/5,scale=320:-1,tile=6x5" sheets/sheet_%03d.png

This writes one thumbnail every five seconds, 30 per sheet. Skim for anything outside the window you meant to show.

Pass 2: an OCR sweep

mkdir -p frames
ffmpeg -i tutorial.mp4 -vf fps=1 frames/f_%04d.png
for f in frames/*.png; do tesseract "$f" "${f%.png}" 2>/dev/null; done
# Tier 1: credential-shaped text
grep -l -i -E 'api[_ -]?key|secret|token|password|sk-|AKIA|ASIA|gh[pousr]_|github_pat_|PRIVATE KEY|[[:alnum:]_-]{32,}' frames/*.txt
# Tier 2: your deny-list, plus anything email-shaped
grep -l -i -E -f denylist.txt -e '[[:alnum:]._%+-]+@[[:alnum:].-]+\.[[:alpha:]]{2,}' frames/*.txt

This needs Tesseract, a free OCR engine, installed. denylist.txt holds one term per line: customer names, your employer's domain, internal hostnames, your home-folder name. Short patterns like sk- and ASIA are noisy under -i, so expect false alarms.

OCR is triage, not a verdict. In one run on a clean synthetic frame, Tesseract read sk-proj-DEMO1234abcd as sk-proj—DEM01234abcd, so the patterns are loose keywords, not exact formats, and real compressed footage will read better or worse. One frame per second can miss a banner that flashes past; use fps=4 for terminal and console segments. A sparse 720p frame took about a quarter of a second on our Mac, so a ten-minute video is 600 frames at fps=1 and 2,400 at fps=4; time a sample of your own. Inspect every flagged frame, and do not read a clean run as clearance.

The review files are copies of the leak. Run the sweep in a folder that is not synced to iCloud Drive or Dropbox, and delete the frames, sheets and OCR text when you finish (rm -rf frames sheets).

Pass 3: grep the transcript and OCR text for exact formats and spoken names

Export captions from your editor, or generate a transcript locally, before you upload; captions.srt is that file.

grep -n -E 'A(KI|SI)A[0-9A-Z]{12,}|gh[pousr]_[A-Za-z0-9]{20,}|github_pat_[A-Za-z0-9_]{20,}|BEGIN [A-Z ]*PRIVATE KEY' captions.srt frames/*.txt
grep -n -i -f denylist.txt captions.srt

Speech recognition rarely spells out a token, so the first pattern mostly earns its keep on the OCR text; the second catches spoken customer names and hostnames. AWS access keys start with AKIA and temporary (AWS STS) key IDs with ASIA (AWS IAM identifiers). GitHub tokens start with ghp_, gho_, ghu_, ghs_, ghr_ or github_pat_ (GitHub Docs). Add your other providers' prefixes from their docs.

Redaction that survives an attacker

Hill, Zhou, Saul and Shacham used hidden Markov models, a technique borrowed from speech recognition, to reconstruct text behind mosaic and blur filters, including real redacted examples, and concluded neither filter reliably redacts text (PoPETs 2016).

Bishop Fox's Unredacter, a proof of concept released by Dan Petro in February 2022, guesses one character at a time, pixelates the guess and compares it with the redacted image. It assumes the attacker knows the font, the font size and that the content is text (in Petro's example, words above the pixelated line gave away the first two), and it brute-forces the unknown pixel offsets. His advice: cover the whole text with solid black bars and use nothing else (Bishop Fox). Both studies used still images, and a video is a sequence of stills; neither source gives a blur strength you can trust.

Warning: An editor's box or blur can sit on its own layer and drift off the text for a frame or two as the screen scrolls, so scrub the exported file, not the project, around every redaction. YouTube Studio's custom blur is still a blur, so keep it for faces and backgrounds, and scrub the result if you use its Track object option.

Two habits finish the pass. Keep unredacted originals and project folders off shared drives, because editors that preserve your source footage also preserve the secret. And strip container metadata from the export, which removes global tags such as title and comment:

ffmpeg -i final.mp4 -map_metadata -1 -c copy final-clean.mp4

If something slips through: the first-hour playbook

1. Minutes 0 to 5: take the video out of view. On YouTube, open Studio > Content, use the Visibility menu and choose Private, which limits viewing to you and people you choose (YouTube Help). Remove embeds. Do not delete yet; you may need to see exactly what was exposed.
2. Minutes 5 to 30: kill the credential first, replace it second. For a Tier 1 credential, deactivate the exposed key now. AWS's incident guidance recommends disabling rather than deleting at first, because a disabled key can be restored if an app breaks. Then create the replacement (or move to an IAM role, which uses temporary credentials), update your apps, and delete the old key once nothing depends on it. Routine rotation runs create, switch, deactivate because nothing is on fire; with a live leak, minutes of downtime cost less than minutes of exposure. The same 2014 AWS post adds a detail people miss: temporary credentials issued from the exposed key expire on their own schedule unless you invalidate them (AWS Security Blog).
3. Within hours: read the logs. Check activity from the moment the video went public to the moment you revoked. AWS's guidance names S3 bucket logs and CloudTrail logs, and says to restore from a pre-exposure backup if data was modified.
4. Same day: fix the video. For a Tier 1 credential you have already revoked, cut the section in Studio (Content > the video > Editor > Trim & cut > New Cut > Save), which keeps the URL, view count and comments (YouTube Help). For Tier 2 data, or anything you want gone, upload a re-edited video, which gets a new URL (YouTube Help), then delete the old one. Deletion is permanent, but the Help pages we read do not say what happens to existing links or the pre-edit file. Re-upload too if Studio refuses to save edits, which can happen to unedited videos with over 100,000 views outside the YouTube Partner Program. Then hunt down other copies: embeds, cross-posts, clips cut from it, and your own storage or CDN. Anyone who downloaded the video while it was public still has it, which is why step 2 is the fix and this step is cleanup.
5. For Tier 2 leaks, tell the data's owner first. If the footage shows a customer's or client's personal data, tell them and your privacy contact the same day. Under the GDPR, the controller (whoever decides why and how personal data is used) must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights and freedoms (Art. 33(1)). A processor (anyone handling data on the controller's behalf) must tell the controller without undue delay (Art. 33(2)), and the controller must document any breach (Art. 33(5)). Telling the individuals is a separate duty when the risk is high (Article 34). Whether a clip counts as a breach is for whoever handles privacy at your company; this is not legal advice.

Keep a short note for every incident:

Incident note: screen recording exposure
Video / URL:
Public from (UTC) to (UTC):
What was visible (tier 1 / 2 / 3):
Credentials disabled, then replaced, at:
Logs checked (service, window, result):
Video made private / cut / replaced at:
Who was told (data owner, privacy contact):
What changes in the checklist:

The printable checklist

Before

• Demo-only Chrome profile or macOS user; throwaway, scoped credentials
• Do Not Disturb on, previews set to Never, desktop items hidden, Dock recents off
• Fresh shell with an empty environment and neutral prompt, placeholder env file
• .env, key files, chat, mail and clipboard apps closed; any real console on screen runs on a demo account
• 20-second test recording watched full screen and listened to

During

• Window or region capture; no secret or customer name spoken or typed; stop on any surprise

After

• Contact sheet, OCR sweep, deny-list and caption grep done; flagged frames inspected
• Text-heavy moments scrubbed in the export; cuts or solid boxes only, no blur on text
• Metadata stripped; raw originals kept private; frames, sheets and OCR text deleted
• Any real credential shown anywhere revoked before upload

If it leaks

• Video private; credential disabled, then replaced; logs checked; owner told; incident note filled

Where to start this week

Create the recording Chrome profile and set Do Not Disturb. Then run the OCR sweep on the original file of your most-watched tutorial. A clean result is not clearance, but a hit means you have a rotation to do today.

Frequently asked questions

Is it fine to blur faces or background windows?

For anything that is not a credential or readable text, yes. Blurring a face is a courtesy, not a security boundary, so if someone must stay unidentifiable, use an opaque shape or cut the shot. YouTube Studio offers face blur and custom blur (YouTube Help).

What if the key was a test key, already expired, or a placeholder?

A placeholder or a key you already revoked needs nothing. Anything that still authenticates to a real account, test mode included, gets the burn rule, because you cannot know what a stranger can reach with it.

Will recording one window keep notifications out of the file?

Apple documents a separate setting, "Show Notifications: when mirroring or sharing the display", but its page does not mention screen recording, and we found no Apple page covering banners over a recorded window. Keep Do Not Disturb on, and check your 20-second test recording.

Sources and further reading

• How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories — Meli, McNiece and Reaves, NDSS 2019. Discovery time and removal rates.
• The State of Secrets Sprawl 2026 — GitGuardian, 2026. Vendor data on credential validity.
• On the (In)effectiveness of Mosaicing and Blurring as Tools for Document Redaction — Hill, Zhou, Saul and Shacham, PoPETs 2016. Blur and mosaic failing on text.
• Unredacter: Never Pixelate Sensitive Information — Dan Petro, Bishop Fox, 2022. Pixelation recovery; black bars.
• What to Do If You Inadvertently Expose an AWS Access Key — AWS Security Blog, 2014. Disable first, review logs, restore from backup.
• Art. 33 GDPR: Notification of a personal data breach to the supervisory authority — gdpr-info.eu, an unofficial reproduction. The 72-hour rule.
• Replace or delete your video — YouTube Help. No file replacement; deletion is permanent.
• Trim your videos — YouTube Help. In-place cuts and the 100,000-view limit.

TechCast Studio, our local-first recording workspace, runs recording-readiness checks (audio, system, readability and privacy) before you record. It is in Founding Beta on Apple Silicon. Every step above works with the recorder and editor you already use.