When handling auth secrets, user directory/path-based configuration, or shell-generated code, treat any value that could reveal identity/organization or execute code as sensitive and untrusted by default.

Apply these rules:

1) Define trust boundaries explicitly

• Secret-backed and command-backed values must be treated as inert data during Drive sync/preview/import/shared browsing/metadata rendering.
• Execute or substitute into a live shell session only after explicit user action (e.g., apply/export) and only for content the user owns or has explicitly chosen to trust.

2) Escape/serialize as data, never as code

• For shell code generation (e.g., Nushell): embed dynamic values using the shell-specific literal serializer/escaping contract (double-quoted literal rules, escaping of quotes/backslashes/control chars, and correct string/argument handling).
• Never construct executable snippets by concatenating raw dynamic strings. Prefer binding escaped literals to variables and passing them as arguments.

3) Redact sensitive logs and diagnostics

• Never log raw directory/path keys, secret-manager commands, or secret stdout/stderr.
• For path-derived keys (like directory override maps), log only a stable short redacted identifier (hash) plus non-sensitive value text when needed.

4) Don’t “silently weaken” authorization scopes

• If secrets are personal-scoped by default, ensure the system cleanly supports broader scopes only when explicitly modeled (e.g., team API keys) and never by accident.

Example patterns

A) Redacted warning message (path-key privacy)

fn warn_directory_override(key: &str, theme: &str) {
  let redacted = redacted_key_id(key); // stable short id; never reversible without a local salt
  log::warn!(
    "directory_overrides[hash={}] : unknown theme '{}' — skipping this entry until corrected",
    redacted,
    theme
  );
}

B) Inert secret/command snippets in untrusted flows

• During sync/preview/import: store the structured reference (or escaped literal placeholders) but do not persist rendered secret-manager commands or secret output.
• Only after user applies/exports into an owned/trusted execution context, render/execute and keep failure output free of secrets.

Enforcement checklist / tests

• Add tests that assert:
  • Logs/telemetry never contain raw sensitive strings (raw directory keys; rendered secret-manager command; secret output).
  • Shell-generated code treats dynamic values as literals (malicious strings with quotes/$()/’/newlines stay single-statement data).
  • Secret-backed values remain inert through preview/import until explicit apply.
  • Auth-secret scope changes are authorization-driven (no accidental escalation from defaults).