security: add gitleaks secret scanning GitHub Action

[RexOwenDev]

Summary

Adds gitleaks secret scanning on every push + PR. Pure prevention layer — no existing issues to fix.

Scan baseline

This repo was scanned during a portfolio-wide audit. Came back clean — zero hardcoded tokens, zero internal infrastructure URLs, zero PII. The codebase already uses environment variables for all credentials (ANTHROPIC_API_KEY, OPENAI_API_KEY, COHERE_API_KEY, Supabase keys via @supabase/ssr), which is the correct pattern.

What's added

.gitleaks.toml — custom ruleset

Extends gitleaks defaults with rules specific to this stack:

• Supabase service-role JWT detection (critical — this key bypasses RLS, which is a core security boundary of this app)
• OpenAI API keys (sk-...)
• Cohere API keys (scoped to .env paths)
• Anthropic API keys (sk-ant-...)
• Generic signed JWTs (catch-all for human review)

Allowlist prevents false positives on:

• .env.example templates
• Test fixtures and mocks
• Placeholder tokens like [ANTHROPIC_API_KEY], sk-ant-YOUR_KEY

.github/workflows/gitleaks.yml — GitHub Action

Runs on every push/PR across all branches. Posts findings to PR comments + GitHub Security tab.

Why this matters for RAG specifically

A leaked Supabase service-role key on a RAG app is worse than on a typical SaaS app: it bypasses all RLS policies, meaning an attacker with the key can read every workspace's documents and conversations — the entire knowledge base, across all tenants. The custom supabase-service-role-key rule specifically catches this.

Test plan

• Merge this PR
• Next PR should show a green "gitleaks" check
• (Optional) Intentionally test by creating a throwaway branch with a fake sk-ant-ABC123... — verify Action catches it — then delete the branch

---

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com