Per-Attack Blocking Hides Catalog Vulnerability: A Weakest-Link Analysis of Tool Manifests

Runtime controls for tool-using agents depend on manifests that specify what each tool may read and where its output may go. ChainCaps shows that correct manifests can block permission laundering, but it reports one number, per-attack blocking, on 11 attacks in a fixed catalog. We argue that per-attack blocking is the wrong reporting unit for a composition-safety system, and we make the argument two ways. Analytically, if $M$ source policies are authored independently and each is wrong with probability $p$, the chance that a catalog contains at least one accepted exfiltration path is $1-(1-p)^{M}$, so the tolerable error rate for a fixed catalog target falls as $1/M$ while per-attack blocking stays at $1-p$. Empirically, we run every sensitive source once through a representative HTTP path in the public ChainCaps engine, over synthetic catalogs of 10 to 400 tools and 2,000 independently authored catalogs per cell, to test whether a real enforcement implementation deviates from that binomial. It does not: ChainCaps' transform pass-through gives no protective composition effect, so an 8% source-budget error rate leaves per-attack blocking near 92% while catalog vulnerability rises from 0.218 at 10 tools to 0.994 at 200. A dependence analysis marks the boundary: at 200 tools with $p = 0.08$, catalog vulnerability is 0.993 under 60 independent decisions but 0.08 under one shared decision, so raw tool count is not the scaling variable. A descriptive seven-model pilot adds excess channels in 42 of 63 sensitive-source decisions from tool descriptions and 27 of 63 with the policy supplied. The catalog-vulnerable rate is not a breach probability; it is the evaluation unit that per-attack blocking omits.