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 right that everything else in this thread is post-install, and that is a real hole. The counter reassures someone who already trusts me enough to run my binary, which is the wrong end of the funnel for the claim that is hardest to believe.
The paste-a-string page is the strongest version I have been given, and the reason is that it inverts who is asserting. Right now I say the detector works. That page lets someone verify it without giving me anything, not even an install. It also fails usefully: if people paste real-world strings that get through, I learn about my false negatives from strangers, for free, which is more adversarial testing than I can generate alone.
The part I have to be careful about is that a test page which tells you whether a string matches is also, from the other side, a way to check whether a given secret format evades my detector. That is not much of a threat model for a writing tool, but it is worth thinking through before it exists rather than after.
Publishing the patterns themselves I am less sure about, though probably for bad reasons. There is nothing clever in them. The reluctance is vanity rather than security, which is usually a sign the open version is correct.
I am going to build the page. Thank you, this is the most useful thing anyone has said about this feature.
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.
This is the comment I will still be thinking about next week.
You are right that the feature is unexplainable to anyone who has not had the near miss, and obvious to anyone who has. Which means the work is not writing a better paragraph, it is being present where people describe the moment it happened to them. That is a completely different activity from the one I have been doing.
The uncomfortable consequence is that it makes most of my marketing surface useless for this particular feature. A landing page reaches people in a browsing posture, and browsing people have not just pasted a key into something. The person who has is, at that exact moment, searching for how to revoke it.
I am not going to pretend I know how to act on that cleanly yet. Showing up in threads where someone has just done it, to say here is a thing that would have caught that, is a fine line between useful and ghoulish, and I would rather think about which side it lands on than move fast on it.
But the reframe is right and I had the wrong problem in my head. Thank you for stating it that plainly.
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.