Security Architecture
MemorDesk implements several non-obvious security patterns that go beyond standard SaaS practices. This article documents them for security-conscious teams.
Dead Refresh Token Circuit Breaker
Most web apps retry on a 401 Unauthorized response. When an authentication session is invalidated (rotated, revoked, or expired), retrying produces a cascade of 401s that each trigger another refresh attempt -- creating a request storm and often causing rate-limit errors.
MemorDesk's session management layer detects the specific error conditions that indicate a token is permanently invalid. On any of these, it immediately clears all session cookies and redirects to the sign-in page. There is no retry. The rate-limit storm never starts.
Password Forensics Without Plaintext
MemorDesk's intrusion log captures failed login attempts for analysis, but plaintext passwords are never stored -- not even temporarily.
When a failed login is recorded, a non-reversible cryptographic fingerprint is computed from the attempted password. Only a short segment of this fingerprint and the password length are retained. The plaintext is discarded immediately.
This fingerprint lets security reviewers detect credential-stuffing patterns -- "the same password was tried against 800 different accounts" -- without reconstructing or leaking the actual password. The fingerprint is not reversible.
Credit Holds for Concurrent Execution Safety
Credits are MemorDesk's billing unit for AI operations (meeting processing, Kojo queries, voice recaps). A naive deduction model has a race condition: two simultaneous jobs both read the user's balance as sufficient, both proceed, and the user ends up overdrawn.
MemorDesk solves this with a credit hold pattern borrowed from payment processing:
- Before starting a job, a temporary reservation is placed against the expected credit cost with an automatic expiration window.
- Credit availability checks include active holds in the balance calculation.
- On job completion, the hold is consumed and the actual deduction is recorded in the immutable transaction ledger.
- On job failure, the hold is released. Credits are never deducted for failed jobs.
- Expired holds collapse automatically, providing a safety valve if a job hangs indefinitely.
Desktop: profile avatar (top-right) > the credit balance dropdown shows your available balance net of holds.
Mobile: profile avatar (top-left) > Profile > Credits card.
Shared Bot Session Deduplication (Team+ Plans)
When two calendar events in the same organization share the same meeting URL, a naive system would send two bots -- one per event. This causes two identical bots to appear in the meeting simultaneously, wasting provider cost and confusing participants.
MemorDesk's calendar ingestion engine checks for an existing active bot session matching a meeting URL before dispatching a new one. If a bot is already in the session, the second event is attached to the same session rather than triggering a new join.
This deduplication is active for Team, Business, and Enterprise plans.
Intrusion Detection and Observe Mode
MemorDesk records every rejected auth attempt with network telemetry including IP address, geographic data, device information, and a non-reversible password fingerprint. Automated detection rules evaluate patterns after each logged attempt:
| Rule | Condition | Action |
|---|---|---|
| IP rate threshold | Repeated failed authentication from a single IP address within a short window | Automatic IP block |
| Coordinated attack | Multiple distinct IP addresses targeting the same account within a defined time window | Admin dashboard security alert |
Observe mode: By default, detection rules evaluate against live traffic and log projected enforcement decisions without blocking any requests. Enforcement mode is enabled separately after verifying rule accuracy against production traffic.
Desktop: Admin panel > Security (/admin/security). Visible to administrator roles only.
IP Allowlist with Automatic Fail-Closed Semantics
The admin access control layer supports IP-based allowlisting for administrative routes.
- No entries configured: all IPs are allowed (safe default during setup).
- Any entry present: only listed IPs are allowed. Adding the first entry instantly switches from fail-open to fail-closed with no additional flag to set.
Blocked IPs receive a 404 Not Found response to avoid leaking the existence of the admin surface. CIDR notation is supported for IP range entries.
Three-Layer Admin Defense
Every request to admin routes passes through three independent gates:
- IP allowlist -- evaluated first when IP allowlisting is enabled. Returns 404 on block.
- Authentication -- must have a valid active session.
- Role check -- confirms the requesting user holds an administrator role. Cached briefly to reduce database load.
Session and Device Tracking
Every authenticated device is registered with its device fingerprint, platform, OS, IP address, user agent, and last-seen timestamp. Administrators can revoke any device session remotely.
Desktop: Settings > Security (/dashboard/settings/security) > active sessions list.
Mobile: profile avatar (top-left) > Profile > scroll to Sessions.