Security architecture for safe recursive self-improvement research.

Foundational thesis: Constraints aren't limitations; they're the engine that makes browser-native RSI work. The browser sandbox, VFS containment, and graduated gates create stable pressure toward compact, efficient self-modifications.

This document provides a high-level overview of REPLOID's security model. For detailed implementation specifications, see the referenced blueprints.

Current defaults are intentionally permissive for experimentation: REPLOID_SECURITY_MODE defaults to 'off' and REPLOID_ARENA_GATING defaults to 'false'. Enable them explicitly for substrate-modification experiments.

Graduated operation with automated gates:

Gating is enforced via automated verification and rollback:

• Arena consensus for L1 changes
• Arena + GenesisSnapshot rollback for L2 changes
• Signed rsi.improvement-episode/v1 evidence, protected evaluator authority, paired raw observations, explicit promotion, and generation rollback for L3 claims
• Circuit breakers prevent runaway failures

Arena success, mutation logs, telemetry, saved reflection, or a rising fitness number does not establish L3 improvement. See RSI improvement episodes.

REPLOID studies RSI (recursive self-improvement) without giving agents access to the underlying operating system. All execution happens in a browser sandbox with multiple containment layers.

• Read/write VFS files (IndexedDB)
• Create and execute tools in VFS
• Modify their own substrate (with gates)
• Spawn sub-workers with restricted permissions
• Call LLM APIs (rate-limited)
• Request sponsored inference from swarm sponsor peers (free tier)

• Access the underlying filesystem
• Execute operating-system binaries
• Make arbitrary network requests (except scoped Gemini calls by sponsor peers)
• Access browser APIs directly
• Escape browser sandbox
• Modify Service Worker directly
• Access unrelated browser tabs/origins directly outside swarm transport

Reploid supports a pure P2P free tier where opted-in peers form small custody committees for one or more shared demo Gemini keys. This enables zero-install, zero-config demo usage without backend key custody.

See Blueprint 0x00007E: Sponsor-Peer Protocol for the canonical specification. The blueprint is the source of truth for topology, routing, quotas, and scaling. This section summarizes policy only.

This is a flat swarm with dynamic sponsor roles, not a permanent privileged class:

• Shared keys are split into shares and distributed across small committees
• No peer stores the full Gemini key at rest
• Requesters never see the full key
• Executors reconstruct a key in memory only after quorum, then zeroize
• Quotas are enforced per peer identity and per key bucket
• Peers hold a persistent ECDSA P-256 identity keypair (Web Crypto API, stored in IndexedDB)
• Peer ID = SHA-256 fingerprint of public key

Sponsored inference must follow these scaling rules:

• Keep custody committees small: 3-10 peers
• Never split one shared key across the whole swarm
• Scale capacity by adding key buckets, not by adding more custodians to one key
• Route requesters to a key bucket, not to the full swarm
• Isolate failure domains per key bucket

Authorized executors are granted a scoped network exception to the "no arbitrary network requests" rule:

• Scope: HTTPS calls to generativelanguage.googleapis.com only
• Trigger: Only in response to a valid, signed lease and quorum-backed share release
• Constraint: Only allowlisted demo models and bounded sponsored-mode quotas
• Audit: All forwarded requests logged with peer ID, key ID, token count, timestamp

This is not a general network hole. The exception is:

1. Scoped to a single API endpoint
2. Gated behind sponsor opt-in and committee quorum
3. Metered per peer identity
4. Constrained to the weakest model tier

Quota enforcement is keyed by public-key fingerprint and key bucket.

Default demo quotas, lease limits, and stream limits are defined in the blueprint. Security policy requires that sponsored inference remain bounded, low-priority, and separately metered from BYOK or local inference.

Sponsored inference is intentionally limited:

• Flash Lite tier only
• Low max output tokens
• Slower queue priority
• Small daily quota
• No long context
• No batch jobs
• No arena / heavy self-improvement paths
• Small custody committees only
• Capacity scales by adding more shared keys, not more custodians per key

This is soft enforcement for a demo tier, not a secure production secret:

• Sybil identities: A peer can generate new keypairs. Mitigate with per-key quotas and sponsor-side heuristics.
• Executor compromise: A malicious executor can abuse a reconstructed key in memory. Mitigate with short-lived leases, scoped model restrictions, key rotation, and monitoring.
• Replay attacks: Signed leases require expiry timestamps and nonces.
• No backend authority: Without a server, there is no single source of truth for quota state. Executors gossip usage receipts for soft consistency.
• No global Shamir mesh: A single shared key must never be split across a large open swarm. Scaling comes from multiple key buckets with small committees.

The right product framing is sponsored serverless demo capacity, not a secure shared-production secret.

localStorage.REPLOID_ARENA_GATING='true';// Require consensuslocalStorage.REPLOID_MAX_ITERATIONS='50';// Cap iterations

localStorage.REPLOID_ARENA_GATING='true';// Multi-model consensuslocalStorage.REPLOID_SECURITY_MODE='on';// Enable security enforcement

1. Stop agent: Press Escape or click Stop button
2. Review audit log: Check /.logs/audit/ for recent actions
3. Restore genesis: Click "Restore to Genesis" in Snapshots tab
4. Export session: Save for analysis before clearing
5. Clear VFS: If needed, clear IndexedDB entirely

For implementation details, see:

• 0x000040: Verification Manager - Complete security integration section
• 0x000049: HITL Controller - Human oversight modes
• 0x00005C: Circuit Breaker - Failure isolation
• 0x00003C: Genesis Snapshots - Rollback system
• 0x00007E: Sponsor-Peer Protocol - P2P free tier inference

Last updated: March 2026