Platform Features Blog Build With Us
Try ATMAN
SYSTEM ARCHITECTURE // DEFENSE SPECIFICATION // PROTOCOL HARDENING

Security Architecture

TRANSIT: TLS 1.3
CUSTODY: CLIENT-LOCAL
KEY HYGIENE: SANITIZED HEADERS
AUTH: WEBAUTHN PASSKEYS
Active Evolution Notice

ĀTMAN is currently in active development. As our cognitive intelligence architecture expands and new capabilities are introduced, our security infrastructure and defense protocols will continually evolve to enhance user protection and system resilience. Registered users and security researchers will be notified of material security updates.

LIVING SYSTEM ARCHITECTURE // VERIFIED DIRECTIONAL DATAFLOW
Explore verified component boundaries, inspect live dataflows, or trace an end-to-end prompt reflection.
DIAGRAM: SEC.02-INTERACTIVE
Guided Flow
Prompt Reflection Lifecycle
STAGE 1: SOVEREIGN INCEPTION

When you write a thought or reflection in ĀTMAN, it never reaches a cloud database in plaintext. Your browser immediately derives a local AES-GCM-256 key via the Web Crypto API, generates a 96-bit random IV, and commits the encrypted ciphertext to client IndexedDB.

Boundary A: Client Sanctuary Device Custody
Boundary B: Transport & Airlock Perimeter Gate
Boundary C: Ephemeral Inference External Cluster
Verified Directional Dataflows (Select to Inspect Transit Invariants) 7 End-to-End Invariants

AES-GCM-256 Sovereign Vault

User Device Hardware

Direct hardware-accelerated AES-GCM-256 client encryption for scratchpad notes in local IndexedDB (atman_vault_db). Submitted conversational reflections are transmitted over TLS to private server proxies for AI reflection and deleted upon request.

Technical Responsibilities
  • Generates non-extractable 256-bit AES-GCM master key via window.crypto.subtle
  • Applies unique cryptographically random 96-bit IV per encrypted record
  • Saves encrypted drafts, dialogues, and memory matrices in browser IndexedDB
  • Executes 1-click zeroization wiping all database object stores and in-memory keys
Security Properties
  • Zero cloud database storage of user reflections
  • Sole client custody over private cryptographic keys
  • Non-extractable key flag neutralizes script memory extraction attempts
Verified Source Code Evidence

Verified in public/js/vault.js lines 112-170 (window.crypto.subtle.generateKey with ALGORITHM="AES-GCM", KEY_LENGTH=256, IV_LENGTH=12, store="keys").

Architectural Boundaries & Known Limitations

Master key is held within browser IndexedDB on the device. If the physical host operating system is compromised or malicious browser extensions have full origin access, local data could be extracted.

Client-Side Custody

LOCAL-FIRST MEMORY VAULT

Traditional cloud AI architectures transmit every user reflection into centralized multi-tenant databases, creating massive breach vulnerabilities. ĀTMAN keeps cognitive vectors sandboxed on the client machine.

  • Browser Sandboxing: Scratchpad drafts reside directly in local encrypted IndexedDB storage under user device custody.
  • Synchronized Continuity with Complete Deletion: For authenticated users, conversation history and distilled memory are stored on secure server storage to enable cross-session continuity. We never monetize transcripts, and users can permanently delete all server records at any time.
  • Instant Eradication: Selecting "Delete All Account Data" triggers complete, irreversible eradication of both local vault storage and cloud server records.

Transport Security

MANDATORY TLS 1.3 & HSTS

All client-to-server and proxy-to-model transmissions are encrypted using modern cryptographic protocols with forward secrecy.

  • Enforced TLS 1.3: Insecure or deprecated cipher suites (TLS 1.0, 1.1) are strictly rejected at the edge.
  • HSTS Enforcement: Strict Transport Security prevents SSL-stripping and man-in-the-middle downgrade attacks.
  • Encrypted Websockets: Real-time mascot thought streams and telemetry pass through authenticated, encrypted secure channels.

Proxy Airlock Hygiene

AGENTSHIELD TOKEN HYGIENE

Our server-side AI proxy acts as a hardened airlock between client sessions and upstream neural models.

  • Zero Hardcoded Credentials: Source code and git commits are verified to contain zero master keys or database secrets.
  • Header Sanitization: Custom keys (x-custom-deepseek-key, x-custom-gemini-key) are passed in volatile server memory and never logged to disk.
  • Self-Healing Cascades: Resilient model fallback handles API upstream blips without exposing backend stack traces.

Sanctuary Access

WEBAUTHN & HARDENED AUTH

Authentication mechanisms are designed to resist credential stuffing, session hijacking, and brute-force enumeration.

  • FIDO2 / WebAuthn Passkeys: Biometric and hardware-key login for passwordless, credential-theft-resistant access.
  • Credential Isolation: Administrative credentials authenticate via isolated environment variables (PBKDF2 SHA-256 high-work iteration roadmap target).
  • HttpOnly Strict Cookies: Session tokens are locked in HttpOnly, SameSite=Strict cookies, neutralizing XSS extraction.
COORDINATED VULNERABILITY DISCLOSURE // RESPONSIBLE RESEARCH POLICY: RFC-9116 / SECURITY.TXT

Reporting Protocol

We deeply welcome responsible vulnerability disclosures from ethical security researchers. If you identify an issue affecting client cryptographic isolation, token sanitization, or origin boundaries, report it directly to our security engineering team.

Verified Invariants Matrix

  • ✔ Zero unencrypted conversational reflections stored on central disks
  • ◌ Server-isolated environment credentials (PBKDF2 SHA-256 hashing in development)
  • ✔ AES-GCM-256 native Web Crypto API with 96-bit unique IVs
  • ✔ Strict ~700-token ceiling on companion prompt distillations