Fuzzing & Security Testing

Problem

Standard tests only cover "expected" inputs. Malicious or malformed data could still trigger memory leaks, SQL injection, or crashes.

Describe the feature or change you'd like.

Any alternative approaches you've thought about.

Any mockups, examples, or references that help explain the request.

@taitelee

Triage note as part of the pre-alpha priority pass.

The current body is the issue template with the bullet points unfilled. Before this can be actioned, someone has to make three scope decisions:

What to fuzz — the JSON ingest payload validator (internal/discovery/)? The raw /v1/query SQL handler (more dangerous, smaller surface)? The structured-query AST builder (internal/query/)? The JWT claim path extractor (extractClaim in internal/api/middleware.go)? Each has different cost/value characteristics.
What tooling — Go's built-in go test -fuzz (cheap, in-tree, runs in CI under make test-fuzz)? Joining OSS-Fuzz (more thorough, more setup, only useful once the surface is stable)? Both, sequenced?
What "security testing" means here — fuzzing is one class. The body also mentions "memory leaks, SQL injection, authentication bypass" which are different exercises (long-running soak tests, dedicated SQL-injection fuzz corpus, auth boundary tests). Each is a distinct workstream.

Recommendation: split into 2–3 concrete sub-issues once decisions are made, and close this one as the umbrella tracker. As-is it's not actionable.

@taitelee — you opened this; want to weigh in on the scope cuts before someone tries to start it?