feat(rules): add Pinecone and LangSmith API key detection rules - #2177

Summary

Adds two new high-confidence Gitleaks rules — pinecone-api-key and langsmith-api-key — covering credentials for the vector-database and LLM-observability layers that now sit at the centre of most RAG/AI stacks. Both rules anchor on vendor-issued, structurally distinctive prefixes, so they detect real leaks while keeping false positives near zero.

Problem / motivation

Gitleaks ships rules for the AI model providers (Anthropic, OpenAI, Cohere, Hugging Face, Perplexity, Bedrock) but has no coverage for the retrieval and observability tier those models depend on. A leaked Pinecone or LangSmith key is not a low-value finding:

• Pinecone keys grant read/write access to the vector indexes that store an application's embedded private data. A compromised key enables silent exfiltration of the underlying corpus and index poisoning of downstream retrieval.
• LangSmith keys (personal access tokens and service keys) expose tracing data — full prompts, completions, tool I/O — plus the ability to act against connected LangChain/LangGraph workloads.

Both are routinely committed to .env files, notebooks, CI config, and IaC, and today pass through Gitleaks undetected (at best they trip the noisy generic-api-key rule, which yields a generic finding with no provenance).

Change

Following CONTRIBUTING.md exactly:

• cmd/generate/config/rules/pinecone.go — PineconeApiKey()
• cmd/generate/config/rules/langsmith.go — LangsmithApiKey()
• Registered both in cmd/generate/config/main.go (alphabetical ordering preserved).
• Regenerated config/gitleaks.toml via go generate ./cmd/generate/config/.

Both rules use GenerateUniqueTokenRegex, consistent with the existing prefix-anchored AI-provider rules (anthropic.go, openai.go), because the token prefixes are themselves the high-signal identifier:

An entropy = 3 floor is set on both to suppress low-entropy placeholders and documentation samples.

Security rationale

• OWASP LLM Top 10 (2025) — LLM02: Sensitive Information Disclosure and LLM03: Supply Chain: the vector store and tracing backend are the two components where an AI application's private data and prompt logic concentrate; credential leakage here maps directly to these risks.
• CWE-798: Use of Hard-coded Credentials — the exact weakness these rules surface in source control.
• MITRE ATT&CK T1552.001 (Unsecured Credentials: Credentials In Files) — the technique these findings interdict pre-commit.
• Prefix-anchored matching (rather than keyword-proximity heuristics) keeps the false-positive rate negligible, which is the bar for a default-config rule.

Testing / validation

• go generate ./cmd/generate/config/ — succeeds; the generator runs Validate() (true-positive + false-positive assertions) against every rule and exits non-zero on any failure. Both new rules pass.
• go build ./... — clean.
• go test ./cmd/generate/... ./config/... — pass (the config test parses the regenerated gitleaks.toml).
• End-to-end gitleaks detect against a fixture:
  • Positives detected: pcsk_<6>_<63>, lsv2_pt_<32>_<10>, lsv2_sk_<32>_<10> — each attributed to the correct rule.
  • Negatives not flagged: truncated pcsk_abc_tooshort, a generic eyJ... JWT, a legacy ls__ key (deprecated 2024-10-22), and a malformed lsv2_xx_... type segment.

Checklist

• Does your PR pass tests?
• Have you written new tests for your changes? (tps/fps embedded in each rule, enforced by the generator)
• Have you lint your code locally prior to submission? (gofmt)