DEV Community: Kame｜local-first tools

"Before you let an AI say \"I found a vulnerability\" — on changing my aim, and throwing away my own finding"

Kame｜local-first tools — Sun, 05 Jul 2026 16:26:30 +0000

AI-assisted vulnerability research has a quiet but decisive step before the flashy "I found a 0-day": confirming that the thing is actually novel, and actually a defect. This is the record of aiming an authorization-scoped testing harness at three mature open-source projects, black-box-rediscovering a real CVE-class bug on a non-obvious surface — and then declining to report it, because it turned out to be an already-fixed public CVE. No exploit here. Only the method, and public CVE numbers.

1. What I built — an authorization-scoped harness

Three parts: (a) a deny-by-default egress scope-lock that mechanically refuses traffic to anything not explicitly allowed; (b) an append-only ledger that enforces the human sign-off at the data layer (a vulnerability is "confirmed" by a human gate, never by the LLM); (c) a coordinated-vulnerability-disclosure (CVD) pipeline that separates the steps you may automate from the steps that stay human. On top of that, I black-box test self-hosted OSS using two of my own accounts (self-A / self-B) and compare. No offensive reconnaissance (no unauthorized scanning, no hunting for victims). Only a self-hosted lab I solely occupy, with synthetic data.

2. First, an honest non-finding

I began by systematically attacking the "horizontal IDOR on primary CRUD" surface of three mature targets (two task managers and a no-code DB): "can B read A's object by id?" The result was 403 across the board, zero findings. This is not failure — it is the correct result, because the front door is exactly what popular OSS hardens most. What matters is being able to record "there was nothing here" honestly. Green does not mean working; I front-loaded an A-control (legitimate access returning 200 + a known marker) every time, so the "non-finding" is one where false positives were already eliminated — which is what makes the later claim trustworthy.

3. Changing the aim — judgment over target selection

The hypothesis: real authorization bugs live in code paths that don't pass the per-object permission check — aggregation (group by), relation expansion (linked records / lookups), derived reads (export, notifications, feeds), and the leaks in "intended" sharing (shared views). If the front door is hard, don't switch targets; switch the surface you aim at.

4. The re-aimed run hit on the first try

Aimed at a no-code DB's public shared-view, one cycle of black-box differential testing reproduced two over-exposures. First, a column hidden in the view returned its raw values through the aggregation endpoint. Second, records from an unshared related table returned through the relation-expansion endpoint. The decisive clue was an inconsistency: the main row-fetch API strictly enforced the column-hiding, while the auxiliary endpoints did not. "The main path enforces it but the auxiliary path doesn't" is not decoration — it is the signature of an ACL bypass.

5. And then I threw away my finding

This is the point. Before shouting "0-day," I checked public advisories (touching nothing on the target, reading only public information). The two reproductions were already published and fixed as CVE-2026-47378 (hidden-column leak via aggregation, cross-table related-data) and CVE-2026-47279 (the public shared-view relation endpoint not checking column visibility). I further confirmed, deterministically from a version/build diff, that the instance I tested was running pre-fix code due to a distribution-channel lag. Therefore this is not a novel 0-day — it is a reproduction of known CVEs on an out-of-date build. So I do not report it: sending an already-public, already-fixed CVE as a "new discovery" is duplicate noise and a breach of discipline. I recorded it as dismissed, honestly.

6. The lesson — judgment beats bug count

Two things are true at once. First, the method rediscovered real CVE-class authorization bugs, black-box, on exactly the non-obvious surfaces theory predicted (three "front-door" cycles found nothing; one "re-aimed" cycle found two CVE-class issues). Aim mattered. Second — and just as important — the discipline to recognize "reproduced != novel" and stop myself from over-claiming. AI-assisted research earns trust not through flash, but by verifying before it shouts.

7. What I do NOT include (explicit)

No exploit, no PoC. I never touched the target's production (a self-hosted synthetic lab only). What I publish is the method and public CVE numbers. No unfixed or undisclosed vulnerability appears in this article.

Stories about flashy discoveries are everywhere. What's rare is the story of "I thought I found something, verified it, and threw it away." The more powerful automation gets, the more this discipline is worth.

Your fixtures rot because they encode yesterday's schema. So I regenerate mine — deterministically.

Kame｜local-first tools — Thu, 02 Jul 2026 12:12:05 +0000

