Security at Cloche

Data protection

App data

Each app has its own database. Lists are shared by default, so everyone who can open the app sees the same entries. Private lists separate entries by signed-in account or share link. People using the same share link share those entries. App owners can manage the saved data. Cloche checks who can read or change each entry.

An app can show live data from another product using each person's own access to that product. The app owner can also keep a copy. Everyone who can open the app can see that copy, including people who cannot access the original. Learn about saving and connecting data.

Encryption

Connections to Cloche use HTTPS. Google Cloud and Cloudflare encrypt the account information, app data, app files, and backups they store for Cloche at rest using AES-256.

Cloche also encrypts credentials for connected data sources using AES-256-GCM before storing them. Google Cloud Key Management Service protects the key that encrypts them.

Hosting and data processing

Cloche operates from Israel. Customer data may be processed in Israel, the United States, the European Economic Area, and other locations described in our privacy policy.

Google Cloud runs the service and stores account and app information. Cloudflare carries traffic and stores app files and backups. WorkOS handles sign-in. Our privacy policy lists providers and explains retention and deletion.

Our data-processing terms require confidentiality from people authorized to process app information. They also require us to notify you without undue delay after we learn of a personal data breach affecting that information.

Access and governance

Authentication

Cloche handles sign-in and verifies app sessions, so builders do not need to build authentication into each app. People can sign in with Google or an email code.

Public apps and apps shared through a link can allow access without signing in.

To discuss your company's single sign-on setup, email hi@cloche.dev.

Authorization

Cloche checks app permissions on requests and saved-data permissions when entries are read or changed. These checks run on Cloche's servers.

Organization Owners can see the organization's apps, pause them, and change who can open them. The Owner role alone does not grant permission to edit another person's app or manage its saved data.

Admins manage members and can review publishing requests. Being an Admin does not grant control over every app.

Owners can enable publishing approval and personal-data checks in organization settings. These are separate settings, both off by default.

Removing a member requires handing their apps to another member. Removal revokes app and folder invitations addressed to their account or current verified email. Public access and existing share links remain until changed.

Sharing and access

New apps are private unless the app owner asks to share them when publishing. An app owner can share an app with named people, through a link, or publicly. Removing an invitation or revoking a share link removes access through it. Other invitations, links, or public access can still let someone in.

A share link does not identify each person who uses it. Email invitations can identify people separately for private entries. Learn about sharing and access.

Publishing safeguards

Publishing and oversight

When an Owner enables publishing approval, a new version waits unless its publisher is a current organization Owner or Admin. Publishing still requires permission to edit that app. One Owner or Admin can approve a waiting version. Their own publishes do not require a second reviewer.

The requester and current reviewers can open a private, read-only preview of the submitted version. Reviewing does not grant new access to saved app data. The current version stays live during review. Reviewers can comment before approving or declining. They must leave a comment when declining. The builder's agent can read the comments and respond in the next publish.

Approval applies to the submitted version.

• Cloche refuses a stale approval that would overwrite a newer live version.
• A replacement publish withdraws the older request.
• Restoring a past version follows the current approval setting.
• Turning approval off does not itself publish versions already waiting.

Reviewers approve in the dashboard. Cloche's agent tools cannot approve requests. Cloche checks the reviewer's current role again when applying the decision.

Secret scanning

Cloche checks text files in a proposed app version for credential patterns, using a maintained, open-source set of detection rules. Examples include cloud access keys, private keys, source-control tokens, payment and AI service keys, and database addresses that carry a password. A match blocks publishing and names the file and line without repeating the secret. Keys their providers document as safe in a web page, such as Google Maps and Firebase web keys and the Supabase public key, are allowed. A version the check cannot finish in time is blocked, not passed.

When on, this check runs for every publish, including publishes by Owners and Admins, and when restoring a past version. It is on by default. An Owner can turn it off in the organization's settings, for apps that are meant to carry a key. A personal space always has it on.

Pattern matching can miss secrets and does not tell you whether a credential still works. The check does not inspect images, PDFs, saved app records, or external systems. It is not a continuous scan or a full code audit.

Allowed destinations

An Owner or Admin can list the outside addresses an organization's apps may reach, then turn on Block everything else. The setting starts off.

When it is on, an app's pages can reach only Cloche, the listed addresses, and the addresses those are known to load from, such as Google Fonts' font host. The browser blocks everything else, on any port. A publish or restore whose files name an unlisted address still goes live, and its answer names the address the browser will block and who can add it.

• An app showing data from a connected source can reach only its own address, whatever the list says.
• The publish note reads addresses written in the files, so it can also name an address in a comment that is never called. An address the app builds while it runs is not named at publish. The browser blocks both the same way.
• The setting covers what an app's pages do in the browser. It does not cover a server the app runs, a page sending the visitor to another site, or direct browser-to-browser connections.
• A page already open keeps its earlier rules until it loads again.
• Owners and Admins see the addresses apps recently tried to reach that are not on the list, as browsers report them, whether or not the setting is on. Cloche keeps only the address name and which app reached it, never the full address it was sent to. Anyone can send such a report, so allowing one asks first.

Personal-data checks

An Owner can enable checks for personally identifiable information, or PII. Cloche checks the text files being published and the names of fields the app is set up to read from a connected source. Findings can include email addresses, phone numbers, payment details, and selected national identifiers. Field names can indicate information such as salary, address, or date of birth.

The check is advisory.

• A finding does not block publishing or require approval.
• The check does not inspect saved app records, live data returned by connected sources, or the contents of images and PDFs.
• Detection does not cover every kind of personal data or every country's identifiers.

A finding records its category, location, and count. It does not store the detected value or a copy of the surrounding text. Results appear with the app version and, when approval is required, in the publishing review.

Owners and Admins can mark a finding as expected. The mark records who made it and when. It carries forward for the same category and location in that app, even if the number of matches grows. A new category or location remains open for review. Marking a finding does not remove data or approve publishing.

Files that cannot be read are marked Not checked. A failed check does not block publishing or count as a clean result. Enabling the setting does not check existing versions. Disabling it stops new checks and keeps previous results. Restoring a version keeps that version's previous result.

Activity history

Organization Owners and Admins can review Recent changes. It records membership changes, app handovers, app removal, publishing requests and decisions, and changes to the publishing-approval setting. Each entry shows who did what, what it affected, and when.

App version history shows changes to an app. Neither it nor Recent changes is a complete record of app visits or data reads. Personal-data setting changes and expected marks do not appear in Recent changes.

Your responsibilities

Your organization decides what each app is for, what data it holds or connects to, and who should have access. App owners choose whether to share an app and whether saved entries are shared or private. Reviewers assess whether a proposed version is appropriate to publish. Automated checks do not make that decision for them.

Our terms require written agreement before apps collect health, payment-card, government-identification, or other information subject to special regulatory or security requirements. A scan result or publishing approval does not replace that agreement.

If your team uses an AI provider to build or work with apps, the provider's terms and data practices also apply.

Security reviews and reporting

For a security review, hosting or data-residency requirements, or to report a security issue, write to hi@cloche.dev.