pub(super) fn verify_jekt_signature(
state: &AppState,
req: &mut InjectionRequest,
)Expand description
Host-tier jekt sender verification (SPEC_JEKT_TRUST_LAYER_COMPLETION_2026_08_13.md
§2.2). Mutates req.sig_verified in place based on whether the claimed
source_agent’s stored signing key (if any) verifies req.jekt_sig,
within the anti-replay freshness window.
Every entry point that can build a host-tier InjectionRequest from
client-supplied fields MUST call this before handing it to
Handler::inject_message — reagentx P0 on PR #2565 found two call
sites (messagebus.rs::handle_inject, websocket.rs’s bus:inject
message handling) that built InjectionRequest with a fully
client-controlled source_agent and called inject_message directly,
bypassing this entirely — those messages rendered TRUST=self-declared
(unescalated) exactly as if this feature didn’t exist. Both now call
this too.
Deliberately NOT gated on delivery_tier == "host" (reagentx P0 on
the LAN signing PR — this WAS gated that way originally, and it was the
bug): delivery_tier is a value this instance largely trusts as
self-declared by whoever authenticated with the full local auth_key
(needed so legitimate same-host forwarding can carry an already-"lan"
jekt through unmolested — see resolve_delivery_tier’s doc comment).
That means a request claiming delivery_tier: "lan" (or "wan") was
otherwise a way to dodge THIS check entirely — impersonate a real,
locally-known agent by simply not calling it “host,” since
verify_lan_signature/verify_reagent_signature only fire for their
own tiers and leave an unsigned claim unforced by design. Running this
check unconditionally closes that: it only ever does anything when
agent_jekt_key_load finds a LOCAL key for the claimed source_agent —
which is None for any genuinely-remote LAN/WAN sender this instance
never spawned (no behavior change for real network traffic), but
catches an unsigned/wrong-signature impersonation of an agent THIS
instance actually knows, regardless of what tier the request claims.