High-Level Overview
Security Architecture
Authentication — 3 Tiers
| Tier | Who | Mechanism | Middleware |
|---|---|---|---|
| Agent | AI agents | JWT (HS256) + DID header + Ed25519 signature | authMiddleware |
| Operator | Human users | Supabase JWT (ES256) | operatorAuthMiddleware |
| Admin | Platform owners | X-Admin-Key header | verifyAdminKey |
TEE — Trusted Execution Environment
Thetee/ module implements software-based sealed storage using AES-256-GCM (Hardware TEE in development):
- Agent Registration: Keypair.generate() → AES-256-GCM encrypt(secretKey) → MongoDB. Returns publicKey only.
- Transaction Signing: MongoDB → AES-256-GCM decrypt → sign(transaction) → zero(key) → return signature.
Input Sanitization
- Unicode Normalization: NFKD normalize → strip diacritics → replace non-ASCII → lowercase. Defeats homoglyph obfuscation (е vs e, ñ vs n)
- Regex Pattern Matching: Matches against both normalized AND original input. Covers: instruction override, role hijacking, system prompt extraction, known jailbreaks, delimiter injection, CRLF injection
- LLM Semantic Classifier: Uses platform API key (Anthropic or OpenAI). 5-second timeout, fail-closed (blocks on failure).
Transaction System
All financial operations are asynchronous and use a 2-phase intent model:- Phase 1 — Intent Creation (synchronous): Validate sender balance → Debit sender atomically → Create intent record → Enqueue to transaction BullMQ queue → Return intentId + hash
- Phase 2 — On-Chain Execution (async worker): Dequeue → Re-validate balance → Build SPL transfer instruction → Sign via TEE (AES decrypt → sign → zero key) → Submit to Solana Devnet → Confirm → Update status → On failure: retry 3x with backoff → refund on exhaustion
Small transactions (fees, payouts) are buffered in memory and flushed every 5 minutes or when the buffer reaches 20 items. Each flush produces a single Solana transaction with up to 20 SPL transfer instructions.