Launched this week
HeimWall
Catch secrets before they leak into Cursor & Claude
48 followers
Catch secrets before they leak into Cursor & Claude
48 followers
HeimWall catches leaked secrets, credentials, and PII the moment they're about to reach AI coding assistants like Cursor, Claude Code, and Copilot. A lightweight macOS app, fully on-device: 47 hand-written rules flag leaks in real time. Your prompts never leave your Mac. No content stored, no account, no signup. Free for individual engineers. Next up: a team dashboard showing security leads leak trends without exposing what anyone typed. Signal, not content. Design partners welcome.
Good to know the standalone-app approach keeps the composer reads stable — that was my main worry with the Electron editors like Cursor. On custom rules: even a simple local list of extra prefix strings (no full regex engine) would cover the internal-token case for most teams without you shipping an app update each time. Is that the likely direction, or are you thinking a managed ruleset pushed centrally?
@hi_i_am_mimo Right now it's the 47 built-ins, no custom rules yet, but this is the case that makes the strongest argument for adding them, and you're the second person to land here. And you're right it doesn't need a full regex engine: a local list of extra prefix strings would cover most internal-token cases without an app update, which is the lightweight version we'd look at first. Managed team rulesets are the natural next step. Useful signal, thanks so much for your feedback.
@ata_cinar_genc Makes sense to start with prefix strings. One thing worth building in from day one is an allowlist alongside the blocklist — plenty of internal prefixes look scary but are safe to paste (public-repo tokens, sandbox keys), and if the first version only ever adds matches teams will hit noisy false-positives and turn it off. Are you thinking the local rules would support both add and exempt patterns, or additive detection first?
@hi_i_am_mimo Right instinct, and it's the failure mode I worry about most: a tool that only adds matches gets noisy, and a noisy security tool gets turned off — worse than not having it. Your examples (sandbox keys, public-repo tokens, test creds) are exactly the ones that erode trust. So the direction is add and exempt together, not additive-first — shipping the blocklist without the allowlist is basically shipping the false-positive problem. Good day-one thinking.
Really like the signal over content approach. One thing that would help me actually roll this out is a one-click allowlist for the specific secret values I know are safe but get flagged constantly, like local Postgres URLs or my dev API keys. Right now I'd imagine false positives get noisy fast. Persistent per-project overrides with maybe an audit log would make this feel less like babysitting and more like a real safety net.
@furkan522799 This is the right bar to hold us to, alert fatigue is what kills tools like this. Two honest notes. The validators already try to discount dev-shaped values, localhost connection strings and placeholder patterns get rejected by shape. And a mute-this-exact-value allowlist is a very natural fit: we already compute a local hash of every matched value for dedup, so remembering your dismissals on-device is a clean next step. Per-project is trickier since we watch the prompt box rather than your repo, but value-level overrides plus a local log of what you muted is noted.
The deterministic 7MB rule engine over the Accessibility API is the right tradeoff here — no model means nothing to phone home, which is the whole point for a leak-prevention tool. Since Cursor and Copilot-in-VSCode are Electron, does the composer read stay reliable there, or does the Accessibility tree get flaky compared to a native field like Claude Code in the terminal? And can I add rules for our own internal token prefixes locally, or does expanding past the 47 built-ins need an app update?
the DevGPT stat sold it, three live keys and 49 emails in one week of public snapshots is a genuinely alarming stat. since detection is rule-based rather than a model, how do you handle secrets with no recognizable format, like an internal API key using a company-specific naming scheme that just looks like a random string? that seems like the hardest case for a pattern-matching approach
@galdayan Hardest case for pattern-matching, and I won't pretend regex alone catches it. A lot of formatless keys still get caught on entropy (randomness is itself a signal) or on context (a random string next to TOKEN=…), and for a known internal naming scheme you'd add a custom rule. The true residual, low-entropy secrets that look like ordinary strings with no contextual tell, pattern-matching misses, and that's exactly what a semantic layer is for. Good question, and thanks for the feedback!
@ata_cinar_genc that makes sense, entropy plus context gets you most of the way there. the low-entropy no-tell case is a good honest answer, most tools would just claim to catch everything. curious how the custom rule authoring works in practice, is that something teams do themselves or do you help set it up
One thing I'd love to see is a simple CLI flag so I can pipe clipboard content through HeimWall's rule set from my terminal without opening the app. That way quick checks during code review stay in my flow.
@ege_karama27779 Funny timing, you and the git-hooks commenter above are pointing at the same deliverable: the engine packaged as a small CLI. It already runs as one inside our benchmark harness, that's how we scan public corpora, so pbpaste piped into a heimwall check with proper exit codes is a very natural release.
Small note, if the app is running the clipboard guard is already watching passively. But an explicit terminal check with visible output is a different flow, agreed. On the list.
Congrats on the launch!
Two questions:
1) Claude Code runs in a terminal no structured composer for the Accessibility API to read. How do you handle that surface?
2) The bigger leak vector arguably isn’t what the user pastes, but what the agent itself reads and sends to the API (.env files, configs). Is a local proxy layer for agent traffic on the roadmap?
@ali_ekmekci Great questions, both hit walls we ran into personally.
1) Terminals are accessibility surfaces too, Terminal and iTerm expose their text through the AX tree, and the clipboard guard covers the paste-into-terminal path, which is where most terminal leaks happen. Claude Code catches show up in our live data daily. That said, it's the roughest of our capture paths, and the CLI packaging people asked for above will make it first class.
2) Agreed, and our technical report says exactly this: agent-read files are a strictly larger surface and we make no prevention claims there today. War story: we actually built a local TLS proxy first, then learned some tools pin certs or ship prompts straight to raw IPs, which defeats any middlebox. It still exists behind a feature flag, off in the free build because it needs a root CA and a system proxy, host mutations a free consumer app should not do silently. That layer is planned for managed team deployments where an admin explicitly opts in.
@ali_ekmekci Also as we would say in Turkish; teşekkürler dostum.
Love that it's fully on-device, finally something that doesn't sell my clipboard to a cloud. One thing I'd want soon though - a way to whitelist my own throwaway test secrets so I'm not hitting the red on every dummy API key I paste in for debugging.
@duygugonul48114 Thank you! You're the third person today asking for this, which pretty much settles the roadmap question. In the meantime, obviously fake-shaped values like EXAMPLE keys and your-token style placeholders are already rejected by the validators. It's the authentic-format dummies that hit the red, and a mute-this-value option that remembers your dismissals on-device is the natural fix. It just moved up the list.