How the account data is protected.

Access and authentication

• Every product route, every account page and the entire data API sit behind an authentication gate. An unauthenticated request to a page is redirected to sign-in; an unauthenticated request to the data API is refused outright with a 401 rather than being handed a login page to misread.
• The session cookie is checked against a secret held on the server. A cookie hand-set in a browser cannot match it, so the gate cannot be forged from the client side.
• The public marketing page is the only route served without a session — deliberately, and it carries no account data.

Credentials and secrets

• Amazon API credentials live server-side in the runtime environment. They are never sent to the browser, never included in the application bundle, and never written into a release.
• Authentication configuration is owned by the service that runs the application, not by any individual deployment — so a deployment cannot accidentally ship without the login gate in place.
• Requests to Amazon are signed server-side. The browser never holds a token that could be replayed against your Seller Central account.

Transport and hosting

• Everything is served over HTTPS. There is no unencrypted path to the application.
• The application runs on infrastructure controlled by Jack2Media in the United Kingdom, reached through a Cloudflare tunnel. The origin is not directly addressable from the public internet.
• Releases are immutable: a deployment builds a fresh, versioned copy and only switches traffic to it after the build succeeds, so a failed build cannot take the live service down with it.

What Cleave does with your data

• Your account data is never sold, and never shared with other Cleave users.
• It is not used for advertising, and there is no tracking on the marketing site.
• Where a feature calls an external provider, only the material that feature needs is sent. The privacy page lists every provider and what reaches it.
• Missing data is shown as missing. Cleave never invents a figure to fill a gap, which is as much an integrity property as a security one.

What is not in place yet

This is the section most security pages leave out. Cleave is in private early access and the following are honest limitations, not oversights we are hoping you miss:

• There are no per-user accounts yet. Access is invitation-only and managed by hand, so there is no self-serve signup, no per-user audit trail and no per-user revocation. Named accounts are the next authentication change, and they land before Cleave opens beyond the invited group.
• No two-factor authentication yet. It arrives with named accounts — 2FA is only meaningful once each person has their own credential.
• No third-party security certification. Cleave holds no SOC 2 report and no ISO 27001 certificate. Any product our size claiming otherwise at this stage would be worth a second look.
• No published penetration test. None has been commissioned yet.

These are the things we would want to know if the roles were reversed. If any of them matter to you, ask before anything is connected — we would rather have that conversation up front than have you assume something that is not true yet.

Reporting a problem

Found something that looks wrong? Email [email protected] with enough detail to reproduce it. Reports are read by the people who built the product, not a ticket queue. Please give us a reasonable window to fix an issue before publishing it, and we will keep you updated on the fix rather than going quiet.