Access & Security
Understand Zeta's single-owner store model, DPAPI key protection, lock screen, and why there is no traditional authentication.
Access model overview
Zeta uses local, single-owner storage instead of traditional authentication. This page explains how the application protects its store, keys, and sensitive UI state, and where those protections stop.
Zeta is a Windows desktop prototype. It has no network service, production identity system, or deployment-signing workflow.
No traditional authentication
Zeta runs as a local Windows desktop application. It does not provide:
- A login system
- User accounts
- JWT tokens
- API keys
- OAuth flows
- Production authentication
- Deployment signing
Access to the application depends on the local Windows environment, the protected store keys, and the single-owner process lock. These controls do not establish user identity for a production service.
Single-owner local store
Zeta opens an ownership file named .owner with exclusive sharing in the local store directory:
%LOCALAPPDATA%\Zeta\Synthetic-v1
The exclusive file handle prevents a second Zeta process from opening the same store concurrently. If another process already owns the store, the second process receives:
STORE_ALREADY_OPEN
This ownership check prevents two application instances from modifying the same SQLite database at the same time. It is a process-level storage safeguard, not a user authentication mechanism.
DPAPI key protection
During normal Windows execution, Zeta generates 64 bytes of installation key material. The application divides the material into two keys:
- A 32-byte AES key for encrypting stored inventory values.
- A 32-byte HMAC key for keyed fingerprints and duplicate detection.
Zeta protects the combined key material with Windows DPAPI using the CurrentUser scope. The wrapped material is stored in owner.keys within the local store directory. Because DPAPI binds the protected material to the Windows user context, the original Windows user is required to unwrap the keys.
If Zeta finds an existing database without its key file, it refuses to generate replacement keys. Replacement keys would make previously encrypted inventory data unreadable, so the application does not silently replace missing key material.
The key file is separate from the SQLite database. Encrypted backups also exclude the keys, which means a backup is recoverable only with the original DPAPI-protected key material and Windows user context.
Lock screen behavior
Locking the application protects the active session while the process remains open. Zeta locking:
- Pauses new work.
- Clears sensitive windows.
- Clears application-owned clipboard contents.
- Prevents access to service operations.
Unlocking is a demo confirmation in the prototype. It does not validate a password, establish production identity, perform Windows reauthentication, or replace a production access-control system.
Treat the lock screen as an in-session privacy control. It limits access to the running application but does not provide production reauthentication.
Recovery limitations
Zeta's access and key model has explicit recovery boundaries:
- Keys are tied to the Windows user account through DPAPI.
- The store is not portable between Windows users.
- A lost device or lost Windows user context has no portable recovery path.
- The application has no production authentication.
- The application has no deployment signing.
- A missing key file cannot be repaired by generating a replacement key.
These limitations are intentional prototype boundaries. Zeta does not claim to provide identity recovery, device migration, production account recovery, or signed production deployment.