Fail-Closed Secrets Safety

Use fail-closed security boundaries and secret-safe observability by default.

1) Auth/CSRF: never store or act on unverified callbacks

• Treat state (or equivalent anti-forgery token) as a required verification gate.
• Confirmation prompts must be allow-list gated (only a deliberate affirmative action proceeds); dismiss/close must cancel.
• If verification fails, do not persist tokens, do not update session/provider state, and return a safe error.

Example (deny-by-default, allow only explicit “Store”):

if (authNonce !== state) {
  const choice = await vscode.window.showWarningMessage(
    `Auth callback could not be verified. Store token returned from ${uri.path}?`,
    { modal: true },
    "Store",
  );
  if (choice !== "Store") return; // fail closed on dismiss
}
// proceed to store token only after verified

2) Authorization/ownership: never “silently takeover” security-critical actions

• For capabilities/clients/agents/tools, require an explicit compatible takeover contract.
• If the original owner/client is gone/detached, fail the request (do not pick an arbitrary first registrant).

3) Credentials/state updates: only override the specific credential channel you intend

• When updating provider auth from user input (e.g., pasted API key), clear/replace only the corresponding stored auth state that would otherwise win.
• Gate token/identity clearing on evidence of an actual sign-in state being replaced; avoid dropping identity for same-account rotations unless you also immediately repair via a follow-up fetch.

4) Sandboxes/path access: minimize writable roots and validate real boundaries

• Never grant write access to an entire ancestor like home, filesystem root, or the drive without a strict boundary check.
• Resolve real paths (handle symlinks if intentionally allowed) and fail closed when grants would escape the intended project directory.

5) Secret-safe logging: redact by policy, not by call-site hope

• In production, log only narrowly-scoped safe data (e.g., numbers/booleans and safe error messages), and never serialize arbitrary error objects/strings that may contain OAuth codes, API keys, file/terminal contents, or credential-bearing URLs.
• Always reduce URLs in logs to origin (or an even safer form) before emitting them.
• Error messages built from user-provided strings can leak secrets: fix at the source (don’t “scrub later”).

6) Sensitive-file handling: protect against “unknown filename” secrets

• Filename-only blocklists are incomplete; treat them as best-effort and prefer structural detection (path patterns, known secret directories) plus regression tests for previously missed secret types.
• If you add a sensitive-path list, ensure it has tests for multiple variations and deleted/renamed cases.

Adopt these as team coding standards: deny-by-default on security checks, no silent ownership/credential takeover, tight filesystem write boundaries, and redaction-first observability.