---
status: open
opened: 2026-09-30
located-in:
  - mesh-controller internal/inventory/secrets.go (SecretFor mints a pair credential nobody accepted)
fixed-by:
amended-design:
---

# 164 — A credential that must be accepted is minted anyway

## What was observed

Provisioning ace's modules. Several providers hold exactly one credential they did not get from the
mesh and cannot take one from it: a Servarr app's API key (sonarr, radarr, lidarr), jackett's API key,
plex's X-Plex-Token, nzbget's ControlPassword, qBittorrent's WebUI password. Their consumers' pair
credential must be **accepted** by the operator (ADR 0092). Until it is, `SecretFor` mints a random
value, seals it to both ends, and reports nothing: the value can never work.

Every consumer therefore had to learn to detect it — try the credential against the provider first,
refuse a value the provider rejects, print the `secret accept` command — six write-in steps, one probe
each (ombi, home-assistant, and the four download-stack consumers). qBittorrent bans an address after
five failed logins, so a consumer retrying a minted value locks itself out.

## What would be right

A provision (or a provider's `serves`) can declare its pair credential **accepted-only**. The plan then
refuses the pair — naming the accept command — instead of minting, and a consumer is never handed a
value the mesh knows cannot work.