Home · Resources · Security

Security & data practices

Cricket reads your public website, and — only if you connect them — your Google marketing data and publishing accounts. That's a position of trust, and this page lays out plainly how we handle it: what we store, how access is scoped, what we will never do, and where the honest limits are. No badge-wall, no vague "bank-grade" claims — just the actual practices.

The principles

• Read-only by default. Every data integration requests the narrowest scope the provider offers — Google access is two read-only scopes and nothing more.
• Nothing acts without a click. No draft is ever posted, published, emailed or committed automatically. Publishing actions (X, WordPress, GitHub PRs) fire once per explicit button press, on the specific item you pressed.
• Your data isn't training data. Content processed to build your reports — including Google user data — is never used to develop, improve or train AI/ML models, ours or any third party's. This is a binding commitment in our privacy policy, per Google's Limited Use requirements.
• Honest by design. The product never fabricates data — unmeasured signals show as empty, failed checks are excluded rather than guessed. The same standard applies to this page.

Authentication & access control

Sign-in and session management are handled by Clerk, a dedicated authentication provider — we never see or store your password. Every resource in Cricket is owner-scoped: reports, schedules, chat history, tokens and billing records carry your user ID, and every API endpoint checks ownership before returning anything. Report IDs are unguessable, and knowing one is deliberately not enough — access still requires being its owner.

Connected-account tokens

OAuth tokens (Google, GitHub, X) are stored server-side, keyed to your user and the specific project they were connected for — a token for one site is never used for another. OAuth flows use single-use state values to prevent cross-site request forgery, and disconnecting an integration deletes its stored token immediately. Deleting your account wipes all of them.

Fetching your site, safely

Analyzing a URL means our servers fetch pages you point us at — a classic server-side request forgery (SSRF) risk if done carelessly. Every server-side fetch of a user-provided URL passes through a guard that resolves the address and refuses private, internal and loopback destinations, so the crawler can only reach the public web. User-uploaded reference images are accepted only as inline data or public HTTPS URLs — the server never fetches arbitrary hosts on your behalf for them.

Data storage, transport & deletion

• All traffic is encrypted in transit (TLS); the app is served from Vercel and data lives in a managed Postgres (Neon). Payments are processed by our merchant of record — full card numbers never touch our systems.
• Deleting a project removes its reports, calendar drops and daily schedule, and cancels its subscription so nothing keeps billing in the background.
• Deleting your account (Settings → Danger zone) erases everything we hold across every store — reports, schedules, chat history, done-marks, connected-account tokens and billing entitlements — and can delete the sign-in identity itself. This is a self-serve GDPR erasure, not a support ticket.

Community safety — your accounts stay yours

The Reddit and community agents never touch your accounts: discovery uses public data, drafts are written for you to review and post, and every draft honestly discloses your affiliation. We built it this way because undisclosed automated posting is how accounts get banned and reputations get burned — the safety-graded, human-posts-it model is a feature, not a limitation.

Monitoring & transparency

We run structured error tracking and a public status page fed by the same health endpoint our own monitoring uses — it reports uptime and which integrations are live, and never exposes secrets. Significant incidents and changes ship to the changelog.

Honest limits

We're a young product and say so: we don't yet hold formal certifications like SOC 2, and we won't claim badges we haven't earned. What we can promise is the engineering above, narrow scopes, real deletion, and fast, honest communication when something goes wrong.

Reporting a vulnerability

Found something? Email support@cricketai.io with the details and steps to reproduce. We read every report, respond as fast as we can, and will credit you if you'd like once it's fixed. Please give us a reasonable window to patch before public disclosure.