"'I can reach it' and 'I'm allowed to change it' are two different sentences. Systems that confuse them break in production."
Reachability is a network fact; authority is a capability fact
That you can open an SSH session to a machine tells you the network let you in. It says nothing about whether that session can unlock the login Keychain, raise a GUI approval dialog, or write as the volume owner. Reachable and authorized are different axes, and treating a green connection as a blanket permission is the root of a whole family of failures.
Headless never assumes
So a launchd or SSH executor must not assume login-Keychain, GUI-session, or volume-owner access. Those are declared capabilities it may or may not have — never defaults it helps itself to. The safe posture is: assume the least, declare what you actually hold, and let preflight decide whether that's enough.
Volume-owner is the sharpest case
The clearest example is a macOS system update. An update executor can stage and resume typed work, but it never stores or invents volume-owner authorization; the bootstrap-token and interactive-owner paths stay explicit capabilities. It doesn't bypass Apple's rules, and it doesn't tuck away a credential to make a future run easier. If the envelope lacks the authority, the honest answer is to stop and say so — not to manufacture the missing right.
The gap is handled, never papered over
When an envelope can't satisfy a step, there are exactly two acceptable moves: send the target to needs_attention, or delegate to a compatible executor. Never loop credential prompts. Never copy a secret into the operation to smuggle it across the gap. Never let host identity stand in for credential availability. The mismatch is a fact to report, not a wall to tunnel under.