# Cohesivity — Privacy Policy

Effective: 2026-08-10

This is a plain-language policy for cohesivity.ai and the Cohesivity API. Questions: accounts@cohesivity.ai

## What we collect

- **Ephemeral tenants** (created at project setup, no signup required): We generate tenant credentials and keep tenant metadata, usage counters, and request telemetry (request IDs, timing, status codes). For abuse prevention and forensics we also record the request **origin signals** at tenant creation — client IP address, User-Agent, network ASN, country, and the (untrusted) X-Forwarded-For header — on the tenant record. An IP address can be personal data under GDPR/CCPA, so this is more than nothing: our lawful basis is our legitimate interest in detecting and preventing fraud and abuse (GDPR Art. 6(1)(f)).
- **Setup attribution (agent runtime)**: when the `quickstart.sh` or `npx @cohesivity/init` setup flow creates a tenant, it identifies the coding agent that launched it by walking its own parent processes, and sends that one name. This is recorded on the tenant row for attribution and abuse forensics under the same legitimate-interest basis as the origin signals above (GDPR Art. 6(1)(f)); when nothing can be inferred, "none" is sent. Nothing else about your machine is read or transmitted: the setup flows do not list your running processes, and do not read your coding agent's session logs, conversations, or model settings.
- **Setup (machine) id**: the `npx @cohesivity/init` and `quickstart.sh` setup flows store an opaque random identifier on your machine (`~/.config/cohesivity/machine-id`) and send it when creating a tenant. Because each project gets its own `.cohesivity`, this is what tells us that several tenants came from one setup rather than several unrelated people; we use it to understand how many projects a machine creates and how many are kept, and to size and improve onboarding. It is a random value issued by us — it is **not** derived from your hardware, hostname, username, MAC address, or any device fingerprint, and it carries nothing about you or your project. It is a device identifier under GDPR, and our lawful basis is our legitimate interest in understanding and securing product setup (GDPR Art. 6(1)(f)). Deleting that file ends the association; the next setup run is issued a new, unlinked id.
- **Website setup ref**: when you copy the onboarding prompt on our website, we generate an opaque random identifier and hold it against your public IP addresses for five minutes. Because your browser and the setup tool can reach us over different address families, the site also reads your IPv4 and IPv6 addresses from Cloudflare's address-echo service (`icanhazip.com`) so that either one can be matched; Cloudflare already handles every request to this site, so this adds no new recipient of your address. If a project setup reaches us from any of those addresses inside that window, we record the identifier on the tenant, which is what tells us a setup followed a visit to the site rather than arriving from nowhere. It is a random value issued by us — it is **not** derived from your hardware, browser, or any device fingerprint, and it carries nothing about you or your project. The association is an inference from timing and network rather than a confirmed link, and it is stored as one; where more than one visitor shares an IP address we record nothing at all. It is a device identifier under GDPR, and our lawful basis is our legitimate interest in understanding how setup begins (GDPR Art. 6(1)(f)). Setting up from a different network than you browsed from, or never using the copy button, leaves no association.
- **Origin signals at claim and account creation**: we record the same origin triple (IP, ASN, country) when a tenant is claimed and when a Cohesivity owner account is first created, for the same abuse-prevention purpose. Raw User-Agent is stored only at tenant creation, not on claim or owner-account rows.
- **Ephemeral Steel Browser abuse admission**: when an ephemeral tenant provisions Steel Browser, we derive an opaque HMAC identity hash from the authoritative exact genesis IPv4 address or IPv6 `/64` plus bounded ASN/country enrichment when available. The address and dedicated HMAC secret remain mandatory; missing or malformed optional enrichment is normalized instead of making Steel Browser unavailable. The admission and aggregate-budget tables store only that hash, tenant id, timestamps, and Browser usage counters — no additional raw IP, User-Agent, key, or token. This lets temporary tenants sharing one egress consume a bounded common budget without treating a different tenant id as abuse by itself.
- **Steel Browser activity**: Cohesivity stores local session ownership, lifecycle, duration, and usage records. CDP frames are relayed opaquely without payload logging by Cohesivity, while target URLs, page content, and provider-side session artifacts are processed by Steel.dev. Its public Scale plan advertises retention of up to 14 days and Cohesivity has no custom DPA or SLA for this offering.
- **Claimed accounts**: when a builder claims a tenant through the one-click approval flow, we store the account email and the authentication identifiers returned by the sign-in provider.
- **Remote management MCP OAuth**: when an MCP client dynamically registers, we store its generated client id, client name, exact redirect URIs, supported public-client grant types, and status. When an owner approves access, we store a short-lived account-wide grant with approved scopes, the canonical management MCP resource, redirect URI, PKCE S256 challenge, expiry, and an optional owned tenant selected only as a convenience default. The grant can be approved when the account owns no tenants, covers current and future owned claimed tenants within its scopes, and never treats the default as proof of ownership: every tenant tool call checks current account ownership again. Authorization codes, access tokens, and refresh tokens are high-entropy bearer values returned to the client and are never stored recoverably; Cohesivity stores only their full one-way SHA-256 hashes plus expiry, rotation, consumption, family, and revocation metadata. Authenticated tenant creation also stores only the idempotency-key hash and resulting tenant id. For human-completed claim, payment, domain-verification, and provider-device flows, MCP returns the required URL or user code plus a random operation handle; only the handle hash, account/client/scope binding, optional tenant id, typed `{type,rid,exp}` wait descriptor, status, expiry, and sanitized terminal result are stored. Existing raw wait bearers, auth headers, and shell commands are neither stored nor returned through MCP.
- **Inbox content**: when a tenant provisions Inbox, we store sender and recipient addresses, subject, text and HTML bodies, attachment metadata, delivery state, and threading identifiers in that tenant's provisioned Neon Postgres database under the reserved `coh_inbox` schema. We store raw inbound MIME, including inbound attachments, in a private Cloudflare R2 bucket. When a claimed tenant configures an inbound webhook, Cohesivity sends the event type and message id to that tenant-supplied HTTPS URL; message content is not included. Email may contain personal or sensitive data; the tenant controls what its agents send and which messages they keep.
- **Billing**: payments are processed by Razorpay. We store plan and subscription state, payment-link identifiers, and wallet/ledger records. Card, UPI, and bank details go directly to Razorpay and never touch Cohesivity.

