Privacy

SineCodex is designed to keep your organization in control of its information. The Assistant is optional, your organization chooses its provider, and access to tenant data is controlled by an administrator at the field level before an Assistant request is prepared.

Open a section below for the full details and limitations.

Passwordless sign-in, without another password to remember

Passwords can be difficult to manage. They may be forgotten, reused across services, discovered through phishing, or exposed when another service suffers a data breach. SineCodex avoids those long-lived passwords for regular user accounts. Instead, a person can request a short-lived sign-in code at the primary email address recorded for the account, use a rotating code from an authenticator, or use an enrolled passkey or security key.

An emailed sign-in code contains eight digits, expires after 10 minutes, and can be used only once. SineCodex limits how often codes can be requested and how many unsuccessful verification attempts are allowed. Email sign-in depends on the security and availability of the account mailbox and the instance’s outgoing email service. For an administrator with automatic Admin Mode sign-in enabled, an emailed code signs the administrator directly into Admin Mode. If that preference is off, the administrator signs in to User Mode and must complete a separate security check to enter Admin Mode; the emailed code cannot answer that check. An emailed code also cannot unlock a module configured to require an additional security check. A user with TOTP configured may turn off email sign-in in My Information after entering the current Security PIN. Disabling it immediately invalidates outstanding email codes. Resetting TOTP automatically turns email sign-in back on to prevent account lockout.

After first sign-in, a user is prompted to create a reusable six-digit Security PIN. The PIN cannot sign the user in; it unlocks secured modules and can unlock Admin Mode for administrators. It is stored as a salted PBKDF2 hash, and five unsuccessful PIN attempts lock PIN verification for 15 minutes. A passkey, security key, or TOTP authenticator can be used instead. A TOTP authenticator generates a new six-digit code every 30 seconds and can work without cellular service or an Internet connection.

Any authenticator or password manager that supports standard TOTP verification codes can be used. Common choices include:

These examples are provided for convenience and are not endorsements. Protect the device or account that holds your authenticator, never share the setup QR code or manual secret, and never give a current security code to another person. An administrator can issue a one-time setup reset if an authenticator must be replaced.

Optional biometrics, passkeys, and security keys

A user may open My Information after signing in by email and enroll one or more WebAuthn credentials without first configuring an authenticator app. Depending on the device and browser, verification may use face recognition, a fingerprint, the device PIN, a passkey, or a FIDO2 physical security key. An enrolled credential can be used to sign in without entering a username or rotating code and to answer later identity checks for Admin Mode or secured modules. Any configured rotating authenticator code remains available for ordinary sign-in; email remains available unless the user has turned it off after configuring TOTP.

SineCodex does not receive or store a face image, fingerprint, or biometric template. Biometric matching is performed locally by the user’s device, operating system, or physical authenticator. SineCodex receives only the result of that verification and stores the WebAuthn public credential, an opaque user handle, and limited credential metadata needed to verify future challenges. That public information cannot be used to reconstruct the user’s biometric data.

A passkey may be stored only on one device, held on a physical key, or synchronized by the user’s device-platform account. Any synchronization, recovery, and access to that platform account are controlled by its provider and are subject to the provider’s security and privacy practices. Users should protect every device and account that can access their passkeys and remove a lost or retired credential from My Information as soon as possible.

The Assistant is optional

SineCodex works without an AI Assistant. An administrator can select No Assistant at setup or later in Assistant Settings. Assistant buttons and Assistant-only tools are then hidden, and SineCodex stops sending requests to an AI provider.

Connecting an Assistant can still provide major practical benefits. It can help your team:

Assistant output can be incomplete or incorrect. A user must review a proposed import, change, message, or module before relying on it or making it available to others.

Use the AI service your business already trusts

Your organization selects and connects the supported AI service it wants SineCodex to use. If your business already has an approved AI provider, using that account keeps provider choice, contractual terms, retention settings, regional processing options, and usage controls under the same business relationship. The provider receives only the content needed for each permitted Assistant request.

If your organization does not already have a provider, limited no-cost options may be suitable for testing or light use. For example, Google offers a free Gemini API tier for certain models, and OpenRouter offers free models with low request limits. SineCodex also supports Grok where the organization has suitable xAI API access. Provider availability, prices, privacy terms, model access, and limits can change; confirm the provider's current terms before sending business information.

Administrator-controlled Assistant data access

The Assistant has no automatic access to your organization's tenant data. By default, it cannot read your records or field values, even when the signed-in user can view them in SineCodex.

An administrator must explicitly enable Assistant Data Access for each field, module by module. Only the fields selected by an administrator are eligible for tenant-data questions. The server enforces this allowlist before it prepares Assistant context or sends a request to the selected AI provider. The provider never receives broader access to the database or to a module.

This permission is separate from a user's ordinary access. For an allowed field, the Assistant can receive only records that the signed-in user is otherwise permitted to access and that are relevant to the request. Fields that have not been selected are omitted entirely. Sensitive and hidden fields are never provided. Encrypted fields may be selected by an administrator and, if selected, are provided decrypted so the Assistant can use their values.

The same boundary applies to Assistant data searches, summaries, and reports. A module that requires a security token for access remains unavailable to the Assistant, even after a user unlocks it on screen. The server applies these rules before any tenant data is sent to the provider.

What product controls cannot prevent

No access-control system can control what an authorized person does outside its boundary. A user who can view information may be able to print it, photograph the screen, copy it into another service, export it, or deliberately include it in a new Assistant prompt or uploaded file. SineCodex cannot determine that intentionally supplied content came from a field that an administrator did not enable after it has been copied or transformed.

Organizations remain responsible for assigning appropriate access, choosing and configuring their Assistant provider, training users, reviewing provider privacy and retention terms, and following the laws and policies that apply to their information. For sensitive work, do not paste or upload protected information into an Assistant request.

A practical privacy promise

SineCodex does not require an Assistant, does not choose a provider on the customer's behalf, and does not give the Assistant automatic access to tenant data. An administrator must approve access field by field, and the server enforces that decision before any permitted data leaves the application. The AI provider never receives broader access to the database or to a module.