fix(security): remediate 2026-07-11 codebase security audit findings

[SoundMindsAI]

Summary

Batch remediation of the findings from a full-codebase security audit (six parallel audits: injection/command-exec, SSRF/egress, secrets/auth/webhook, frontend, CI/CD & supply chain, LLM/agent authz). No Critical findings existed in the single-tenant MVP1 threat model — these are the Medium/Low latent issues, most of which escalate once auth / remote deployment land.

#	Finding	Fix
1	Cluster-URL SSRF guard ran only at registration (DNS-rebinding TOCTOU)	Re-run the flag-gated guard on the reuse paths (acquire_adapter, reprobe_cluster, get_or_probe_health)
2	Query-DSL/JSON injection via raw {{ query_text }} in shipped templates (also a live JSONDecodeError)	Validator now requires query_text to flow through | tojson; fixed 3 shipped templates + demo-seeding bodies
3	Chat confirmation gate false positives + stale-proposal binding	Tightened is_affirmative (deferral/inability negations + anchored phrases); bound the gate to the immediately-preceding assistant turn
4/5	Fail-open ENVIRONMENT default + SSRF flag off in non-dev	Loud startup WARNs
5	No script-src CSP (frontend)	Enforce object-src/base-uri/form-action; ship script-src/style-src as report-only (nonce work deferred to GA)
6	Solr local-params ({!...}) injection via query_text on q	Neutralize a leading {! prefix on the user q (render path only)
7	No git-ref pattern on pr_base_branch/default_branch	Pattern-lock (blocks leading-dash git argument injection)
8	Chat tool-loop budget checked once per turn	Per-iteration budget peek before each completion
9	config_diff values unvalidated at PR-open	Reject wrong-typed values for numeric/bool declared params
10	CORS allow_credentials=True + wildcard footgun	Disable credentials when a wildcard origin is configured

Findings confirmed by the audits as already secure (webhook HMAC, secret handling, git subprocess argv discipline, no SQLi/SSTI, CI action pinning, React escaping) were left unchanged.

Scope note

Larger than a typical ad-hoc PR (cross-subsystem) — bundled deliberately as one security batch per request. No migration; Alembic head unchanged (0023).

Test plan

• make test-unit — 2873 passed (+30 new regression tests)
• cd ui && pnpm test — 1330 passed
• make lint && make typecheck (mypy + tsc clean; ruff format --check clean)
• bash scripts/regen-generated-artifacts.sh — ui/openapi.json refreshed (branch-field pattern)
• DB-backed contract/integration layers run against CI's Postgres service container

Notes

• Cross-model review: Opus self-review (GPT-5.5 unreachable in this environment); Gemini Code Assist is the live cross-family gate and its findings will be adjudicated per the four-quadrant rubric.
• Also fixes: a latent JSONDecodeError on any query containing " (rolled into finding docs: MVP1 architecture + 12 feature specs + GPT-5.5 review fixes #2).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request implements several security hardening measures addressing recent audit findings, including escaping leading Solr local-params, enforcing per-iteration LLM budget gates, validating git branch patterns to prevent argument injection, requiring | tojson filtering for query text interpolation, and adding SSRF re-validation on cluster reuse paths to mitigate DNS-rebinding. Additionally, the confirmation guard logic is refined, CORS credentials are disabled for wildcard origins, and CSP headers are strengthened. Review feedback suggests avoiding false negatives in the confirmation logic by checking for contractions like "can't" explicitly instead of using "can" as a negation token, and recommends using f-strings or structured logging instead of %s formatting in startup warnings.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Including "can" and "couldn" in _NEGATION_TOKENS causes false negatives for common, valid affirmative responses such as "yes you can" or "I can confirm". Since the [a-z]+ regex splits contractions like "can't" and "couldn't" into separate words, we should remove "can" and "couldn" from the token set and instead handle these contractions explicitly in is_affirmative.

Suggested change

	# Deferral / inability tokens — a reply that contains these is not an
	# authorization even if it also carries an affirmative token ("ok" in
	# "ok thanks", "do it" in "can't do it right now" / "do it later").
	"can", # can't (apostrophe stripped by the [a-z] regex) / "I can later"
	"cant",
	"cannot",
	"couldn", # couldn't
	"couldnt",
	"maybe",
	"later",
	# Deferral / inability tokens — a reply that contains these is not an
	# authorization even if it also carries an affirmative token ("ok" in
	# "ok thanks", "do it" in "can't do it right now" / "do it later").
	"cant",
	"cannot",
	"couldnt",
	"maybe",
	"later",

[gemini-code-assist]

To support removing "can" and "couldn" from _NEGATION_TOKENS (preventing false negatives on valid confirmations), we can explicitly check for "can't" and "couldn't" contractions in is_affirmative before evaluating other rules.

Suggested change

	# Affirmative *phrases* must LEAD the message (anchored) so a mid-sentence
	# "do it" in "I'll do it later" doesn't unlock dispatch — the leading
	# negation/deferral tokens above already reject most of those, this closes
	# the residual where no negation token is present.
	if _LEADING_AFFIRMATIVE_PHRASE.match(lowered):
	return True
	# Since the [a-z]+ regex splits "can't" into "can" and "t", we check for "can't" / "couldn't" explicitly
	# to avoid false negatives when "can" is used in a valid affirmative (e.g., "yes you can").
	if any(neg in lowered for neg in ("can't", "cant", "cannot", "couldn't", "couldnt")):
	return False
	# Affirmative *phrases* must LEAD the message (anchored) so a mid-sentence
	# "do it" in "I'll do it later" doesn't unlock dispatch — the leading
	# negation/deferral tokens above already reject most of those, this closes
	# the residual where no negation token is present.
	if _LEADING_AFFIRMATIVE_PHRASE.match(lowered):
	return True

[gemini-code-assist]

Using %s formatting with structlog loggers is discouraged and may not format correctly depending on the processor configuration. It is cleaner and safer to use an f-string or pass the environment as a structured keyword argument.

        logger.warning(
            f"RELYLOOP_ALLOW_PRIVATE_CLUSTERS=True on a non-development deployment "
            f"(ENVIRONMENT={settings.environment}): the cluster base_url SSRF guard is disabled, so "
            f"internal/metadata endpoints can be registered and probed. Set "
            f"RELYLOOP_ALLOW_PRIVATE_CLUSTERS=False to enable the guard.",
            event_type="ssrf_guard_disabled_non_dev",
        )

[SoundMindsAI]

Review adjudication (Gemini Code Assist)

Fixes landed in 482965a9.

#	Sev	Location	Verdict	Notes
1	Medium	backend/app/agent/confirmation.py:102	Accepted	Bare can/couldn in the negation set false-rejected valid affirmatives ("yes you can", "I can confirm"). Removed them; kept whole-word cant/cannot/couldnt.
2	Medium	backend/app/agent/confirmation.py:128	Accepted (variant)	Added an explicit apostrophe-form check for can't/couldn't. Used a can't/couldn't substring match (apostrophe makes it safe) rather than Gemini's raw cant substring, which would false-positive on "significant".
3	Medium	backend/app/main.py:119	Accepted	Switched the SSRF-guard WARN from %s interpolation to an f-string (structlog-safe).

Outcomes

• Applied (3): confirmation negation-token fix + apostrophe-form guard; structlog f-string. Regression cases added in both directions (yes you can → affirmative; cant do it / cannot do it / couldn't → not affirmative).
• Rejected (0) / Deferred (0).

CI note

One integration test — test_synthetic_ubi_seed_round_trip_hits_rung_3 — is red due to an Elasticsearch "Temporary failure in name resolution" flake in the CI runner, not this diff. The failing assertion is downstream of a passing pure-domain assertion (640 UBI events fabricated correctly); the seed→ES→read chain it exercises (fabricate_ubi_for_scenario, seed_synthetic_ubi, classify_rung) is untouched by this PR, and the same run shows ES unreachable elsewhere (test_documents_endpoints skipped with the identical name-resolution error). Every other job (unit, frontend, static-checks, docker×2, generated-artifacts, DCO, secrets-defense) is green.

Cross-model review: Opus self-review (GPT-5.5 unreachable in this environment); Gemini is the live cross-family gate.