feat(security): scoped feed tokens — design + implementation + hypothesis-based scope parser fuzz (tracking)

[cmeans-claude-dev]

Tracking issue for a future feature surfaced as potentially on the beta roadmap: scoped feed tokens — user-issued API tokens that grant read (or limited write) access scoped to a subset of the owner's data.

Chris flagged 2026-04-22 that this is planned future work. Filing a tracking issue so it's visible alongside the other security roadmap items even though implementation is deferred.

Concept (as surfaced so far)

GitHub-PAT-style tokens:

• Owner mints a token via CLI / dashboard
• Token carries a scope (syntax TBD — tag filters, source filters, type filters, read-only flag, etc.)
• Edge collectors / external readers present the token to reach only what the scope allows
• Revocable and expirable independently of the OAuth session

Distinct from the existing OAuth session infrastructure (which is auth-dance state, not user-facing API tokens).

Sub-work (place-holder checkboxes — expand when design firms up)

• Design spec — scope string grammar, server-side enforcement point (middleware vs. store layer), revocation story, token storage (hashed-at-rest), TTL defaults
• Implementation — mint/list/revoke CLI (mcp-awareness-token?), middleware validation, scope-filter at the store layer
• Migration — new table for issued tokens, owner-scoped under RLS
• Test: scope parser fuzz — hypothesis-based property tests that generate random scope strings and assert the parser accepts only well-formed scopes + each well-formed scope restricts to its declared subset (no broader access leaks)
• Test: cross-scope leak — mint tokens at scope A and scope B for the same owner, assert A cannot reach B's subset and vice-versa (inside-owner isolation, in addition to cross-owner isolation which the main RLS harness covers)
• Docs — docs/security/feed-tokens.md covering token lifecycle, scope grammar, rotation guidance

Related

• CD recommendation 2026-04-22 (verbatim): "Scoped feed tokens: mint tokens at varying scopes, assert each can only reach what it should, fuzz the scope string for parser edge cases."
• Parent roadmap: security-tooling-roadmap-2026-04-22 (id 0d4007ce) — Update CHANGELOG through PR #8 #9 on the ranked list, "scoped-token scope parser fuzz (hypothesis)" was under the assumption this feature existed; actually depends on the feature itself being built first.
• Related features: feat(security): action gating foundation (Never/Ask/Always) with in-chat Ask #329 (action gating), feat(security): prompt-injection Phase 1 — directive entry type, scan_status, execute-mode retrieval #306 (prompt-injection Phase 1), feat: REST/HTTP interface for edge collectors (beta blocker) #307 (REST/HTTP for edge collectors — may be the natural consumer surface for feed tokens).
• Existing OAuth session infrastructure (session_*.sql files) is auth-dance state, not this. Different surface.

Acceptance (this tracking issue closes when)

• Design spec merged
• Implementation merged
• Scope parser fuzz + cross-scope leak tests landed
• Docs published