Privacy Policy

This policy covers three groups of people: visitors to this website, people who use the camada app, and end users of the applications our customers protect with the camada SDK.

Who we are

camada is operated by Camada Labs, LLC ("camada", "we", "us"). We are the controller of the data we collect about visitors to camada.app and about people who use the app at my.camada.app. For traffic to our customers' applications, the customer is the controller and we process that data on their behalf as their processor, under our data processing agreement. The one exception is the cross-customer security data described under "Data we use across customers", which we control ourselves.

Contact for anything in this policy: privacy@camada.app.

This website

This site sets no cookies and uses no local storage. When enabled, we use Cloudflare Web Analytics, which is cookieless and does not fingerprint visitors, to count page views. Cloudflare serves the site and processes standard request data (IP address, user agent, the page requested) to deliver and protect it. If you email us, we keep the email and our reply.

The app

When you use my.camada.app we process:

• Account data: your name, email address, user id and the organizations and roles you belong to. Sign-in runs inside camada (Better Auth, open source), by an email code sent through Postmark or by Google if you choose it. camada records sign-in events and uses no third-party authentication processor.
• Invitations: the email address of anyone you invite, until the invitation is accepted, revoked or expires.
• Billing data: your plan, subscription status, invoices and usage. Stripe, our payment processor, collects and processes your card details; the card number never reaches us. We receive the card brand, last four digits, expiry and country, and a Stripe-generated card fingerprint.
• Audit log: every change made in the app, with who made it, what changed (before and after), the IP address and the user agent. Sessions in which camada staff open your organization are logged the same way, with the reason they gave.
• Chat and memory: what you ask the chat assistant, its answers, any thumbs up or down and note you add, and the facts saved to your project's memory.
• Support requests: what you send through the support portal, your name and email address, and any files you attach.
• Trial records: a normalised copy of the email address that started a free trial, kept so the same address cannot start a second one, and the Stripe fingerprint of the card used to start the trial (a code Stripe derives from the card; it is not the card number and cannot be used to make a payment), kept so the same card cannot start a second trial.
• Settings and preferences: project settings, alert destinations you configure (email addresses, Slack and webhook URLs) and display preferences.

The app sets a session cookie when you sign in; the cookie policy lists every cookie.

Traffic to customer applications

When a customer installs the SDK, it sends camada one event for each request to their application. An event holds:

• the method, host, path and query string, with any query value that looks like a password, token or key replaced before it leaves the application;
• the response status and how long the response took;
• header names, count, sizes and order, and the values of User-Agent, Accept, Accept-Language, client hints, Sec-Fetch-*, Content-Type, Content-Length, Referer (with credential-like query values replaced), Origin and X-Requested-With, plus the name of the Authorization scheme (never the credential) and the number of cookies (never their values);
• the client IP address, and, where the SDK runs at a position that exposes them, the network (ASN), country and TLS fingerprint. Where an event has no ASN or country we look them up from the IP address in local copies of public databases (iptoasn.com and DB-IP); the IP address is not sent anywhere for this;
• a random session id from the _sfp cookie and a per-request id;
• whether the client passed a challenge, and which block or rule applied;
• outcomes the application reports with track(), such as a failed login or a payment, with the user identifier replaced inside the customer's application by a keyed hash (HMAC). We cannot reverse the hash, but it still identifies the same user across events, so we treat it as personal data.

If the customer turns on the browser beacon, a script on their pages also sends: screen and window size, pixel ratio, timezone, languages, platform, CPU core count, device memory, touch support, the browser's Do Not Track setting, connection type, WebGL renderer, hashes of a canvas drawing and of math results, automation flags, browser version details from client hints, page timing, and counts of mouse moves, scrolls, key presses, touches and clicks (never which keys or where). The beacon sets no cookies and writes no storage. A customer on Cloudflare can also send its Cloudflare request logs, which carry similar fields plus Cloudflare's own bot and attack scores.

The SDK never sends request or response bodies, cookie or Authorization values, or raw user identifiers. A path can still contain personal data if the customer's application puts it there (for example, an email address in a URL); we store it as received.

IP addresses, session ids, hashed user identifiers and device characteristics are personal data. We process them for the customer to:

• detect automated, abusive and malicious traffic against the customer's application, by scoring each client with fixed rules and, for suspicious clients, with language models (see below);
• produce the blocklist, challenge list and rules the customer's SDK enforces;
• show the customer what happened: verdicts, request timelines, alerts by email, Slack or webhook to destinations the customer chooses, and answers from the chat assistant.

Automated decisions

Scoring and verdicts are automated. A language model writes the verdict for a suspicious client, with the evidence it relied on. Whether a verdict leads to a block or a challenge is the customer's choice: during a project's learning period, on the Free plan, and under the "recommend" policy, verdicts are recommendations only. Customers can review every verdict, allow or clear a client, and remove blocks. If you think a site wrongly blocked or challenged you, contact the site; its operator can review the decision and allow you.

