Clipboard Manager Security: Redact API Keys Before They Hit Disk

Redact Before the Write, or It Does Not Count

A clipboard manager should treat every copy as a potential secret. Scan it, and if it looks like a key, token, or password, redact it before it gets written anywhere. Stash does exactly this. The string lands on the pasteboard, two detection layers run, and anything secret-shaped is stored as [redacted]. The real value never enters the database.

The timing is the whole feature. Plenty of tools let you delete sensitive items after the fact, or skip "transient" pasteboard types that password managers mark. That is cleanup, not protection. If the secret was written to disk for even a minute, it existed in a file that backups copied, that malware could read, and that you forgot about the moment you pasted. Redaction before the write is a different guarantee: there is nothing to clean up because nothing was stored.

Most clipboard managers do neither. They write every copy to a local database, unscanned. Think about what you copied this week. If any of it was a credential, it is sitting in that database right now as plain text.

Your Clipboard Is a Target

Attackers already treat developer clipboards as a credential source. On July 3, 2026, JFrog published research on six npm packages, linked to North Korea's Lazarus group, that impersonate Rollup polyfill tooling. The packages copy the real project's description, repo metadata, and structure. The payload runs at import time during a build, not at install, which is why scanners missed it.

What does it do once it runs? It captures clipboard content periodically. It harvests config files for VS Code, Windsurf, and Cursor. It hunts for credentials belonging to AWS, Microsoft Azure, Google Gemini, and Anthropic Claude, plus SSH keys. Read that target list again. It is a profile of exactly one person: a developer who works with AI coding agents.

The clipboard is on that list because it works. Developers move secrets through the clipboard dozens of times a week, and a process that samples the pasteboard every few seconds will eventually catch one mid-flight. A clipboard manager that persists history makes the attacker's job easier: instead of sampling and hoping, the malware reads one SQLite file and gets everything you copied for the past month.

Stash cannot stop malware from reading the live pasteboard. No clipboard app can, that is an OS-level problem, and your real defense is not installing compromised packages. What Stash can do is make sure its own history file is worthless to an attacker. A database full of [redacted] markers is a dead end.

AI Coding Multiplied the Copies

Setting up an AI coding workflow is a parade of credentials. An Anthropic key for the API. A GitHub token for the agent to push branches. Env values pasted into a new project. MCP server configs with auth headers. OAuth tokens for whatever service the agent needs to reach. Every one of those moves through your clipboard, usually more than once, because the first paste went to the wrong field.

Count your own copies for a week. When I set up a new machine for agent work, I copy 15 to 20 credentials in the first hour. Before secret redaction existed in Stash, every one of them became a history row.

Clipboard history itself has gone mainstream at the same time. Apple built it into Spotlight with macOS Tahoe. Raycast ships it. Nearly every developer I know runs some form of persistent clipboard history in 2026. That is the right call for productivity, a searchable history saves real time every day. It also means "my clipboard is ephemeral" stopped being true on most Macs. The tools quietly moved from forgetting-by-default to remembering-by-default, and secret handling has to catch up with that shift.

What Stash Catches

Detection runs in two layers, both applied to every copied string before it is persisted.

Layer 1: trigger-word pairs. Any name=value pair where the name contains one of these words gets its value redacted: secret, token, key, password, apikey, auth, credential, private. Copy a line out of a .env file and the value side never reaches disk.

Layer 2: provider formats. Some secrets announce themselves by shape. Stash matches the distinctive prefixes:

Redaction applies everywhere a copy can land: clipboard history and the capture reports that Stash generates for screen recordings. If you copy an API key while recording a session for an AI agent to read over MCP, the report logs the clipboard event with [redacted] in place of the value. The agent sees that you copied a credential. It does not see the credential.

Capture Context Purges Itself

Secrets are not the only sensitive thing a capture tool touches. Stash screenshots carry context so AI agents can read them: accessibility trees, selected text, file paths, git branches, terminal working directories. Useful for an agent five minutes after capture. A liability sitting on disk for a year.

So it does not sit there. Sensitive capture context auto-purges 24 hours after capture by default. You can tighten that to 1 hour or loosen it to never in Settings. The screenshots themselves and basic metadata follow your normal history retention. The idea is simple: context has a shelf life, and the default should respect it.

Storage follows the same posture. Everything lives in a local SQLite database at ~/Library/Application Support/Stash/. No cloud sync of clipboard data, ever. The MCP server that lets Claude Code and Cursor query your captures runs on your Mac over a Unix domain socket, with an allowlist controlling which clients can connect. Your account exists for licensing, not data collection. I wrote more about why this architecture matters in Why Your Developer Tools Should Be Local-First.

The Limits, Stated Plainly

Pattern matching is not magic. Three honest caveats.

Unprefixed secrets can pass through. A random hex string with no trigger word next to it and no provider prefix looks like any other string. Stash will store it. If your internal systems mint secrets with no recognizable shape, name them with a trigger word when you copy them, or better, do not route them through the clipboard at all.

Redaction is destructive by design. A redacted value cannot be pulled back out of history, because it was never stored. If you rely on clipboard history to re-find a key you copied last Tuesday, that stops working. Good. Clipboard history is not a secrets manager. The Keychain and 1Password exist for that job.

The live pasteboard still holds the real value. Redaction protects what gets persisted, not the copy currently in flight, because paste has to keep working. A compromised process reading the active pasteboard is an OS security problem that no clipboard app solves. Supply chain hygiene is your defense there, and this month's npm attack shows the discipline is not optional.

How to Evaluate Any Clipboard Manager

Five questions, whether you are looking at Stash or anything else. I put the same bar in the 2026 clipboard manager guide, and it is worth repeating here in security terms.

• Where does history live? You want a file path on your own disk you can point to. If the answer involves a sync service, understand exactly what leaves your machine and when.
• Does it scan for secrets before writing? Not "can I delete items later." Not "does it skip password manager types." Does it detect secret-shaped strings and redact them before persistence.
• What happens to capture context? If the tool records window titles, file paths, or terminal state, there should be a retention control and an auto-purge default.
• What is the retention story? Forever-by-default is fine, and it is what Stash does, but only if secrets never enter the store in the first place. Forever plus no redaction is a liability that compounds monthly.
• Is the behavior documented? A vendor that publishes exactly what gets detected, stored, and purged is making a commitment. Silence on these questions is an answer too.

The bar moved this year. Local-first and secret-aware is now the baseline for a developer clipboard tool, the same way HTTPS became the baseline for websites. Tools that store everything in plain text forever are not neutral. They are one compromised npm package away from being the most valuable file on your disk.