# Cohesivity — Privacy Policy Effective: 2026-07-19 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)). - **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. - **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. - 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. - 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