Language models

All model calls run on Cloudflare Workers AI, through Cloudflare AI Gateway, inside Cloudflare. No other model provider receives the data.

• Traffic analysis: triage runs on Llama 3.3 70B and investigation on DeepSeek V4 Flash. The model sees the client's key (such as its IP address), samples of its requests (paths, query strings, user agents), the computed features and scores, and context the customer has added.
• Chat assistant: GLM 5.3 Flash, with Llama 3.3 70B as a fallback. The model sees your question, the conversation so far, and the project data its tools read to answer, which can include IP addresses and request samples.
• Memory search: facts and summaries are turned into embeddings with BGE-M3 and stored in Cloudflare Vectorize.

These models are hosted by Cloudflare; the companies that published them do not receive the data. We do not use customer data or end-user data to train or fine-tune models. AI Gateway keeps a log of each call, including its input and output, which we use to debug the service. Tracing of model calls to a Langfuse server camada would host itself is off; if we turn it on, we will list it on the sub-processors page first.

Data we use across customers

To protect all customers, we keep two small datasets that combine signals from different customers. We act as controller for these, for the purpose of network and information security.

• Reputation: when a project's analysis reaches a malicious verdict on an IP address or TLS fingerprint, we record that key, the verdict and a count for seven days. The record does not say which customer it came from. An IP address scores higher at another customer's project only when at least three other paying organizations, each past its learning period, reached a malicious verdict on it in the last seven days; we count them from the verdicts each project already keeps. Trial projects and the customer's own organization do not count, and an address the customer allowed, cleared or ignored is not raised. TLS fingerprints are not scored this way; the investigation model can read their record as context. No customer can see another customer's traffic or learn who flagged a key.
• TLS fingerprint popularity: to tell a rare TLS fingerprint from one shared by many ordinary browsers, we record, for each fingerprint and project, a shortened SHA-256 hash of the client's address (for IPv6, of its /64 network). We keep these for eight days and count how many distinct networks across all customers used each fingerprint. The hash is pseudonymous, not anonymous.

Why we use it

For data we control, the legal bases under the GDPR and UK GDPR are:

• to provide the app, your account, alerts and support: performance of our contract with you or your organization;
• to keep billing and tax records: compliance with legal obligations;
• to keep the audit log, secure the app, prevent abuse of free trials, run the website and the cross-customer datasets above: our legitimate interests in securing our service and our customers' services and in running our business.

For traffic to customer applications, the customer decides the legal basis as controller.

How long we keep it

When a customer deletes a project, its data is removed from our live systems at once, except raw events, which age out within 7 days, and hourly counts, which go within 7 days. Our databases keep point-in-time recovery for 30 days, so deleted data is gone everywhere within 30 days. Customers can request an export of a project's data as JSON.

Closing an account: to close your organization or your user account, write to privacy@camada.app. We delete the account data within 30 days, except billing records we must keep by law and the trial records described above (the normalised email address and the card fingerprint).

Who we share it with

We do not sell personal information and we do not share it for cross-context behavioural advertising. We use no advertising cookies or trackers. We share data only:

• with the sub-processors that run parts of the service for us;
• with destinations a customer configures, such as their own Slack workspace, webhook endpoint or email addresses for alerts;
• when the law requires it, or to protect the rights, safety or security of our customers, their users, or us.

Where data is stored

Data is processed and stored on Cloudflare's global network, so it can be processed in any country where Cloudflare operates. We do not yet offer EU-only residency. Stripe and Postmark process data in the United States. Where data protection law requires a safeguard for these transfers, we rely on the standard contractual clauses [to be confirmed by counsel].

Security

Redaction happens inside the SDK before anything is sent; traffic is encrypted in transit; project keys are stored hashed; staff reach a customer's organization only through a logged, time-boxed session with a stated reason. The security page has the details.

Your rights

Depending on where you live, you may have the right to access your personal data, correct it, delete it, receive a copy in a portable format, object to or restrict our use of it, and withdraw consent where we rely on it. Residents of California and other US states with privacy laws can ask what we collect and why, and ask us to delete or correct it; we will not treat you differently for using these rights, and you may use an authorised agent. To use any of these rights, write to privacy@camada.app. We may need to confirm who you are. We answer within the time the law sets, for example one month under the GDPR. You can also complain to your data protection authority.

If you are an end user of a customer's application, that customer controls your data: contact them first and we will help them answer. If you write to us, we will pass your request to the customer when we can tell which one it concerns.

Children

camada is a service for businesses and is not directed to children. We do not knowingly collect children's data as a controller. A customer's application may have younger users; that data is the customer's, as described above.

Changes

We will post changes here and update the date at the top. For material changes we will also tell customers by email before they take effect.