WAB Security Model

This page defines the cryptographic primitives, trust roots, and verification boundaries that the WAB protocol provides — and, just as importantly, what it does not guarantee. For the explicit adversary model see /threat-model.

1. Security goals

The WAB protocol is designed to provide, by construction, the following properties:

• Origin authenticity — agents can prove that a wab.json manifest, capability response, or ATP receipt was produced by the legitimate site operator (or someone holding its private key).
• Scope enforcement — every signed intent declares an explicit, auditable scope (actions, spend cap, expiry, single-use nonce). The server refuses anything outside the declared scope.
• Idempotency — for any (intent_id, idempotency_key) pair, the system executes at most once, regardless of retries, network partitions, or duplicate client submissions.
• Verifiable receipts — every transaction terminates in an Ed25519-signed JSON receipt that any third party can verify with no shared secret, via the public endpoint /api/atp/receipts/verify.
• Auditability — every accepted intent, transition, receipt and compensation is logged with an append-only nonce; the audit trail is replay-resistant by design.

2. Non-goals (what WAB does not claim)

The protocol is honest about its boundaries. The following are deliberately out of scope:

• Confidentiality of payloads at the application layer. WAB rides on TLS but does not add end-to-end encryption on top. If your intent body is sensitive, encrypt it at the application layer.
• Defense against a compromised site key. If the site's Ed25519 private key is stolen, the attacker can sign valid manifests and receipts until the key is rotated. See /key-rotation.
• Defense against a malicious site operator. WAB authenticates that an action came from the declared origin; it does not stop that origin from declaring malicious capabilities. Agents and users must still evaluate trust at the policy layer (Ring 4 trust graph helps).
• Network-layer DoS resistance. Rate limits and replay nonces protect against floods of signed requests; raw network DoS belongs to your edge (CDN/WAF).
• Cross-chain or on-chain finality. ATP provides cryptographic receipts, not consensus. Settlement on top of payment rails (Stripe, ACH, etc.) is handled by those systems and reflected in the receipt body.

3. Cryptographic primitives

4. Trust roots

The protocol intentionally has two distinct trust roots:

• Per-site root — the site's own Ed25519 key, published via its DNS zone and /.well-known/wab.json. Authority over the site is bounded by control of its DNS zone (same trust boundary as TLS).
• Ring 4 trust graph — an optional reputation overlay (webagentbridge.com-anchored today, federated over time) that lets agents reason about which sites to honor without taking on individual trust decisions per request. Trust signals are softening: they bias scoring, they never override a hard refusal.

5. Boundaries we enforce by construction

• Scope — intents cannot exceed the declared actions, max_spend_cents, and expires_at. The server rejects, never silently truncates.
• Single-use — every intent contract burns its nonce on the first authorize. Re-authorize fails closed.
• Idempotent execution — UNIQUE (intent_id, idempotency_key) in the transactions table makes double-execution structurally impossible.
• Receipt immutability — receipts are append-only. Compensation is a separate signed event, never a mutation.
• Time-bounded sessions — JWT access tokens default to 15 min; refresh tokens are bound to the device fingerprint.

6. Reporting vulnerabilities

See /responsible-disclosure. In short: email security@webagentbridge.com, encrypt with our published PGP key, and expect an initial response within 72 hours.

7. Document history

• 2026-05-25 — Initial publication. Reflects v3.17.x protocol.

Related: /threat-model · /responsible-disclosure · /key-rotation · /atp-semantics · Full spec