security: restrict code-introducing settings to trusted scopes at run time

[sadlilas]

Problem

Running amplifier inside a directory applies that directory's .amplifier/settings.yaml with no trust prompt. Project-scope settings are merged into the effective configuration on the run/prepare path, and several of those settings are code-introducing — they tell Amplifier where to fetch module or bundle code from. A cloned or downloaded folder can therefore silently redirect Amplifier to fetch and execute attacker-controlled code the moment a user opens a session in it. No prompt, no opt-in.

The code-introducing settings are:

• sources.modules / sources.bundles — per-identifier source overrides
• modules.<category>[].source — module registrations carrying a source: URI (e.g. modules.providers[].source)
• bundle.app and added-bundle URIs
• bundle.active — the active-bundle selector, whether it is a raw URI (git+ / file:// / http(s):// / zip+) loaded directly as code, or a bare name that resolves into the working directory's .amplifier/bundles/ (see below)

Fix

Split settings into two trust tiers and read code-introducing settings from the trusted merge only (global + session scopes) on the run/prepare path, while leaving non-code policy (model selection, config overrides, display prefs) on the full merge so a folder can still customize behavior that cannot introduce code.

• AppSettings grows get_trusted_settings() and a trusted_only= parameter on every code-introducing accessor (get_module_sources, get_bundle_sources, get_app_bundles, provider sources). Run/prepare callers pass trusted_only=True; management/display commands keep full visibility.

• CLISettingsProvider.get_module_sources and get_effective_provider_sources read modules.<category>[].source registrations from the trusted merge only.

• The module resolver no longer silently falls back to the full merge when a settings provider is asked for trusted sources — trusted_only is part of SettingsProviderProtocol, so a non-conforming provider fails loud rather than serving untrusted sources.

• Sub-session resume refreshes provider credentials by re-reading provider overrides and splicing them into the resumed config; this read also uses the trusted merge only (trusted_only=True). Resume does not assume a clean working directory, so a folder-scope provider entry — including one carrying a code-introducing source: — cannot be merged into a resumed session's provider config.

• The active-bundle selector is gated at a single chokepoint that covers both ways it can introduce code from the working directory. get_active_bundle() honors a selector only when it cannot load attacker code from the cwd:

  • A raw URI (git+ / file:// / http(s):// / zip+) is loaded directly by the bundle loader, bypassing trusted discovery — it is code introduction — so it is honored only when a trusted scope (global/session) set it. A URI appearing only in project/local scope is dropped.
  • A bare name normally resolves against the bundle registry, which is read trusted-only — safe. But bundle discovery also searches Path.cwd()/.amplifier/bundles/ at the highest filesystem precedence. A name with no trusted registry entry therefore resolves into the possibly-cloned working directory and loads attacker-authored bundle code (system prompt, which tools are active, context, and module source: URIs that get pip-installed — RCE) — the same threat as a URI, reached by name. The gate asks the bundle loader's own resolver (resolve_bundle_in_path, shared with discovery's _find_in_path) whether the name resolves into the cwd, so it covers every form the loader would load \x97 directory bundles (<name>/bundle.md, <name>/bundle.yaml) AND single-file bundles (<name>.yaml, <name>.md) \x97 and cannot drift from the loader. A name is dropped when it would resolve into the cwd unless a trusted scope selected it.

  In both cases a dropped selector falls back to the trusted selector or None. Every run-time bundle-loading caller (run, tool, update) routes through this one gate; management/display reads of bundle.active are scope-finders, not load paths, and are unaffected. An explicit --bundle flag bypasses this gate entirely as a per-invocation, user-initiated trust decision.

Management commands (module add, source add, bundle add, provider use, bundle use) are unchanged: explicitly running a command to register a source or select a bundle is intentional user action, distinct from a folder doing it silently on session open. To use a specific code-introducing bundle for a project, add it to the global list first, then select it by name — the name resolves trusted-only (registry), so the selection works without re-introducing the folder-trust hole.

When a folder-origin code-introducing setting is silenced on the prepare path — including a dropped bundle.active selector, whether URI or cwd-resolving name — config preparation prints a one-line notice so the drop is visible rather than mysterious.

Tests

tests/test_folder_config_trust_boundary.py covers each code-introducing setting: project scope is excluded under trusted_only=True, global/session scopes remain honored, and non-code policy still merges from the folder. Includes the modules.providers[].source vector (project excluded, global honored, novel folder-introduced provider rejected) and the full bundle.active selector matrix:

• Raw URI in project/local scope dropped; project URI falls back to the trusted selector; global raw URI honored.
• Bare name in project/local scope that resolves into the cwd's .amplifier/bundles/ dropped — directory forms (<name>/bundle.md, <name>/bundle.yaml) AND single-file forms (<name>.md, <name>.yaml); falls back to the trusted selector.
• Trusted (global) scope selecting a name honored even when a cwd bundle dir of that name exists.
• A name with no cwd bundle dir still honored from project scope — the common, safe case is unaffected.

tests/test_resume_credential_refresh.py covers the resume path: a folder-scope provider source: is excluded from the trusted read the credential refresh performs and never survives into the resumed config, the trusted global credential still refreshes, and a guard pins the trusted_only=True read at the resume call site against revert.