Summary

The gateway /hooks/agent and /hooks/<mapping> request paths rebind the session key (for example agent:main:* → agent:hooks:*) without re-checking allowedSessionKeyPrefixes against the rebound key. An authorization scoped to the original prefix is not re-validated after the rebind.

Impact

HIGH-ish. A caller authorized for one session-key prefix may, after the rebind, operate under a prefix it was never authorized for. The prefix allowlist is enforced on the original key but not re-enforced on the remapped key.

Expected behavior

After rebinding the session key, re-validate the rebound key against allowedSessionKeyPrefixes. If the rebound key no longer matches an allowed prefix, reject the request (400 / unauthorized).

Fix sketch

Add a post-rebind prefix re-check in the /hooks handler path, after the session-key remap and before the request is allowed to proceed.

Why this was deferred

Restoring the check flips currently-accepted requests to 400 — a behavior / security-semantics change that must not ride a make-the-suite-green change. The covering tests were removed with a documenting comment in src/gateway/server/hooks.test.ts (~lines 538 and 564); restore them as part of this hardening.

Acceptance criteria

• Post-rebind requests whose rebound session key violates the prefix allowlist are rejected.
• The documented hooks.test.ts cases are restored and pass.