Struct ExecutionGate 

pub struct ExecutionGate;

The spec §7.1 execution gate: a pure, reusable authorization component evaluated immediately before tool implementation lookup/execution.

Order of checks (each fails typed, closed, without acquiring anything):

1. resolve wire name → exact live ToolId (deterministic reverse mapping; aliases cannot pick a different identity);
2. the identity must be cataloged;
3. the identity must be core (pinned digest intact) or hold an exact session activation grant covering (session, tool, digest) — see [grant_covers_execution]: catalog generation drift alone does NOT deny at execution time; only a real change to the called tool’s record (digest, presence, provenance) does;
4. the record’s CURRENT trust provenance must equal the provenance the session PINNED at core-build/activation time — this closes the coherent-imposter hole (same ToolId, schema-identical body, different but internally consistent source/provenance);
5. source trust is re-evaluated conservatively — see the honesty note on [check_source_trust]: this re-checks typed source/provenance consistency and denies Unknown/Unverified, but does NOT yet consult live manifest permission/revocation state (Task 20 integrates the permission/revocation policy);
6. side-effect/confirmation policy (interim: Unclassified is allowed only for verified-provenance capabilities — Task 24 adds real effect classes);
7. only then is the implementation acquired.

TOCTOU: callers must resolve, authorize, and acquire against ONE consistent registry borrow/lock guard — ExecutionGate::authorize_wire_call does exactly that for a &ToolRegistry held under the caller’s read lock.

Implementations

impl ExecutionGate

pub fn resolve( registry: &ToolRegistry, wire_name: &str, ) -> Result<ResolvedToolCall, ToolAuthorizationError>

Resolve an incoming API/wire name against one registry snapshot.

pub fn authorize( catalog: &ToolCatalog, session: &SessionToolSet, resolved: ResolvedToolCall, ) -> Result<AuthorizedToolCall, ToolAuthorizationError>

Authorize a resolved identity against one catalog snapshot and one session tool set. On success — and only then — the implementation is acquired from the catalog record’s factory and returned inside the typed AuthorizedToolCall. Failure acquires nothing and leaves the session set untouched (the gate never mutates it).

SECURITY INVARIANT (per-tool digest + provenance validation): no tool executes unless its CURRENT catalog record — presence of the exact ToolId, schema digest, and source/trust provenance — exactly matches what the session pinned at core-build/activation time. Catalog generation inequality ALONE is no longer a denial reason at execution time: an unrelated background mutation (e.g. a plugin load mid-round) must not kill in-flight calls to schema-identical tools. Any REAL drift of the called tool’s record — changed digest, removal, changed provenance (even to an internally coherent one) — still denies typed and closed.

ACCEPTED RESIDUAL RISK: SchemaDigest hashes the schema JSON only, not the implementation factory. A record replaced in place with an identical schema AND identical pinned provenance but a different implementation passes this gate; the exposure is bounded by the deterministic round-top rebuild (runtime/stream.rs), which re-pins the set against the current catalog between provider rounds.

pub fn authorize_wire_call( registry: &ToolRegistry, session: &SessionToolSet, wire_name: &str, ) -> Result<AuthorizedToolCall, ToolAuthorizationError>

Resolve + authorize + acquire against ONE registry borrow (one consistent snapshot under the caller’s read lock — no TOCTOU between resolution and implementation acquisition).