Module trust 

Trust tiers + static risk assessment for addons (#864).

Two orthogonal questions about an addon:

1. Trust tier — who vouches for it? TrustTier is conferred by the curated registry (addon.verified), never by the entry claiming it.
2. Risk — what does its wiring actually do? assess statically inspects the [mcp] block for signals that warrant a louder warning (remote endpoints, shelling out, unpinned upstreams, secret-bearing env).

Both are pure + deterministic so the CLI preview, the registry validator and the install policy gate all read from one source of truth.

Structs

RiskFinding

One observation about an addon’s wiring.

Enums

RiskLevel

Severity of a RiskFinding, ordered Info < Warn < Danger.

TrustTier

How much an addon is trusted — set by the registry it ships in.

Functions

assess

Statically inspect an addon’s [mcp] wiring. Pure + deterministic; the returned findings are sorted by descending severity then code so output is byte-stable (provider prompt-cache friendly, #498).

max_level

The highest severity among findings, if any.

wiring_spawns_subprocess

Whether the wiring evidences spawning child processes — the command is a shell run with -c, a fetch/eval primitive, or any argument carries shell metacharacters that chain to another program. The capability audit (super::audit) uses this to flag an addon that declares no exec permission yet clearly shells out (an under-declared capability). HTTP addons run no local child, so this is stdio-only.

wiring_uses_network

Whether the wiring inherently performs outbound network I/O — an HTTP transport, or a stdio command that fetches/executes remote code or runs an unpinned package from a remote registry. The capability audit (super::audit) uses this to flag an addon that declares network = none but actually needs the network (an under-declared capability).