Buyer-safe architecture

Security overview without exposing private implementation source.

This buyer-facing security overview explains the controls clients need to understand: shared 0S gate access, Citadel Database and SkyeNet mail movement, sovereign-key boundaries, inbox storage, and proof records that do not publish secrets.

Security model

The product boundary is public. The private implementation stays private.

Shared 0S gate accessSkyeMail uses the same SkyeGate FS27/Free99 access lane as the rest of the 0S. Buyer and operator sessions come through the shared gate instead of a separate app password.
Sovereign key boundaryMailbox content is protected by the workspace key model. The client passphrase wraps the private unlock material, and private keys or passphrases are not published in proof pages.
Citadel Database mail recordsInbound and outbound events are recorded as sovereign mail records so delivery, receipt, reply, failure, and sync state can be reviewed without exposing private message content.
SkyeNet operating laneThe app surface, inbox refresh, send lane, and operational checks run through the SkyeMail lane backed by Citadel and SkyeNet without exposing implementation internals.
Mailbox routing boundaryHosted mailbox connectors can move mail in and out, but OAuth tokens, private routing secrets, webhook signing material, and owner service tokens stay out of buyer-facing pages.
Sanitized proofPublic proof pages show live status, delivery outcomes, and release receipts with secret fields removed. They are evidence surfaces, not implementation dumps.

Buyer checks

What a buyer can safely verify.

Access pathConfirm SkyeMail opens through the 0S gate and carries the selected mailbox into the inbox session.
Mail pathConfirm live proof shows a send/read loop and that inbox actions operate on the selected hosted mailbox.
Secret boundaryConfirm public pages do not expose private keys, passphrases, tokens, routing secrets, or private implementation source.