security: Invariant #14 durableBindings has zero server-side readers — enforcement lives entirely in the agent it distrusts (#460 closed on the producer half)

[szhygulin]

Verified against canonical agenthill main 504dac0.

Defect

src/security/durable-binding.ts is 96 lines: DurableBindingKind enum, makeDurableBinding factory, canned provenance strings. No comparison. No validation. No throw.

Producers write it — morpho ×6, uniswap-v3 ×3, btc multisig (:432). Readers: zero in src/signing/ or src/security/.

The nuance that makes it worse, not better

durable-binding.ts:11-15 states by design that the skill consumes it. So this is not an oversight — it is a named security invariant (#14) whose entire enforcement lives in the agent.

That is the one party Invariant #14 exists to distrust.

#460 closed on the producer half. The consumer half is the half that enforces anything, and it is outside the trust boundary.

Why it matters

A binding that is only ever written and never read is indistinguishable, at runtime, from not existing. A compromised or lazy agent skips the check and nothing in the server notices. The invariant reads as enforced in the code and in docs; it is not.

Options

1. server-side reader that actually compares the binding and refuses on mismatch — makes Add Base network support (chainId 8453) #14 real
2. keep skill-side consumption but add a server-side falsifier proving the skill ran the check (hard: same class as the userDecision problem)
3. downgrade Add Base network support (chainId 8453) #14 from invariant to advisory in docs and stop counting it as a control

Same class as #763 / #766: a named guarantee whose code does not deliver it.

Related: #460 (closed on producer half), #763, #766.