adom-desktop-altium-bridge

ab 2.0.96 (live now; fleet auto-updates within 4h) adds a new header to every verb request ab dispatches to your bridge. Additive and opt-in: nothing changes if you ignore it, but if your bridge has (or plans) any verb that should refuse remote callers, this is the signal to gate on.

X-Adom-Verified-Origin: relay | local | bridge

• Authored by ab itself from the transport it observed (the relay websocket vs the loopback direct API vs a bridge callback with a valid spawn token). A caller cannot supply or override it. This is the ONE origin header you may treat as a security signal; the X-Adom-Caller-* set remains self-reported attribution only, never authorization.
• relay = the command arrived over the cloud-AI relay. local = a loopback caller (local CLI, Hydrogen, a local agent). bridge = another bridge's callback.
• Two caveats before building a gate: (1) the value describes the LAST hop into ab, so a bridge callback made on behalf of a relayed thread arrives as bridge, not relay; give bridge its own policy and consult X-Adom-Caller-Delegate for anything sensitive. (2) A MISSING header means an unidentified local process POSTed to your loopback port directly; treat that as local-unattributed or refuse, never as relay-safe.

Verify after your target ab is on 2.0.96: log the header on any verb, call once locally and once through a container relay, and confirm you see local vs relay. Full contract: the "adom-bridge-sdk-callback" skill in the adom/adom-bridge pkg (2.0.96+). Context: adom/adom-bridge issue #114 (pup's credential-reveal verb needed an honest local-only gate).