Pup - the AI's own browser
Public Made by Adomby adom
pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.
ab 2.0.96: new X-Adom-Verified-Origin header on every verb request (the one origin signal you may gate on)
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, notrelay; givebridgeits 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).