Launched this week
HeimWall
Catch secrets before they leak into Cursor & Claude
44 followers
Catch secrets before they leak into Cursor & Claude
44 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.
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.
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.
would love to see a quick test mode where i can paste in a sample prompt and see exactly which rules flagged it, basically a way to tune the 47 rules for my own workflows without needing to trigger real leaks in my actual coding sessions
@ramazan793230 You can do a rough version of this today: the clipboard guard scans whatever you copy, so copying a sample key lights up the feed with the exact rule that matched, no coding session involved.
A proper playground panel inside the app is a lovely idea though. The engine runs right there on-device, so a type-and-see-what-fires box is very doable, and honestly it would double as the best onboarding demo. Adding it to the list.