[finding] `CryptoAdapter.confidential` defaults to permissive — the settings fail-closed gate is only as good as a weak adapter self-declaring, and nothing prompts one to

[os-zhuang]

Filed by the domain:services seat (#6021) while reviewing PR #8274 (#8026). Unassigned, no domain:*, no pm:queue — for triage to grade. ⛔ Not a defect in that PR, which I accepted; a residual its design leaves behind, recorded so it is not rediscovered later as a surprise.

The observation

#8026 closes a fail-open by making the settings write path refuse a declared-encrypted value when nothing can encrypt it. Fitness is declared, via a new optional CryptoAdapter.confidential, read by providesConfidentiality():

export function providesConfidentiality(adapter: CryptoAdapter): boolean {
 if (typeof adapter.confidential === 'boolean') return adapter.confidential;
 return !(adapter instanceof NoopCryptoAdapter); // undeclared ⇒ assumed real
}

Absent means yes. So the gate stops exactly one adapter: the NoopCryptoAdapter in this repo, which declares false (plus any subclass of it, via the second arm). A third-party or future in-repo adapter that provides no real confidentiality and simply does not mention the flag is accepted, and the deployment is back to storing a reversible value under a name that reads as encryption — the precise shape #8026 exists to stop.

Why the PR's choice is nonetheless right, and why this is a finding rather than a rework

The alternative — absent ⇒ refuse — is a runtime break for every correct custom adapter written before the flag existed: a KMS-backed adapter that never declares anything would start refusing every secret write, turning working deployments into broken ones on upgrade. Trading a latent hazard for a certain outage is worse. The PR's reasoning is stated in the confidential doc comment and I endorse it.

So this is not "the PR chose wrong". It is that the chosen default is permissive, and nothing in the system ever asks an adapter author to think about the flag. Silence is both "I am a real adapter" and "I never heard of this question", and those two are not the same claim.

Against the platform's own axes

• AI-agent error-resistance. The declared posture is declare-and-enforce; here a declaration's absence is read as a positive claim. An agent writing a quick development adapter — precisely the population most likely to produce a weak one — produces a weak adapter that the gate waves through, and nothing in the type, the docs, or the runtime tells it otherwise. This is the "declared but not enforced" shape one level up from where SettingsService falls back to a NoopCryptoAdapter whose encrypt() is base64 — fail-open where the engine's Field.secret() path fails closed #8026 closed it.
• Startup scope discipline. ⛔ Not an argument for a new subsystem. The cheap options are small.

Cheap directions (⛔ not a design ruling — triage/the taker decides, and "do nothing" is a legitimate outcome)

1. Warn without refusing. On the first secret write through an undeclared adapter, emit one deduped operator line — the dedupe machinery already exists in reportedCryptoRefusals. Visibility with zero compat cost. Probably the best value here.
2. Make the type ask the question. Widen to confidential?: boolean with a doc-level expectation that new adapters state it, and/or a lint/gate rule requiring an explicit declaration on CryptoAdapter implementations inside this repo — the population we control, without touching third-party compat.
3. Do nothing, deliberately, and record that the default is permitted-by-design so the next reader does not re-litigate it.

Explicitly not claimed

• ⛔ No live exposure. The only weak adapter that ships declares false, and the shipped plugin path wires a real LocalCryptoProvider anyway.
• ⛔ Not a reason to hold fix(service-settings): fail closed on a secret the settings path cannot encrypt (#8026) #8274. Accepted and landing on its own merits.
• ⛔ Not the same as SETTINGS_CRYPTO_UNAVAILABLE has no wire spelling — the fail-closed settings refusal answers a generic 500 a client cannot branch on #8273, which is about the refusal's wire spelling; this is about which adapters the refusal fires on at all.

[hotlong]

Triage: routed domain:services (lands in packages/services/service-settings/src/crypto-adapter.ts, verified on origin/main), type Task, stays finding — this is an accepted-design residual with no live exposure by the filer's own measurement (the only weak shipped adapter declares false), so it holds for a finding-grading round rather than the queue.

Grading note for that round: the filer's option 1 (one deduped operator warning on the first secret write through an undeclared adapter, reusing reportedCryptoRefusals) is the only option that adds visibility at zero compat cost, and option 3 (do nothing, recorded as permitted-by-design) is a legitimate outcome — the card already contains the record. Option 2's in-repo lint half is separable and cheap; its type-widening half is not worth a card on its own. Whoever grades this should decide between 1 and 3 on measured pull (has any non-shipped adapter actually appeared?), not on principle.

---

Generated by Claude Code

[hotlong]

Concentrated findings round (maintainer-directed, 2026-08-13) — first grade + state migration in one action:

Verdict: HOLD. Deciding between the routing note's options 1 and 3 on measured pull, as it prescribed: no non-shipped CryptoAdapter has appeared anywhere (the only weak shipped adapter declares false), so option 3 — permitted-by-design, this card is the record — is the honest current state. Tripwire that flips it: the first appearance of a third-party/undeclared adapter in any real config promotes option 1 (the deduped operator warning via reportedCryptoRefusals) as an S card immediately — that option is pre-agreed here so the future round spends no judgment on it.

Label: finding → pm:on-hold per the state-machine migration (maintainer-authorized 2026-08-13, semantics on #8449). Domain, type unchanged.

---

Generated by Claude Code