Security model
MotherShy's security posture is built on three principles: fail-closed, zero key custody, and offline verification.
Fail-closed
Every authority decision fails closed:
- Wall verification — if a request can't be verified, it's blocked. No fail-open path leaks content.
- Domain verification — no keys for a domain you can't prove you control.
- Online capabilities on offline walls — rejected (
online verification required), never silently downgraded to trust. - Nonce safety — a nonce that isn't a JS safe integer is rejected, not rounded.
The one deliberate fail-open: serving content to humans. If the wall can't classify a User-Agent, it errs toward letting humans through — because a false block on a human reader is worse than a missed agent.
Zero key custody
MotherShy never holds a private key it doesn't have to:
| Key | Where | Held by |
|---|---|---|
| Agent signing key | Client | Agent only |
| Publisher signing key | Client | Publisher only |
site_secret (HMAC) | Server-issued | Shown once, write-only after |
| Mother root | Server | Mother (the one authority) |
A compromised wall cannot forge credentials — walls hold only a public root. A compromised MotherShy cannot forge a publisher's signature — it never held their key.
The wall is stateless and offline
Walls hold no secrets and phone home never. They:
- Pin a public root.
- Verify signatures offline.
- Need no live MotherShy to serve traffic.
This means a wall deployment can't leak secrets (there are none) and keeps gating even if MotherShy is down.
Threat model highlights
- Replay — blocked by
nonce+ anti-replay window (timestamp) + idempotent ledger crediting. - Cross-site spend — blocked by
aud/sitematching; a capability for site A is rejected at site B. - Impersonation — blocked by the root→agent birth certificate; only the Mother can mint a recognized identity.
- Budget escape — blocked by
amt_microusd ≤ cap_microusd. - Revocation — offline caps rely on expiry; online caps add revocation + reservation (Cloudflare path).
The differential harness
All six wall form factors share a byte-identical trust core. A differential harness mints one corpus of envelopes and asserts all six implementations agree on every verdict — so a divergence in any one wall is a bug, not a "form-factor difference."