Security, Authentication, and Privacy in xSyched

Your Memory Deserves Real Protection

When your AI has access to your most important professional and personal information, security isn't optional — it's foundational. xSyched was built with security at every layer, from authentication to data access to isolation between users. Your memory is yours alone.

This article walks through the specific mechanisms that protect your data in xSyched — not in abstract terms, but in concrete architectural decisions that ensure your information stays private, authenticated, and under your control.

Multi-Provider OAuth2 Authentication

xSyched does not ask you to create yet another username and password. Instead, authentication is delegated to identity providers you already trust:

• GitHub — ideal for developers and technical professionals who already live in the GitHub ecosystem.
• Google — widely used across personal and professional accounts, providing seamless access.
• Azure Active Directory — designed for enterprise users whose organizations manage identity through Microsoft's platform.

No passwords are stored by xSyched. Each provider independently verifies your identity through the OAuth2 protocol, and xSyched receives only the confirmation that you are who you claim to be. This means there is no password database to breach, no credentials to leak, and no reset flows to exploit.

You can also link multiple providers to the same xSyched account. If you sign in with GitHub at work and Google at home, both sessions connect to the same data. Flexibility without compromise.

API Token Management

Once authenticated, your session is managed through access tokens and refresh tokens that follow OAuth2 best practices:

• Defined lifetimes — access tokens expire after a set period, limiting the window of exposure if a token is ever intercepted.
• Automatic refresh — when an access token expires, a refresh token seamlessly obtains a new one without requiring you to sign in again.
• Session validation — every request checks that the token is still valid. Expired or revoked tokens are immediately rejected, with no grace period and no exceptions.
• Secure token exchange — the flow between ChatGPT and xSyched's API uses a secure, transparent token exchange mechanism that ensures your identity is verified at every step.

This architecture means that even if a session is interrupted or a device is lost, your account remains protected. Tokens can be revoked, sessions can be terminated, and access is always time-bounded.

Context Access Control

Authentication answers the question "who are you?" Access control answers the question "what are you allowed to see?" In xSyched, these are separate, layered checks that occur on every single API request.

• Every API request validates that the requesting user has permission to access the requested context.
• The validate_user_context_access function checks ownership and sharing permissions before any data is returned. If you don't have access, the request is denied — not filtered, not partially returned, but denied entirely.
• You can only see your own contexts and contexts that have been explicitly shared with you by their owner.
• Group contexts are accessible only to verified group members.

This is not a soft boundary. It is enforced at the API layer, which means no client-side trick, no URL manipulation, and no creative request formatting can bypass it. The server decides what you can access, and it decides based on verified ownership and explicit permissions.

Group-Based Permissions

xSyched supports collaborative use through groups, but collaboration never comes at the expense of security. Group access is governed by strict permission rules:

• Group membership controls access — only members of a group can see that group's shared contexts. There is no public or default-open group access.
• Owner-managed membership — group owners decide who can join and what they can access. Membership changes are explicit actions, not automatic processes.
• Invitation-based entry — you cannot join a group uninvited. Access requires an explicit invitation from the group owner, preventing unauthorized discovery or entry.
• Domain group verification — for organizational groups, membership can be verified through email domain, ensuring that only people within your organization can access organizational contexts.

Groups make xSyched more powerful for teams, but the security model treats group access with the same rigor as individual access. Every group member's permissions are validated on every request.

Data Isolation Between Users

Perhaps the most fundamental security property of xSyched is strict data isolation between users:

• Logical isolation — each user's data is logically isolated in the database. Queries are scoped to the authenticated user, and cross-user data access is architecturally impossible through normal operations.
• No cross-access paths — there is no API endpoint, no query parameter, and no feature that allows one user to access another user's private contexts, items, or tasks.
• Explicit sharing only — sharing is always an intentional action by the data owner. Nothing is shared by default, and sharing one context does not expose any other context.
• Consistent access controls — even administrators interact with the system through the same access control mechanisms. There is no backdoor, no admin override that bypasses the permission model.

This isolation is not a policy — it is a structural property of the system. Your data cannot leak to other users because the architecture does not provide a path for it to leak.

Privacy by Design

xSyched's approach to privacy is straightforward: collect only what is necessary, protect everything that is collected, and give you full control over your data.

• Minimal data collection — xSyched collects only what is necessary for the service to function. Your authentication identity, your contexts, your items, and your tasks. Nothing more.
• No advertising or data selling — your data is never sold, never shared with advertisers, and never used for third-party analytics tracking. There are no hidden data flows.
• Your data is your property — the contexts, items, and tasks you create in xSyched belong to you. They exist to serve you, not to feed a business model.
• Right to deletion — you can delete your data at any time. Deletion means deletion — not archival, not soft-deletion with a 90-day retention, but actual removal.

Privacy in xSyched is not a compliance checkbox. It is a design principle that shapes every decision about what data to collect, how to store it, and who can access it.

A Practical Example

Consider Alex, a consultant who uses xSyched to manage both client work and personal projects. Alex stores sensitive client information in a "Contract Negotiations" context — deal terms, counterparty positions, negotiation strategies, and confidential financial details.

Only Alex can access this context. Not team members. Not group members. Not anyone else. The validate_user_context_access function ensures that every request for this context is checked against Alex's identity and ownership.

When Alex shares a different context — say, "Team Project Planning" — with a colleague, the colleague sees only that specific context and its contents. The "Contract Negotiations" context remains completely invisible and inaccessible to the colleague. There is no way to discover it, no way to request it, and no way to infer its existence.

This is not a hypothetical. This is how xSyched works on every request, for every user, every time.

Security as Architecture

Security in xSyched isn't a feature you configure — it's built into the architecture. Every request is authenticated, every access is authorized, and every user's data is isolated. When we say your memory is yours, we mean it structurally, not just philosophically.

From OAuth2 authentication to token management, from context access control to group permissions, from data isolation to privacy by design — every layer of xSyched exists to ensure that your AI memory remains exactly what it should be: yours.