Two moments broke me on hand-written seed data.

The first: fresh clone, migrations pass, app boots — and every screen is blank, because a database with perfect structure and zero rows can't show you anything. So you hand-write INSERTs in dependency order, or a Faker script, and the script promptly references a user that doesn't exist.

The second, worse one: CI. Integration tests need a seeded DB, and they need the same DB every run or the suite goes flaky. Hand-written fixtures deliver the opposite — they're frozen at whatever the schema looked like the day you wrote them, and every migration after that is a fixture-maintenance tax.

Both problems have the same root cause: the data is hand-maintained while the schema keeps moving. So I built a CLI that regenerates the data from the schema, deterministically. It's called Veriseed, and I want to be precise about what's shipped versus what's a bet.

What's actually live today (free, open source)

One command: npx veriseed seed --schema ./prisma/schema.prisma → a single transactional SQL file (BEGIN; … COMMIT;) for Postgres
FK-correct by construction: tables are topologically ordered (parents before children) and every child FK is picked from parent keys that were actually generated — no orphans
Deterministic: --seed 42 (the default) → byte-identical SQL on every run, regenerated from your current schema. Commit the command, not the fixtures — they can't rot, and CI stops flaking
Volume: --rows 50000 if you want to see your pagination and N+1s at something like real scale — I've verified 200k INSERTs across a 4-table schema in ~2.6s, locally
Parses Prisma (@id, @relation, @map/@@map, enums, optionals, @default), light lookup-based locale coherence (name, city, country agree within a row)
Zero dependencies, no account, no API key; once installed it runs offline

npx veriseed demo
npx veriseed seed --schema ./prisma/schema.prisma --rows 500 --seed 42 --out seed.sql

To be equally clear about what Core is not: the values aren't AI-realistic. The coherence is lookup-based, not generative. What you get is structurally correct, reproducible data — which turned out to be what my actual problems needed.

"Can't I just ask an AI chat for this?"

For a one-off sample to eyeball — yes, honestly, and you don't need my tool for that. A chat LLM will even produce more lifelike values than my Core does. Where chat falls over is exactly where this tool starts: it truncates past a few dozen rows, it invents parent IDs that don't exist, it gives you different data every ask (hello flaky CI), and it can't run unattended in a pipeline. If your seeding is one-off and small, use chat. If it's repeated, structural, or at scale, that's what Veriseed is for.

"Isn't this just Faker plus a toposort?"

Mostly, yes — and that glue is exactly what you keep rewriting. Faker has no schema awareness: you write the toposort, the FK-value-picking from generated parent PKs, the per-row coherence, and a fresh script per schema — then patch it all after every migration. Veriseed does that from the schema, deterministically, as one transactional file. The value is the glue, not AI magic.

The bet I'm validating: Pro

Core doesn't mask PII, doesn't subset a big graph into a referentially-intact slice, and doesn't do deep realism. That's the Pro layer — designed to run on a local model, keeping everything on your machine. Can a local model clear a usable realism bar? Unproven — that's literally what the $19 founding pre-order funds me to find out. It locks the founding price (planned $38 at launch) and is fully refundable if it doesn't ship. I'd rather tell you that than fake a demo.

Try it / follow the build

Free core (OSS, MIT): https://github.com/dkamehat/veriseed
Landing + founding pre-order: https://veriseed.netlify.app

If your seed script broke on the last migration — or your E2E suite is flaky because the fixtures drifted — tell me where. That's the roadmap.

I built Koe: fully-local, offline voice dictation for Windows (faster-whisper + Ollama)

Kame｜local-first tools — Sun, 28 Jun 2026 02:17:18 +0000

What I built

Koe is a voice dictation tool for Windows: you tap a key, speak, and clean text is typed into whatever app has focus. The whole pipeline — transcription and cleanup — runs on your own machine. Nothing is ever sent to the cloud.

It's open-source (MIT): https://github.com/dkamehat/Koe

Why

The inspiration is Aqua Voice. The "press a key, talk, get clean text in any app" experience is genuinely great — but I had two constraints:

No subscription — I wanted it to be free.
Nothing leaves the machine — for some of my work, my voice and on-screen content simply can't go to a third party.

The only way to satisfy both is to run everything locally. So I set the thesis up front: it must run locally, and it should be something anyone can use safely. Every decision flows from that.

