Your business data. Protected by design.

Protection you can understand.

Encrypted storage

Customer names, notes, text and JSON record values, and attached files are encrypted before they enter storage.

Access you control

Give each person the information they need. Keep selected information away from AI assistants.

Ways to recover

Restore records from Trash, keep your own downloaded copy and use the platform’s hourly production record snapshots.

Private information stays encrypted in storage.

Encryption turns readable information into scrambled content that needs a key to open it. Cube OS uses AES-256-GCM encryption for text and JSON record values, attached file names and contents, and activity and notification summaries.

Each workspace has its own encryption key. That key is itself encrypted before it is saved in the database. The separate platform key needed to open it is held by the service, outside the database. A database copy alone cannot reveal the encrypted content.

Customer names, email addresses and private notes are examples of text protected this way. Numbers, currency amounts, dates, yes/no values, choices and record identifiers remain readable in storage, along with your data model and configuration. Keep sensitive information in record fields rather than screen labels or workflow settings.

What this means for access by Cube OS

The Cube OS founder account has no automatic access to your workspace. The service opens encrypted information when it needs to answer an authorized request from you, your team or an assistant you connect.

Cube OS manages these server-side keys. Someone who controls the service and the keys could technically read encrypted content. This is not end-to-end encryption or a zero-knowledge service. Encryption protects stored content; access controls govern its use inside the product.

Protected on the way to your browser

The public Cube OS service uses HTTPS to encrypt information travelling between your browser and Cube OS. This helps prevent someone on the network from reading it in transit.

Keep a way back.
Keep your own copy.

A mistaken deletion should not mean starting again. Ordinary record deletions go to Trash, where you can restore them until someone with permission deletes them for good. AI requests to delete records need human approval.

Automatic snapshots of production records

An hourly job saves the latest snapshot of your production records, their relationships and their data model while the API is running. Text and JSON record values stay encrypted in that snapshot. The snapshot alone does not contain the keys needed to read them.

That saved copy gives the platform a starting point for recovery. It contains readable numbers, dates, choices and model definitions alongside the encrypted values.

A separate copy you can keep

People with backup permission can download a JSON package containing the records they are allowed to read, the data model, settings, access rules, workflow definitions and a list of attached files. That download is recorded in the activity history. You can also export records as CSV or JSON.

A downloaded package contains readable information. Store it in a private location with access limited to the right people. Download attached files separately if you need your own copies of them.

Recovery expectations during private preview

The hourly job replaces its previous snapshot. It is not a history of every change or an independent off-site copy. A snapshot is not a complete system backup: attached file contents and control settings need separate protection, and encrypted values also need the keys.

Cube OS does not yet publish a guaranteed retention period, recovery time or point-in-time recovery commitment. Full backup restoration is an operational recovery process, not a self-service restore button. If your business needs a particular recovery guarantee, discuss your backup requirements with us before relying on the service.

The right information.
For the right people.

Cube OS checks workspace membership and permissions on the server. Knowing a record identifier or changing a link does not give someone access to another workspace. Production records also have a database check that limits each transaction to its assigned workspace storage.

Within your workspace, roles and access rules can limit which records and fields someone can see or edit. For example, an employee can be limited to their own details while a manager sees their team’s work. These checks happen before information is returned, rather than simply hiding it on screen.

AI follows your rules too

Connecting an assistant is optional. It works under the access of the person who connects it. You can block selected groups of information from AI, or allow totals only so it can produce summaries without reading individual records. Totals-only access also lets it add records.

Data you allow the assistant to use is sent to its AI provider. That provider’s terms and privacy settings apply. Choose the connection and access that suit the information you handle.

Read how AI connections and approvals work · Read our privacy and data-handling page

Security is part of how the product works.

Verified identity

Sign-in verifies identity and email. Workspace invitations are tied to the invited email, expire and can be revoked.

Reviewed changes

Important changes to how business information is organized go through review. Assistant requests to set up workflows or delete records need human approval.

Activity history

See who changed, deleted, restored or exported information and when. The application’s normal database role can add activity events, but cannot update or delete existing ones.

Careful logging

Routine request logs leave out request bodies and search query strings. Workspace troubleshooting details are encrypted when stored.

Safer browsing

Browser security policies restrict where content can load, block framing by other sites and tell browsers to keep using HTTPS.

Controlled transfers

Exports and backup downloads require permission. Request limits help reduce abuse, and exported records follow the person’s access rules.

These controls work together: identity establishes who is asking, permissions decide what they can use, encryption protects stored content, and recovery tools help when something goes wrong.

Clear answers before you trust us with your data.

Tell us what your business needs.

If you have security requirements, need to understand a control or want to report a concern, contact [email protected]. Describe the question without including passwords, encryption keys or private customer records.

Cube OS is in private preview. We can discuss your access, privacy and recovery requirements before you decide to move important business information into the platform.