Architecture

Zero-Trust Edge Computing

Waspada AI follows a strict Zero-Trust architecture where no component — not even the Gateway — is trusted with victim PII.

┌──────────────────────────────────────────────────────────┐
│                   TRUST BOUNDARY                         │
│  ┌────────────────────────────────────────────────────┐  │
│  │              Client Device (Browser)               │  │
│  │                                                    │  │
│  │  Evidence File ──→ OCR/PDF ──→ Regex ──→ NER      │  │
│  │                                    │               │  │
│  │                              PII Stripper          │  │
│  │                                    │               │  │
│  │                           AES-256-GCM Encrypt      │  │
│  │                           (local evidence store)   │  │
│  │                                    │               │  │
│  │                          Anonymized Indicators     │  │
│  └────────────────────────────┬───────────────────────┘  │
│                               │                          │
│                               │ JWT-Signed, Zero-PII     │
│                               ▼                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │           Waspada Gateway (Stateless)              │  │
│  │                                                    │  │
│  │  JWT Verify → PII Filter → RDAP Enrich → FMS Fmt  │  │
│  └────────────────────────────┬───────────────────────┘  │
│                               │                          │
└───────────────────────────────┼──────────────────────────┘
                                │
                                ▼
                    ┌──────────────────────┐
                    │   Bank FMS Webhook   │
                    │  (Standardized Alert)│
                    └──────────────────────┘

Key Design Principles

1. Local-First Inference

All AI processing runs on the user's device:

Engine	Runtime	Model Size	Latency
Regex	JavaScript	0 KB	< 10ms
OCR (Tesseract)	WASM	~7 MB	1-3s
NER (DistilBERT)	WASM/WebGPU	~40 MB	100-200ms

2. Non-Extractable Cryptography

// Keys are created with extractable: false
// They cannot be exported via JavaScript — browser enforced
const key = await crypto.subtle.deriveKey(
  { name: 'PBKDF2', salt, iterations: 600000, hash: 'SHA-256' },
  baseKey,
  { name: 'AES-GCM', length: 256 },
  false, // ← NON-EXTRACTABLE
  ['encrypt', 'decrypt']
);

3. Defense-in-Depth PII Filtering

PII is stripped in two independent layers:

1. Client SDK — Regex patterns remove NRICs, phone numbers, and names before payload construction
2. Gateway — Secondary PII filter rejects any payload containing suspicious patterns

If PII is Detected at the Gateway

The payload is rejected with HTTP 422. This indicates a bug in the SDK's PII stripper and triggers an engineering incident. It should never happen in production.

4. Gateway: verify-first request path

Today the gateway is request-path stateless (verify JWT → PII gate → enrich → format → deliver). Shared replay/rate-limit state already uses Redis when configured.

Phase B decouples side-effects onto a durable event log (Redis Streams transport + Postgres system of record). See Phase B0 foundations for the schema, tenancy, retention, and encryption design, and Phase B1–B4 runtime for the shipped ingest → bus → durable alert → outbox path. Ingest returns 202 ACCEPTED with event_id.

Horizontal scale still requires Redis for JTI/rate-limit (and, in B4, pub/sub for SSE).