Your clipboard has seen your API keys. I had to build assuming mine would too.
Think about what went through your clipboard today. A password out of your manager. An API key from a dashboard. A salary figure. Half-written messages you would not want stored on anyone else's server. It is the most sensitive surface on the machine and nobody treats it as one.
I build a desktop app that reads what you select or copy and runs AI actions on it. Which means the interesting engineering was never the AI part. It was refusal.
What that turned into:
A detector for 21 secret patterns, covering passwords, Bearer and JWT tokens, provider keys for the usual suspects, PEM private keys, and URLs with credentials embedded in them. It runs in the UI layer and again in the native backend, and once more server side. Anything that matches is never written to local history and never sent to any AI provider, including my own managed one. OCR output gets re-scanned before it is saved, because text extracted from a screenshot of a dashboard is exactly the case that bites you.
Copies originating from the big password managers are skipped from history by default. Your own provider keys, if you bring them, live in the OS keyring rather than in a config file or the app's storage.
The honest limits, since a privacy claim without its edges is just marketing: the local history database is not encrypted at rest yet, so someone with access to your unlocked machine can read it. And when you run an action against a cloud provider, the text you selected does go to that provider. That is what cloud AI is. Only the local model path keeps everything on the device.
Here is the part I have not solved. All of this is invisible. It produces no screenshot, no demo, no before and after. The one moment a user could notice it is the moment nothing happens, when they copy a key by accident and no action fires. As far as I can tell it has contributed nothing measurable to conversion, and I would still build it again tomorrow.
So, for anyone who has shipped trust work: have you found a way to make it legible to buyers that does not turn into fear marketing? Every framing I try either sounds like I am scaring people about a problem they had not considered, or it sounds like nothing at all.
The answers here are all about making refusal visible after install. Your problem sits earlier than that — the person deciding whether to download has never seen the counter and never will.
The version of this that isn't fear marketing is making the detector checkable by someone who hasn't installed anything. Put the 21 patterns and their test corpus in a public repo, and put up a page where you paste a string and it tells you, locally, whether it would have been blocked. No app, no account. The claim stops being "we refuse" and becomes "here's the thing that refuses, run it yourself." That's an artifact you can screenshot, and it's not a warning about a problem the reader hasn't had yet.
The side effect might matter more than the messaging. A public corpus gets pull requests — people send you the pattern you missed, and I'd guess Slack tokens and pre-signed S3 URLs are in the first batch. That's free coverage, and a repo is a thing security-minded devs actually pass around, which a landing page never is.
It also defuses the false-positive worry from the counter discussion, since over-matching becomes visible to everyone rather than just to you.
You are treating this as a messaging problem. It is a targeting problem.
Nothing you write will make refusal legible to someone who has never pasted a key by accident. To someone who has, it needs no explanation at all. And those people announce themselves in public.
giancarlostoro on Hacker News, 19 May: "Claude told me to revoke an API key I accidentally pasted." His only guardrail was the model happening to care. Yours is the thing he assumed he already had.
Kyrio, same site, on a tool that wanted his vendor keys: "So far I've only worked in places that banned ChatGPT over IP concerns like these." That is your buyer describing the ban he lives under.
Neither of them is shopping for you. Both already wrote the reason.
I hand-build prospect lists for founders. Want the rest? Free, no strings.
Your limits paragraph is doing more trust work than the detector list. I’d make the blocked count an audit trail, not a badge: show the pattern category, whether the user overrode it, and the exact boundary (local history not encrypted, cloud action leaves device). That lets a buyer verify the protection without turning a scary hypothetical into marketing. It also gives you a useful signal for false positives before a high count starts rewarding an over-eager detector.
@Wrenio_Studio Both, but I’d emphasize the session count. It gives immediate feedback: “that thing I just copied was protected.” The lifetime number can sit in a history view, but after a while it’ll just become wallpaper.
Make the refusal visible or it may as well not exist. Ship a counter in the UI, blocked 47 secrets this month, 3 today, with a one-line log the user can open, because nobody values a thing that never produces an artifact, and that counter is also the screenshot you said you did not have. From years of selling security work, the other half is attestation: a published threat model and an independent pen test result move buyers more than any feature list, because a privacy claim is worth what an outsider will put their name on.
A small local audit like “3 secrets blocked this week” could make the protection visible without exposing the secrets. Specific limits also feel more trustworthy than simply saying “we take privacy seriously.”
That is the best answer anyone has given me, and it is buildable this week. The count never leaves the machine, so it costs nothing in privacy terms, and it converts a non-event into something the user can actually see.
One wrinkle I would want to design around before shipping it. A number like that is only impressive when it is high, which quietly creates an incentive to loosen the detector, and a loose detector on this particular feature means blocking things that were not secrets and making the product feel broken. So I think the honest version shows both sides: blocked this week, and a way to see what was blocked so a false positive is visible rather than mysterious. A user who sees "3 blocked" and can confirm all three were real keys gets the reassurance. A user who cannot check is just being told a number by the same party that produced it, which is where "we take privacy seriously" came from in the first place.
Your second sentence is the part I want to keep: specific limits read as more trustworthy than general assurances. That is exactly why the unencrypted history line is in the post. Saying the thing that costs you something is what makes the rest believable.
Would you want that count per session, or cumulative since install?
The hardest part of trust features may be that their success is mostly invisible.
Curious whether buyers respond more to the protection itself, or to seeing what could have happened without it.
I think those two are the same lever pointed in opposite directions, and only one of them is safe to pull.
Showing the protection is describable: here is what it does, here is what it refuses, here are its limits. Showing what could have happened without it means dramatising a loss the person has not experienced, and the moment you make that vivid you are selling with fear. It also sets up a claim you cannot support, because you do not know what would have happened to that particular user.
So my instinct is protection only, stated plainly, with the failure modes attached. The suggestion above about a local count of blocked secrets is a third option I had not considered, and I like it better than either, because the evidence is generated by the user's own machine rather than asserted by me. Nothing to believe, just a number that either matches their experience or does not.
The honest answer to your question is still that I do not know which converts. Nobody has bought or declined in front of me because of this feature.
That’s a good distinction. The local blocked-secret count seems much more credible than trying to manufacture a hypothetical loss scenario.