A useful personal memory connects information that usually lives apart: the reasons behind a preference, the circumstances of a decision, the people involved, and the changes that came later. As those connections accumulate, security has to account for what the system can infer and share alongside the files it stores. A carefully protected archive can still be exposed too broadly when an application asks to know its owner.
In the earlier personality-layer essay, I described a personal metalayer containing biography, experiences, preferences, relationships, and patterns that persist across tasks. Giving that layer a useful role in software requires several kinds of control. The user needs to decide where the underlying material lives, which applications may consult it, what those applications may change, and how those decisions can be revised.
Synthius brings these controls into the same architecture. Its security model combines encrypted cloud storage and RAM-only private source processing with optional local sources, authenticated access, and separate permissions for applications connected to a persona. A common layer can reduce repeated copies of a person’s context while becoming a valuable point of access itself. Its value depends partly on how precisely the person can govern that access.
Where the Memory Is Kept
Synthius separates original sources, structured personal memory, and operational metadata. A document, the memories extracted from it, and the record of a processing job have different purposes and storage requirements. Their security properties need to be described separately.
User-owned cloud files are encrypted before their bytes reach object storage. This covers source uploads and content-bearing artifacts such as persona outputs, saved conversation content, reports, and memory-change payloads. The implementation uses AES-256-GCM, which protects confidentiality and detects modification of the encrypted content. Each user has a data-encryption key, itself stored in wrapped form, with the wrapping secret held outside the database.
Personal-memory payloads, document contents, conversation bodies, and cloud search indexes are encrypted in full at rest. The database keeps the information needed to locate and manage them, including timestamps, job states, identifiers, and storage pointers. Account details, filenames, and app-supplied labels or notes can also be readable database fields; access controls protect that metadata while the associated content payloads remain encrypted. A copy of the encrypted archive and its wrapped keys cannot be decrypted without the separate server-held secret.
Persona facts, assessments, summaries, and writing-style content are read from the encrypted files themselves, without readable duplicate bodies in persona database records. Importing a published persona creates an independent copy encrypted under the recipient’s account key. Later additions and corrections belong to that copy and receive the same protection as the user’s other persona memory.
We built the server-side parsing and extraction pipeline so that private source data never touches persistent storage unencrypted. Authorized content is decrypted in memory, and intermediate files stay in verified RAM-only scratch storage, with swap protection and no disk fallback. Cloud outputs are encrypted before storage. This protects the source and the personal memory extracted from it throughout processing, without leaving readable copies in server temporary files alongside the encrypted archive. The running backend remains trusted to use decrypted content for the requested task.
The backend obtains identity from a verified Supabase access token and checks ownership before returning a source or persona artifact. Database row-level security adds another boundary where client access is permitted; privileged backend routes still need their own owner-scoped checks. HTTPS protects data moving between the browser and online service. Encryption, authentication, and authorization address different ways information can become accessible.
Original sources can also reside on the user’s computer through Dendrite. Residence is chosen per source, so a person can keep a private archive locally while storing other material in the cloud. Local parsing and source-search indexes stay with that source; structured persona memory and online processing remain online. Building memory can send source material for processing, and later retrieval can transmit relevant passages. Keeping an original locally controls its residence without making the whole system offline.
Dendrite intentionally leaves local source files, parsed text, and search indexes unencrypted on the user’s computer, so the person can open and use them without Synthius. The operating-system account and disk protection secure these files. Dendrite’s local API separately verifies the user’s access token, restricts browser origins, and enforces ownership.
Mem0’s self-hosted deployment gives an operator control over the memory stack and model configuration, along with responsibility for authentication, network protection, and maintenance. We built Synthius to put the relevant decisions directly in the person’s hands: source residence, the persona an app may use, the memory domains it may read, and the changes it may make. For an individual seeking a protected personal memory, that is a substantial practical advantage over assembling and securing an infrastructure stack. The controls arrive as part of the product and remain manageable as new applications connect.
Permissions That Follow the Person
The user-owned layer becomes useful when other applications can consult it selectively. A work assistant may need professional history and current preferences, while a travel tool may need preferences without access to biography or relationship records. Treating those connections independently lets personalization begin with a smaller disclosure.
Synthius exposes this through Personal MCP and its Memory Gate. MCP supplies a common interface through which compatible assistants can use external tools. Each app receives its own credential, bound to one persona, with a domain selection and read-only or read-and-update authority. The server stores a hash of the credential; its secret is shown when created or rotated.
Read permissions operate at the level of memory domains, including biography, experiences, preferences, work, social circle, and psychometrics. The backend derives the owner and persona from the credential and checks the allowed domains before retrieval. Another persona, the user’s account settings, ordinary chat history, and provider API keys remain outside that connection. These checks are enforced in the service rather than entrusted to a request asking an assistant to respect a boundary.
Update authority distinguishes changes submitted for Synthius processing from direct amendments, where an app can receive separate Add, Edit, and Delete grants for selected structured domains. A travel assistant could therefore be allowed to add preferences while lacking permission to edit existing ones or delete records. Direct amendments validate the resulting records and recheck live authorization at the database commit, including changes to permissions made while a request was underway.
Two broader permissions deserve their own explanation. Biography summary reveals a complete generated overview, which can repeat information from several domains. Original sources permits passage retrieval across the persona’s linked source files, where a passage can contain material outside the selected structured domains. Leaving those permissions disabled preserves a narrower connection. The current read boundary is domain-level; a Preferences grant can expose the permitted preference records more broadly than the few travel facts an app happens to need.
An owner can narrow, rotate, or revoke one app’s connection without disconnecting the others. Reduced permissions apply to subsequent requests, and direct writes check authority again when committing. Information already returned remains in the recipient’s possession, subject to its own retention practices. Revocation closes future access through Synthius; deleting copies held elsewhere requires controls at the receiving service too.
Supermemory offers scoped MCP access, including selected spaces and read-only connections. Synthius provides a more specific control surface for a personal proxy: Biography, Work, Preferences, and the other domains already have distinct meanings, and update grants distinguish adding a record from changing or deleting one. A travel tool can contribute a new preference while being unable to rewrite existing preferences or read the user’s work history. The person can make that decision directly in Memory Gate, without first designing a set of spaces to stand in for the structure of a life. This is the advantage we built into Synthius: personal understanding and the authority to use it are organized together.
What Leaves the Memory Layer
The next boundary appears whenever memory is used. A selected model receives the material needed for a reply or processing task. Persona construction may involve substantial parts of a chosen archive; a later conversation may use retrieved records and excerpts. The receiving provider’s terms, retention, and processing locations remain part of that interaction even when the original files are encrypted or local.
Synthius’s provider policy commits to business/API processing without training shared models on customer content. Its own use of uploads, chats, and generated personal memory is governed by the same no-training commitment. Bringing a personal API key changes the provider relationship and settings involved, which is why provider selection belongs among the user’s data decisions.
This is an area where established providers already offer substantial protections. OpenAI documents encryption and no training by default for its business products and API, while Anthropic makes a comparable commercial training commitment. Google’s Gemini API terms distinguish paid and unpaid services. Training, retention, and access during processing are separate questions, and the applicable product and account matter to each.
When an external assistant reads Synthius through MCP, returned information enters that assistant’s context under its own product terms. A separate personality layer gives the user control over the disclosure made by Synthius, while the receiving service remains responsible for its copy. A narrow permission can make that disclosure much smaller than uploading an entire archive to every new assistant.
With connected tools, the same assistant can move from reading context to acting in other services. Synthius’s managed Composio integration isolates users into separate projects and binds execution to the verified account and enabled tools. Precision Control can keep a mail-reading connection available while disabling send or delete tools. It restricts execution inside Synthius without shrinking the underlying provider’s OAuth grant; provider-side revocation remains a separate control. Enabled tools and saved schedules can act under their existing authority without a fresh approval dialog for every operation.
A Personal Bot in a Shared Messenger
Telegram uses different credentials for different jobs. A bot token authorizes a bot, while a user-account session authorizes access as the person. The API ID and hash identify the client application. Keeping those roles distinct makes it possible to retain only the authority each feature needs.
We designed Dendrite’s history importer to minimize retained account authority. Its session key lives only in the native worker’s RAM, with no reusable session saved to disk, browser storage, or Synthius servers. The user selects chats or topics and dates; the application exposes a limited reading workflow and excludes Secret Chats, protected content, and expiring material. Compared with an importer that keeps a reusable account session, this removes a long-lived credential from the retained archive. Logout is attempted when the workflow ends; if it cannot be confirmed, Telegram’s Devices controls provide the recovery path. The live session still carries ordinary account authority, and the device remains part of the security boundary.
The ongoing Synthius bot uses a different policy: its bot token is retained encrypted, with secure owner pairing and a bot-specific webhook secret. Only the paired owner’s requests can use the persona, including owner-invoked Guest Mode replies. Shared-chat participants can see those replies. Bot exchanges remain Telegram cloud chats under Telegram’s encryption model; Synthius protects its stored content and account access while Telegram and the selected AI provider still process the exchange.
Control Over a Memory That Keeps Changing
A personality layer continues to change after an upload has finished. New experiences enter it, earlier interpretations are corrected, and connected applications may contribute updates. Its security therefore includes integrity: keeping a valid record of who changed what and preserving a route back to the underlying evidence.
Synthius’s Memory Trail and Explorer make those changes inspectable, including updates submitted through connected apps. Direct amendments use record validation, revision checks, and atomic saves to avoid silently overwriting another update. Schema validity and factual accuracy remain separate properties. Source references and change history give the person a way to examine an interpretation, identify an inaccurate contribution, and correct the resulting memory.
Deletion also needs distinct meanings. Removing a source deletes its source material and parsing artifacts while preserving memories previously learned from it. Removing a particular memory, deleting a persona, and deleting an account have wider or different scopes. The ChatGPT memory documentation describes a related distinction between remembered information and its original chats or files; Claude provides its own memory and conversation controls. A durable memory makes the relationship between these objects important in every product.
Synthius’s privacy policy explains data use, deletion, and the user’s choices. The policy requires relevant consent for sensitive analysis and keeps relationship context scoped to the user’s own life, rather than constructing cross-user profiles of people mentioned in the archive. Those people’s privacy requests have a separate review path.
We created Synthius around a user-owned personality layer whose access controls remain with the person across products, giving the memory portability argument a practical security model. A travel tool can receive Preferences access while biography and original sources stay closed; a work assistant can receive Work access without the social-circle domain; another app can lose its connection when its role ends. Each application receives a usable part of the same continuity, while the person retains independent control over its access.
The security model gives Bring Your Own Human an application-level meaning: a person can carry useful continuity between products while retaining control over the permissions each product receives. The personality layer remains the common source, and every connected service has its own limited relationship with it under permissions set by the person.