## Upstream providers

Cohesivity provisions resources from upstream providers (for example Cloudflare, Neon, Vercel, OpenAI, Deepgram, Exa, Steel.dev, and Razorpay) and proxies requests to them at the edge, injecting provider credentials so you never handle upstream keys. Data you store in or send through a provisioned resource is processed by that upstream provider to deliver the service. Inbox uses Cloudflare Email Service for inbound routing and outbound transmission, and private Cloudflare R2 for raw inbound MIME. Cohesivity uses Resend internally for account and billing emails.

## What we do not do

- We do not sell personal data and do not run ads.
- We do not use tenant application data for anything beyond serving requests, metering, debugging, and abuse prevention.

## Retention and deletion

- Unclaimed ephemeral tenants and their resources are terminated after the 72-hour claim window expires; the tenant record and its origin signals remain for audit and abuse forensics until an account-deletion or data request covers them.
- The setup (machine) id persists on the tenant record for the life of that record and in a machines table recording first-seen, last-seen, and the coding-agent runtime that first used it; deleting a tenant removes its copy, and a data-deletion request covers the machines row.
- The website setup ref persists on the tenant record for the life of that record, together with the measured delay between the copy and the setup; the short-lived copy-time record it is drawn from expires within minutes and is discarded unattached when no setup matches it. Deleting a tenant removes it.
- Claimed tenants persist until you tear them down via the Management API or ask us to close the account; deleting a tenant removes its origin signals along with the rest of the tenant record.
- Ephemeral Steel Browser identity mappings and aggregate-budget history are separate from the tenant row and survive tenant and resource teardown for 30 days. Bounded lifecycle cleanup then deletes them after the enforcement/audit horizon.
- Steel Browser session traffic and artifacts may remain at Steel.dev for up to 14 days under its published Scale retention window, independently of Cohesivity resource teardown.
- Origin signals copied into our operational logs (Axiom) expire automatically at that dataset’s 30-day retention.
- Origin signals stored on a Cohesivity owner-account record persist for the life of the account; we clear them on request as part of a data-deletion request.
- Active MCP client registrations persist so a registered public client can reconnect and can be approved by more than one owner account; they are client-global rather than owned by the first account that uses them. Expired approval requests, authorization grants, and operation handles are removed in bounded cleanup batches. Rotated or expired token rows are removed only after both their access and refresh validity windows have ended, preserving live refresh families and revocation/replay enforcement. Deleting one tenant clears it as an OAuth convenience default and removes tenant-bound operation handles, but does not revoke an account-wide grant; later calls still need a fresh ownership match. An account/data-deletion request covers that account’s user-bound grants, token families, creation-idempotency rows, and operation handles, and can also cover client registration metadata.
- Inbox messages have fixed 30-day retention on every tier. Deleting a message removes its normalized record and raw inbound MIME immediately; tearing down Inbox removes its messages. Account deletion keeps only permanent identity tombstones for the former canonical and vanity addresses so those identities cannot be reassigned.
- For account-deletion or data requests, email accounts@cohesivity.ai.

## Changes

We will update this page when our practices change; the effective date above moves with it.

## Contact

accounts@cohesivity.ai

Terms of service: https://cohesivity.ai/terms
About the company: https://cohesivity.ai/about