security(mcp): required_permission() default-allows at runtime for undeclared tools — #13228 stage 3 #14523

Problem

autobot_shared.auth.mcp_tool_permissions.required_permission() default-allows
at runtime in both branches it can return, and #14494 (CI-time declaration
coverage) does not touch either one:

• A tool absent from TOOL_PERMISSIONS on a known bridge (one of the
  eleven BRIDGE_DEFAULT_PERMISSIONS keys) resolves through the bridge's
  default — a real, grantable read permission, not a refusal. Pinned
  intentionally by
  mcp_tool_permissions_test.test_an_undeclared_tool_on_a_known_bridge_inherits_the_least_privilege.
• A tool on an unknown bridge resolves to None. PermissionEnforcementExtension.on_before_tool_execute
  currently treats None as "legacy — allow through", with no check at all.

So a tool that reaches production without a CI run having caught it — on a
twelfth bridge, or declared in a source shape
autobot_shared.auth.mcp_bridge_scan does not recognise — is exactly as
under-granted as select was before #14469, just not caught by the guard
#14494 added. #14494's guarantee is complete CI-time coverage across the
eleven governed bridges, backstopped at runtime only by the read-level
default; it is not a runtime denial. (Raised in the #14521 security review,
which otherwise approved that PR.)

This is the runtime half of #13228 stage 3, deliberately deferred rather than
folded into #14494: it changes live MCP authorization behaviour for every
existing "legacy" tool, and deserves its own review.

Two options, either closes this

1. Flip to deny-by-default. required_permission() returns None for
   any undeclared tool regardless of bridge (not only an unknown one), and
   PermissionEnforcementExtension denies on None for MCP dispatch instead
   of allowing it through as legacy. Requires confirming every currently-live
   tool actually has a declaration first (security(mcp): the under-grant guard infers 'mutating' from a hand-written verb list, so a differently-named mutating tool inherits read-level permission silently #14494 makes that true today) and
   deciding how a bridge added without updating BRIDGE_DEFAULT_PERMISSIONS
   fails — probably the same way test_every_bridge_has_a_default already
   expects.
2. Document the default-allow as deliberate, if there's a reason runtime
   enforcement should stay permissive independent of the CI guard (e.g. a
   migration/rollout concern) — state it in the module docstring and close
   this without a behaviour change.

Also worth fixing while in this code

• DISCOVERY_FLOOR = 90 in tools/lint/check_mcp_tool_permission_coverage.py
  is a single global floor over all bridges combined. A genuinely new tool
  declared in a syntax mcp_bridge_scan does not recognise contributes zero
  to the count and is invisible to both undeclared_tools() and
  stale_declarations() — it would not trip a 104 → 103 drop against a floor
  of 90. A per-bridge floor that fails when any known bridging bridge's own
  tool count drops (rather than only the sum) would close this gap.
• TOOL_PERMISSIONS is keyed by tool name alone, not (bridge, tool). Zero
  collisions today across all 104 tools on the eleven bridges, but nothing
  stops two different bridges' tools sharing a name and one of them silently
  taking the other's permission. Worth stating as a documented constraint (or
  guarding against) before a twelfth bridge arrives.
• MCPDispatcher.dispatch() still carries the original seven-substring
  _ADMIN_ONLY_TOOLS blocklist MCP tool calls bypass canonical RBAC — three parallel authorization models, default-allow blocklist #13228 was meant to replace. Not a bypass
  today (enforcement runs before dispatch), but it is now duplicate logic and
  a cleanup candidate once option 1 above lands.

Related

• MCP tool calls bypass canonical RBAC — three parallel authorization models, default-allow blocklist #13228 — MCP tool governance (this is stage 3, the runtime enforcement)
• security(mcp): the under-grant guard infers 'mutating' from a hand-written verb list, so a differently-named mutating tool inherits read-level permission silently #14494 / security(mcp): declare every tool's permission, retire the verb-list under-grant guard (#14494) #14521 — CI-time declaration coverage; this issue is its
  explicitly-deferred runtime half, per the security review on security(mcp): declare every tool's permission, retire the verb-list under-grant guard (#14494) #14521
• security: PermissionEnforcementExtension has no coverage for execute_command, browser tools, or web_search #14469 / fix(security): thread RBAC role into execute_command/browser/web_search dispatch (#14469) #14492 — the select/select_index under-grant this whole chain
  traces back to