security: track H2 router security hardening across auth, feedback, and Looper paths

Summary

Coordinate H2 security hardening across trusted identity, feedback integrity, Looper/plugin boundaries, tool execution, learning inputs, and policy bypass risk.

Parent roadmap: #2287
Child issues: #1443, #1445, #1452, #1456
Related: #1146, #1388, #2286, #2336, #2342, #2362, #2463, #2464, #2465, #2466

Important package boundary

src/semantic-router/pkg/authz resolves credentials for upstream/provider access. It is not the router's RBAC/governance policy engine.

Authorization-related routing signals and decisions belong in validated config/classification/DSL/ext_proc surfaces. Tool-call final authorization must also be enforced at the external execution gateway (#2547).

Scope

Track and coordinate:

• trusted, impersonation-resistant caller/tenant identity;
• management/config/feedback API authentication and abuse prevention;
• Looper/Fusion/ReMoM header, breadth, token, concurrency, and plugin-boundary safety;
• replay/diagnostic redaction and content-free security reasons;
• SSRF, reusable browser token, route-bound dashboard auth, and management API hardening;
• poisoning-resistant learning/outcome inputs;
• request-side tool visibility plus execution-boundary RBAC;
• E2E/security regression coverage and release gating.

Cross-cutting follow-ups

• #2543 — bounded session/caller risk research; depends on trusted identity
• #2547 — tool RBAC across router filtering and execution gateway
• #2548 — privacy-bounded shared reputation research with an explicit trust domain
• #2549 — typed behavioral commitment policy state
• #2558 — governance-as-code ownership and hard-constraint precedence

Router Memory must not become a security reputation/policy database. Router Replay evidence and any security aggregate must be typed, content-minimized, TTL-bound, isolated, and poisoning-aware.

Non-goals

• No identity derived from prompt text or arbitrary caller headers.
• No router-only claim of pre-execution enforcement for externally executed tools.
• No cost/latency/energy objective may weaken authorization or safety.
• No raw sensitive payload in ordinary metrics or diagnostic reasons.
• No public exploit detail beyond what is required to test and fix the issue.

Acceptance criteria

• Every security-relevant attribute has a trusted source and enforcement owner.
• API, dashboard, feedback, Looper, and execution-gateway boundaries are authenticated and regression-tested.
• Security decisions fail according to documented risk-specific semantics.
• Learning/reputation features state identity, poisoning, isolation, retention, and correction assumptions.
• Audit/replay explains policy effects without leaking protected content.
• Hard authorization/safety precedence is exercised in E2E tests.
• Child issues have owner, priority, release impact, and safe fallback/rollback.