[security] ${VAR} interpolation in tycoon.yml is an env-var exfiltration vector (Medium)

[db-tycoon-stephen]

Summary

tycoon.yml strings are run through ${VAR} / ${VAR:-default} expansion against the victim's full os.environ (_interpolate_recursive, applied to the entire parsed config). A malicious shared project can place ${MOTHERDUCK_TOKEN}, ${AWS_SECRET_ACCESS_KEY}, etc. into any field. The expanded secret then flows into generated files (nao_config.yaml, RULES.md, dbt/Rill YAML), is sent to the configured LLM provider, or is included in the notify webhook payload — all exfiltration channels.

Evidence

• src/tycoon/project.py:90-110, 306 — _interpolate_recursive over the whole tycoon.yml

Threat model

Victim runs almost any tycoon command inside a shared project → silent exfiltration of their environment secrets.

Fix

• Restrict interpolation to an allowlist of fields where it's intended (connection strings the user explicitly authored), or refuse to expand env-var names matching a secret-looking pattern.
• At minimum, never echo expanded secret values into generated artifacts or network payloads, and document the behavior.
• runner._check_unexpanded_env_vars already warns on unexpanded vars; the inverse (warn on unexpected expanded vars) would help.

Severity: Medium

[db-tycoon-stephen]

Mirrored in Jira: PTC-34 (Epic: PTC-31 — Security hardening). Dev work continues here.

[db-tycoon-stephen]

Scope update after the v0.1.10 refactor (PR #147): still valid — _interpolate_recursive runs over the whole tycoon.yml in src/tycoon/project.py — but two of the cited exfiltration channels are gone with the ask/nao removal (nao_config.yaml/RULES.md generation and the LLM-provider request path). Remaining channels: generated dbt/Rill YAML and the notify webhook payload. Severity arguably drops a notch; the root-cause fix (#65's validation layer plus an interpolation allowlist) is unchanged.