Feature request: supported pre-routing authorization hook for HTTP and MCP

[bagutzu]

Request

Please provide a supported extension seam that can authorize every incoming
HTTP and MCP transport request before native route handling. The hook should
receive method, normalized path, relevant transport headers and the existing
request context, and should be able to return an HTTP denial without replacing
or mutating native handlers.

Motivation

Hindsight's tenant and operation extensions cover bank operations well, but
some native surfaces answer before tenant authentication: utility routes,
generated documentation/OpenAPI, deprecated responses and MCP's no-session GET
probe. HttpExtension adds routers; it cannot attach a documented dependency or
middleware to existing routes. Undocumented FastAPI mutation would be brittle
for downstream operators.

Health and metrics exceptions vary by deployment, so a fixed upstream policy is
less useful than a supported fail-closed hook. Existing bank operation
validators should remain authoritative; this request covers transport admission
and route-level exclusions, not a replacement authorization model.

Proposed shape

A single pre-routing callback with an explicit allow/reject result is enough.
It should run for generated routes and MCP transport probes as well as ordinary
REST handlers, preserve normal extension configuration/lifecycle, and have
tests proving fail-closed behavior when the extension rejects or errors.

Related issue #2343 discusses broader auth profile and extension needs. This
request is limited to a supported pre-routing admission seam for existing
native HTTP and MCP handlers.

[nicoloboschi]

Thanks for the detailed write-up.

Having looked at this, I don't think we need a new pre-routing seam: the authorization path you're asking for already exists, one layer in.

TenantExtension.authenticate() runs on every operation. Every engine entry point calls _authenticate_tenant() before doing any work (~90 call sites), and raising AuthenticationError from your extension rejects the request fail-closed. That covers every bank, memory, recall, retain and admin operation over both HTTP and MCP — authenticate_mcp() is the MCP transport's own hook and runs before the session is established.

For per-operation rules, OperationValidatorExtension sits on top of that and receives the operation and bank id, so "this caller may read but not delete" is expressible today without touching routing.

What genuinely isn't covered is the handful of routes that never reach the engine — /docs, /openapi.json, /metrics, /health, and the MCP no-session GET probe. Those expose the API shape and liveness, not data, and whether they should be authenticated varies by deployment, as you note.

So: closing as not planned for now. If authenticate() is missing context you actually need — method, path, or other request metadata — that's a much smaller change and we'd be happy to take it. Open a focused issue (or comment here) describing the policy you can't express today and the request that should be denied, and we'll look at extending the hook's context rather than adding a parallel admission layer.