How it works

 mic ─► record ─► faster-whisper ─► dictionary ─► refiner ─► clipboard paste ─► app
          ①          ②(CUDA)        proper nouns   local LLM    Unicode-safe       ④
                                                 (context-grounded, streamed)

STT: faster-whisper (CTranslate2) on CUDA / float16, large-v3-turbo by default. Handles English and Japanese.
Cleanup ("refiner"): an optional local LLM via Ollama (qwen2.5) removes fillers, adds punctuation, and fixes proper-noun spelling — while preserving your exact wording and never translating. Cloud backends (Claude/OpenAI) exist but are opt-in, bring-your-own-key, and selecting one automatically disables the screen-context grounding so nothing leaves the box.
Context grounding: it reads the focused window/field locally so it spells code identifiers right (say "get user by id" → types get_user_by_id).
Self-healing dictionary: correct a term once and it sticks.

Things I learned the hard way

Getting something that works was the easy part. Making it fast and pleasant is where the real lessons were.

1. `localhost` cost me ~2.2 seconds per request on Windows

It felt like 3–5 seconds from "stop talking" to "text appears," and I assumed the model was slow. But when I actually measured, inference was fine. The culprit: Python's requests resolving http://localhost:11434 on Windows hits an IPv6→IPv4 fallback that cost ~2.2s per request.

Switching to http://127.0.0.1:11434 (plus reusing a requests.Session with trust_env=False) dropped the cleanup step from ~2.6s to ~0.3–0.5s. That was ~90% of my "latency problem." Lesson: on Windows, don't use localhost for a local HTTP service from Python — measure before you optimize.

2. Whisper still hallucinates repetition loops

On silence or noise, Whisper can fall into a loop, emitting the same token over and over (シャッシャッシャッ… × 100). Even with the usual guards (compression_ratio_threshold, temperature fallback, VAD) it occasionally slips through — and then the LLM cleanup step dutifully chews on a thousand repeated tokens, wasting ~10 seconds.

The fix that actually held: a deterministic post-processing guard that collapses any short unit repeated 6+ times in a row down to a single occurrence. Normal speech never does that, so it's safe — and it stops the garbage from ever reaching the user or the LLM.

3. Fixing the clipped first word with "preroll"

The instant you press the key, mic driver start-up latency eats the first syllable ("…ello" instead of "Hello"). The fix: keep an always-on ring buffer running, and when you start a take, prepend the ~0.3s before the keypress. First word intact.

4. Keeping the local LLM from "improving" too much

Left alone, a local LLM loves to paraphrase — and sometimes to translate. The first time my Japanese came back as English, I was surprised. Beyond a hardened "preserve wording, never translate, minimal edits" prompt, I added a deterministic language guard: if the input contains CJK but the output dropped all of it (or vice-versa), the LLM result is discarded and rule-based formatting is used instead. For dictation, predictable beats clever.

5. Packaging CUDA into a standalone .exe

"Anyone can use it" means a build that runs without Python or git. PyInstaller handles the app, but the CUDA DLLs (cuBLAS/cuDNN) are the tricky part. CTranslate2's loader only searches its own package directory and the bundle root — not arbitrary subfolders — so the DLLs have to sit at the root. On top of that, PyInstaller's nvidia hooks were collecting the same DLLs into a second location; dropping those duplicates saved ~650 MB. Final result: a ~1.2 GB zip you can download, unzip, and run.

Try it

# A) Download (no Python needed)
#    Grab Koe-win64-cuda.zip from the Releases page, unzip, run Koe.exe

# B) From source
git clone https://github.com/dkamehat/Koe.git
cd Koe
.\setup.ps1
.\run-admin.bat

Tap Right Ctrl once to start, speak (pause and think freely), tap again to stop → cleaned text lands in the focused app.

What's next

With the foundation in place, I'm prototyping a live meeting interpreter on the same local stack — local English subtitles + Japanese translation for the other side of a Zoom/Meet call. The hard part is WASAPI loopback capture and streaming endpointing. More on that later.

Closing

You can build genuinely useful voice input without giving up "local-only and safe for anyone." A surprising amount of the work was chasing unglamorous culprits — the biggest "slowness" was DNS resolution, not the model. Measure first, then fix.

Repo: https://github.com/dkamehat/Koe — feedback very welcome.