Privacy

CREAO respects your privacy and gives you control over your data.

What data does CREAO collect?

CREAO collects the minimum data necessary to provide the service:

Account data — email address, name, and authentication credentials
Event registration data — on event-specific registration pages, CREAO may collect your name, professional role, practice area, experience range, an optional question, and a referral source tag to estimate attendance and tailor the session. Event forms do not request client names, matter details, identity-document numbers, or uploaded files. Responses may be submitted directly to a Google Workspace Sheet controlled by the event organizer rather than stored in CREAO’s product databases
Developer profile — optional display name, company, and website you provide on the developer portal (developer.creao.ai). Keyed to your account and deleted when your account is deleted
Developer API keys — when you create Account API keys for the Developer Platform, CREAO stores the key label, HMAC token hash, public token prefix/preview, creation and revocation timestamps, and last-used-at timestamp for validation, revocation, audit, and abuse prevention. The raw API key is shown once at creation and is never stored. Account API keys can create, edit, and run personal agents owned by your account, and can manage those agents’ long-term memory and skill file space as described below. Key rows are deleted when your account is deleted
Developer API agent data — when you create or edit personal agents through the Developer Platform, CREAO stores the agent definition in the same encrypted agent resource store used by the main CREAO app, including agent name, description, version, skill instructions, app configuration, dashboard template, write-autonomy setting, release note, and timestamps. These agent rows are deleted when your account is deleted
Developer API agent memory — when you read, overwrite, or clear a personal agent’s long-term memory through the Developer Platform (/v1/agents/{agent_id}/memory), CREAO retrieves or updates reflection playbooks for that agent via CREAO’s reflection service. Overwrite and clear operations send playbook content and status to that service; read responses return playbook identifiers, names, content, triggers, rationales, statuses, and timestamps. CREAO does not store a separate Developer API copy of these playbooks beyond ordinary request logging described below; source playbooks remain in the reflection service and are purged when the underlying agent is deleted
Developer API agent files — when you list, download, or delete files in a personal agent’s skill file space through the Developer Platform (/v1/agents/{agent_id}/files), CREAO uses the same encrypted file registry and object storage used by the main CREAO app for that agent’s skill folder (including auto-staged skill files such as SKILL.md). List and download responses include file identifiers, names, MIME types, sizes, content hashes, timestamps, and short-lived presigned download URLs. Delete removes the registry row and the stored object. These files are deleted when your account is deleted, or when you delete them via the API or the product UI
Developer API run data — when you start async or realtime agent runs through the Developer Platform, CREAO stores the request identifier, agent/conversation/thread/session identifiers, run mode, status, timing, input JSON payload, result JSON payload, error metadata when a run fails, and credits used. If you configure a webhook URL, CREAO also stores that URL and delivery timestamp and may POST the run output to the developer-configured endpoint. Run rows are deleted when your account is deleted
Developer API request logs — when an authenticated Account API key request reaches a /v1/* Developer API route after authentication and account rate-limit checks, CREAO stores one request-log row with your account identifier, Account API key row identifier, HTTP method, route pattern and path, handler name, status or error code, created or fetched run identifiers where applicable, agent and conversation identifiers where applicable, timing, request and response byte counts, and credited usage when the call creates a billable run. CREAO does not store request payloads, response payloads, headers, raw API keys, or tokens in this request log. Rows are deleted when your account is deleted
Conversation data — messages, files, and artifacts you create during chat sessions. On iOS and Android, URLs, text, and files shared into CREAO from other apps through the system Share sheet are treated as chat attachments and retained under the same conversation data policy. When CREAO’s reflection analytics/retrieval is enabled, user turns and selected assistant final-turn summaries (with compact tool metadata) may be processed by CREAO’s reflection service for quality monitoring, and your current query text may be used by CREAO’s reflection search to retrieve relevant profiles/playbooks
Usage data — credit consumption, feature usage, acquisition attribution (UTM parameters, click IDs such as Google click ID (gclid), Meta click ID (fbclid), and Impact affiliate click ID (IM_REF), referring site, landing path, owner-derived affiliate or referral attribution from public shared-thread and agent-install pages, and KOL-defined affiliate sub-tracking parameters such as media or sub_id), session metadata for billing, analytics, and product improvement. When Google Analytics or Google Ads conversion measurement is enabled, CREAO also sends your CREAO user identifier (after sign-in), first-touch campaign/referrer parameters, Google click ID (gclid), the browser GA4 client identifier derived from the _ga cookie and, on agent run requests where a live session is active, the session identifier derived from the _ga_<container> cookie, conversion events, and the signed-in email address for sign-up and purchase enhanced-conversion matching; the Google tag hashes email data before Google receives it for matching. When Meta Pixel or Meta Conversions API measurement is enabled, CREAO may send hashed email, hashed CREAO user identifier, IP address, user agent, Meta browser/click identifiers (_fbp, _fbc), and sign-up or purchase conversion events to Meta for attribution matching; no conversation content is sent for these analytics events
Billing coupon data — when a one-time subscription coupon is created or redeemed, CREAO stores the coupon code, campaign type, discount terms, optional internal distributor note, Stripe coupon/promotion identifiers, and admin/redeemer attribution needed to prevent reuse, reconcile checkout, support customers, and audit discount issuance. Redeemer email is visible only to CREAO admins and is removed if the redeemer’s account is deleted
Affiliate and referral billing data — when you join or use an affiliate referral campaign, CREAO may store referral handle attribution, KOL account identifiers, configurable commission rates, invitee reward credit grants, and related credit ledger metadata so rewards, revenue share, and payouts can be calculated and audited. For Impact.com affiliate campaigns, CREAO may send eligible sign-up, subscription, and credit-purchase conversion records to Impact.com for partner attribution and reconciliation; these records may include SHA1-hashed email, CREAO user ID, Impact click ID, order ID, conversion timestamp, event type, subscription or purchase amount, and promo code
Memory data — facts and preferences the super agent saves on your behalf (you can view, search, and delete these at any time). When you work in an organization context, memories are stored in a shared team pool visible to all members of that organization rather than in your personal memory
Login geolocation — a location estimate derived from your IP address is recorded with each login event. A country code (ISO 3166 alpha-2, from Cloudflare) is used for analytics, abuse detection, and billing routing. CREAO may also derive and store a coarse city/region estimate — from Cloudflare’s edge geolocation of your IP on live logins, or an offline geolocation database applied to the stored IP for historical (backfilled) estimates — used for regional product analytics and to segment location-relevant CREAO communications (see Location-based communications below). When derived, this estimate is approximate — it reflects your network’s location, not a precise position, and can be wrong (for example with VPNs or mobile carriers). No GPS or precise-location data is collected, and only the coarse city/region estimate — never the raw IP — is shared with our marketing-automation subprocessor (customer.io) for this purpose, and only for users outside the EU/EEA/UK (see Location-based communications below)
Location-based communications — CREAO may use the coarse city/region estimate described above to segment marketing and lifecycle emails by area (for example, an event or announcement relevant to your metro). This applies to users outside the EU/EEA/UK: because CREAO does not yet operate a per-user consent mechanism for this purpose, users in the EU/EEA/UK are excluded from location-based marketing segmentation entirely, and their location estimate is not shared with our marketing-automation subprocessor for it. You can opt out of marketing emails at any time via the unsubscribe link or your notification settings
Dream profiles — AI-generated summaries of your preferences, working style, and recent activity, derived from your conversation history. These are created automatically (daily) or on demand, and can be viewed from the Memory → Dream tab
Reflection playbooks — Reflection-generated workflow rules inferred from your CREAO interactions. When enabled, you can view your own playbooks from the Memory page. CREAO retrieves source playbooks from CREAO’s reflection service on demand; when retrieved playbook snippets are used as context during a conversation, those snippets are stored as part of the message content blocks in conversation history and retained until the thread is deleted
Linked social profiles — when you connect an X (Twitter) or Discord account from the Rewards hub or Account Settings, CREAO stores the provider account ID, username, display name, and avatar URL so the UI can show which accounts you have linked. For Discord we also retain the OAuth access token so reward verification (CREAO server membership) can run without prompting you to re-authenticate. For X, the OAuth token is used only at link time to confirm account ownership — CREAO does not call back to X to read your follows, posts, or social graph. To prevent reward-farming via re-binding, an X or Discord identity that has been linked to a CREAO account is bound permanently to that account — it cannot be disconnected from the UI. As a security measure, linked profile data and stored OAuth tokens are also removed automatically whenever your authentication state is revoked (password reset, admin force-logout, account ban) — this prevents an attacker who briefly held a session cookie from leaving an attached account behind after the rightful owner regains control. They are otherwise removed only when you delete your CREAO account, at which point all linked profile data and stored OAuth tokens are deleted with it. You can still revoke CREAO’s access at any time from your provider’s settings (X → Connected apps, Discord → Authorized apps), which invalidates the stored token immediately
Campaign participation data — if you join a CREAO campaign or challenge, CREAO may store campaign-specific enrollment state, eligibility checks, public leaderboard identity, and setup metadata. For the Agent Trading Campaign, this includes Season 1 submitted WEEX email/UID, Season 2 submitted debot email and Robinhood Chain wallet address, the linked X profile used as your public leaderboard identity (x_username, x_provider_account_id, display name, and avatar), Discord link and CREAO Discord server membership requirements where applicable, your selected CREAO agent app ID, your user-chosen public leaderboard agent name/slug, Agent API Trigger setup metadata, readiness/freeze audit hashes, and disqualification/finalization status. For the optional Season 2 Kite Agentic Wallet side event, CREAO may also store your cloned Kite agent app ID, which Passport skill paths were installed on your CREAO account (authenticate-user, kite-passport, wallet-send), the Base-chain wallet address you confirm, wallet/deposit/transaction verification timestamps, a verified Base deposit balance (USDC), a submitted Base transaction hash, side-event completion status used for the leaderboard Kite badge and score bonus, and reward-credit grant status/timestamps for enrollment-lock and Kite-completion bonuses. Total CREAO credits consumed may be used to determine prize eligibility; public campaign pages may show eligibility status or prize-claim rank, while exact credit totals are visible only to you and CREAO admins
Campaign financial performance data — for trading challenges, CREAO may use the WEEX API credentials you configure in CREAO Secrets to request demo-account balance and order data from WEEX during a WEEX-backed campaign. For Robinhood/debot-backed campaigns, CREAO may check your submitted Robinhood Chain wallet balance at enrollment, receive Debot monitor callbacks on a CREAO community Agent webhook wrapper (which forces phase-based dry-run when appropriate, then forwards to your Platform Agent app), and import wallet equity, PnL, trade count, trade history, and funding history from debot or the Robinhood chain for ranking and audit. CREAO stores leaderboard snapshots such as USDT or ETH equity, PnL, and trade count for ranking, audit, and results pages, and may persist size-bounded Debot callback payloads (plus a payload hash, event id, dry-run flag, phase, HTTP status, and dispatch outcome) in s2_trading_challenge_api_invokes for My Entry history, idempotent retries, and admin dry-run testing. For the Season 2 Kite Agentic Wallet side event, CREAO may query a Base-chain RPC endpoint with your confirmed Base wallet address and submitted transaction hash to verify deposit balance and that the transaction succeeded and originated from that wallet; CREAO stores the resulting verification metadata (not a private key) in s2_trading_challenge_kite_side_events. CREAO does not store your raw WEEX API key, secret, passphrase, or debot developer API credentials (DEBOT_API_KEY / DEBOT_API_SECRET) in the campaign database, and never collects a wallet private key for debot-backed campaigns or for the Kite side event. During the audit phase, authorized campaign admins may export campaign credentials from the secrets store to verify trading history; these exports are logged as administrative actions
Scheduled-run result delivery — when you enable “Email me a summary” on a scheduled agent app, CREAO sends a summary email after each run. We store the email delivery record in schedule_email_deliveries (schedule ID, run status, delivery outcome, and timestamp). These records are deleted automatically after 30 days by a nightly cron. The delivery setting is off by default and can be changed at any time from the schedule settings
In-app notifications — when an agent run you started reaches a notifiable state (chat and workflow completions, awaiting your input, run failures, a workflow approval pending, running out of credits, an action awaiting approval, or an organization invite), CREAO stores an in-app notification inbox row in notifications. Each row holds the notification reason, the related thread / agent-app / session identifiers, a stable i18n key plus structured parameters used to render the localized message, and its read state. By default, no conversation content, message text, or generated output is stored — only stable keys and identifiers. The Account Settings “Show names in notifications” toggle is off by default; if you opt in, the related chat thread’s title (which for an ordinary chat thread defaults to the start of your first message, truncated to 100 characters), agent app name, and/or organization name are also stored in that row and rendered into the notification copy, including the push body sent to Apple (see the Apple/APNs row below). Account-level and per-schedule controls let you decide whether completion notifications are eligible for delivery. Notification rows are deleted when your account is deleted
Push device registration — if you enable push notifications on the CREAO mobile app, CREAO stores one row per device in push_devices so it can deliver notifications to that device. Each row holds the device push token (an opaque delivery credential issued by the platform’s push service, treated as a secret — never displayed back to you and never written to logs in raw form), the device platform, the delivery environment, the app version and device locale captured at registration (used to localize push copy), and lifecycle timestamps (first registered, last seen, and a disabled marker). No message content is stored. You can remove a device at any time by disabling push notifications or signing out; device rows are hard-deleted when your account is deleted
Team-collaboration attribution — when you and other members work in the same organization, CREAO stores the user identifier of the team member who sent each message, uploaded each file, or performed each tracked action so collaborators can see each other’s display name and email next to those entries (in chat, shared files, and the organization activity log) and know who did what. This attribution is visible only to other members of the same organization — never to users outside the org or to anonymous visitors of a shared link. Any member of the organization can PUBLISH an agent they created to the whole organization, making its configuration visible and runnable by every other member — publishing is treated as ordinary collaboration and is not restricted to owners or admins. (Connecting a new data source is restricted: that stays with organization owners and admins.) For a shared agent app, sharing covers only the agent’s configuration: each member’s own runs, generated outputs, and pending action approvals are private to that member and are not visible to other members (including the agent’s creator). Any member of the organization can schedule a shared agent app to run on a recurring basis; a schedule a member creates is owned by and billed to that member, and its runs and outputs are private to them under the same per-member rule. Editing, pausing, or deleting a schedule is limited to the member who created that schedule — not the agent’s creator or the organization owner. All members can view the agent’s schedules read-only, including each schedule’s configuration and the name and email of the member who created it. Per-agent access delegation — an agent’s owner (its creator) or an organization owner/admin can grant another member of the same organization a role on a specific agent: manager (edit and delete the agent’s configuration) or viewer (run it). CREAO stores one row per grant recording the agent, the member granted, the role, and who granted it, so the access list can be reviewed and audited. A grant can only be given to a current member of that organization, and it stops conferring access the moment that person leaves the organization — their grants are also purged during removal. Organization owners and admins hold full permission over every agent in their organization regardless of who created it. Converting a shared agent back to personal withdraws all delegated access
Organization invite emails — when an organization admin invites a new member, CREAO stores the invitee’s email address in org_invites to deliver the invitation and track its status (pending, accepted, or revoked). The invitee may or may not have an existing CREAO account. When the invite reserves a specific paid seat for an email that has no CREAO account yet, the record also links that reserved seat (seat_id); if the invitee then signs up with that email, the invite is accepted automatically and they join the organization and occupy the reserved seat as an organization-only account (no personal workspace). Invite records are deleted when the invitation is revoked by an admin, when the organization is deleted (FK cascade), or when the invite expires. Accepted invites retain the email for audit purposes until the organization is deleted
Action approvals — when an agent or chat session proposes a guarded write through a connector (email, social media, messaging, etc.), CREAO stores the proposed action payload (for example tweet text, email subject, or message content), validation results, approval status, approver/rejector audit metadata, and apply result so you can review, approve, reject, retry, and audit external actions. This applies to both Agent App sessions and regular chat threads
Workflow orchestration data — when a dynamic workflow is staged (via the /workflow command, or when the agent proposes one in ordinary chat) and you approve it, CREAO stores approved workflow definitions (name, description, and JSON task spec), workflow run and task execution records (status, task prompts, summaries, parent-thread artifact copies, and per-task cost), and append-only progress events so the host can schedule, pause, resume, cancel, retry, and audit the workflow
Slide deck generation data — when you use the /slide command, the deck outline the agent authors from your prompt (slide titles, bullet text, and metric labels) is processed transiently by CREAO’s rendering service to produce your deck; the outline itself is not stored outside your conversation history. The finished PDF and PPTX are saved to your thread’s encrypted file storage and retained under the same policy as other generated files and conversation data
Agent Store engagement — when you interact with agents in the public Agent Store, CREAO stores your likes, bookmarks, shares, written reviews (with star rating), and view impressions. View impressions include your account ID when you are signed in and a SHA-256 hash of your IP address (truncated to 16 hex chars) for deduplication only — no raw IP, user agent, or precise geolocation is stored.
Discover Skills install activity — when you install a community-recommended skill from Discover Skills, CREAO records the Discover Skills entry and your user ID so we can keep install counts accurate and avoid double-counting repeat installs
LLM transaction forensics — when the super agent calls a large language model on your behalf, CREAO stores per-request invocation metadata for billing accuracy and abuse prevention: source IP address (from cf-connecting-ip), user agent, country code, Cloudflare edge-location code (cf.colo), provider name and request path, token counts, cache status, JWT issued-at and age, upstream response identifier, run-history thread identifier (internal UUID), and the per-request cost in USD. This data is written to credit_deduction_logs (one row per LLM call) and is retained alongside other billing records. It is used to spot stolen sandbox credentials, replay attacks, and runaway agent loops, and to reconcile our spend against upstream provider invoices
Connected-database configuration — for enterprise organizations that connect their own database (Bring Your Own Data), CREAO stores the encrypted connection credentials and the database/schema names the workspace admin chose to expose. Credentials are encrypted under a dedicated key separate from the one used for user-uploaded secrets so the two rotation lifecycles stay independent. Connection records are hard-deleted immediately when an admin disconnects the source and cascade on organization deletion
Connected-cloud configuration — when you connect your own AWS account (Bring Your Own Cloud) so the agent can read observability data or provision infrastructure on your behalf, CREAO stores non-secret references to the connection: the cloud provider, a display name, the AWS account ID, the cross-account IAM role ARN you paste back after deploying our CloudFormation stack, the region the tools run against, and the grant tier (readonly for debugging or deploy for provisioning). The only secret in this record is a per-connection ExternalId, which CREAO generates and stores encrypted (AES-256-GCM, under a dedicated key separate from other secrets). No long-lived cloud credentials — no access keys, secrets, or static tokens — are ever stored. Access uses short-lived AWS STS credentials minted on demand via AssumeRole with the ExternalId; those credentials are held only in-process on the host that reads your account and never enter the agent sandbox
Account deletion requests — when you ask to delete your CREAO account, CREAO records the request and how it was handled: its status and timestamps, the IP address it was made from, an email and name snapshot captured at the time of the request, any reason code(s) you optionally select and free-text detail you optionally type when asked why you’re leaving, and any notes an administrator adds while actioning it. This record is stored separately from your account so it can serve as evidence that the request was received and carried out. See Data Retention for how long it is kept
Rate-limit abuse events — when a request is rejected for exceeding a rate limit (HTTP 429), CREAO records a sampled event used to detect scans and brute-force abuse: the time, the endpoint path and HTTP method, the source IP address, an allowlist of non-sensitive request headers (user agent, referer, origin, forwarded-for, accept-language), the limiter bucket, and a size-capped, secret-redacted excerpt of the request body. Body capture is skipped entirely for authentication, billing, credit, secret, token, payment, and login routes, and recording is sampled to at most one event per actor per endpoint per minute. This is written to rate_limit_violations. See Data Retention for how long it is kept
Job applications (CREAO Careers) — when you apply for a role on careers.creao.ai, CREAO collects what the application form asks for: your name, email address, any links you supply (portfolio, GitHub, LinkedIn), your answers to the role’s free-text questions, and — if you attach one — your CV/resume file. The file itself is stored in CREAO’s private S3 upload bucket under a careers/applications/ key derived from a random application identifier; CREAO also records its original filename, MIME type, size, and a content hash (used to recognise the same CV submitted to more than one role). If you were signed in to a CREAO account when you applied, the application is linked to that account ID so you can see your own submissions under My Applications; applying does not require an account. Applications are readable only by CREAO recruiting staff on an allowlisted internal admin surface, and CVs are never exposed on a public URL. Staff may also record an application’s hiring status and interview round, and may link two applications that share a candidate’s email addresses so duplicate submissions are recognised as one person
Job-alert subscriptions (CREAO Careers) — if you ask to be notified about new roles, CREAO stores the email address you give, the scope you chose (this role, this category, or all new roles), and the job or category the request came from, so it can email you when a matching role is published. This is a standalone subscription record — it does not require or create a CREAO account. Ask us at support@creao.ai to remove it
Paired devices (CREAO Connect) — when you pair your own computer or server with CREAO so the agent can invoke local capabilities on it, CREAO stores a device row: a user-chosen device name, platform, a hashed/preview form of the device’s access token, the merged list of capabilities (and MCP tool schemas) the device advertises, status (active/revoked), pause (“do not disturb”) state, and presence timestamps (last seen, last graceful disconnect). Each successful connect also records the source IP address and a derived geolocation string, used for new-location/takeover detection on the pairing UI. When a device capability result is too large to return inline, CREAO temporarily stores the result in an encrypted, per-device-scoped S3 object (device_attachments binding row) referenced only by a short-lived signed URL. Device rows and attachment bindings are deleted when your account is deleted, or immediately when you revoke the device

We do not sell your data to third parties.

CREAO is designed with GDPR principles in mind: - Lawful basis — we process data based on contractual necessity (to provide the service), legitimate interest (to improve the product and measure advertising performance where permitted), and consent where required for advertising cookies, Google Ads enhanced conversions, Meta Pixel / Conversions API, and similar marketing measurement - Data minimization — we collect only what is needed to deliver the service - Right to access — you can export your data at any time - Right to deletion — you can delete your account and all associated data; a limited audit record of the deletion request itself (request metadata, an email snapshot, and any administrator handling notes) may be retained where required for legal, compliance, and security purposes, as described in Data Retention - Right to portability — conversation and file data can be exported in standard formats

Data processing — see the Subprocessors section below for a list of third parties that process data on our behalf - International transfers — user data is stored in the United States. For EU users, data transfers are governed by Standard Contractual Clauses (SCCs) in accordance with GDPR Chapter V. Some AI providers process generation requests outside the US (for example, BytePlus seedance / seedream uses Singapore-region endpoints; Claude inference and Veo video generation via Google Vertex AI may be processed in any Google Cloud region worldwide when using Vertex’s global endpoint; and Fugu Ultra via Sakana AI may be processed by Sakana AI and the external LLM providers it orchestrates). Apple processes Sign in with Apple authentication on Apple’s own servers in the United States. Transfers to these processors are likewise governed by SCCs or equivalent transfer mechanisms where applicable. Apple publishes a Data Processing Addendum covering its developer APIs. Sakana’s public Fugu terms state that the service is provided outside the EEA, UK, and Switzerland, so EEA, UK, and Swiss use of Fugu Ultra requires confirmed DPA and transfer terms before the model is enabled for those regions - Data Processing Agreement — enterprise customers can request a DPA by contacting privacy@creao.ai

CCPA compliance

For California residents, CREAO provides: - Right to know — what personal information we collect and how it is used - Right to delete — request deletion of your personal information - Right to opt-out — we do not sell personal information, and you may opt out of sharing for cross-context behavioral advertising. CREAO honors browser Global Privacy Control signals by disabling Google advertising user-data and personalization consent and by not sending email match data for Google Ads enhanced conversions - Non- discrimination — exercising your rights does not affect pricing or service quality

CREAO uses cookies required for authentication, session management, security, and signup attribution. CREAO may set first-touch attribution cookies on .creao.ai containing encoded UTM/referrer information (for example, campaign parameters, click IDs including Impact’s IM_REF, referring site, and landing path) so the signup can be attributed after moving between CREAO subdomains. When Google Analytics or Google Ads conversion measurement is enabled, Google may set _ga and _ga_* cookies on CREAO domains to distinguish browsers and sessions for analytics and conversion measurement; CREAO reads the _ga client identifier and, on agent run requests where a live session is active, the _ga_<container> session identifier, to stitch server-side analytics events into the originating browser session so they inherit the real traffic source. When Meta Pixel measurement is enabled, Meta may set _fbp (browser identifier) and _fbc (click identifier) cookies on CREAO domains; CREAO reads these cookies and may forward them server-side to Meta’s Conversions API for attribution matching. If your browser sends Global Privacy Control, CREAO denies Google advertising user-data and personalization consent and does not send email match data for enhanced conversions. Public shared-thread and agent-install pages may also capture the page owner’s affiliate handle or referral code using first-party browser storage (creao_aff cookie for affiliate handles, localStorage for referral codes) so signup and install flows can credit the right creator; for Impact.com campaigns, this same first-party attribution path may retain the Impact click ID long enough to attribute sign-up and paid-conversion events. These owner-attribution entries are first-party, same-domain, attribution-only storage and are not cross-site tracking cookies. During OAuth sign-in, CREAO may also set a 5-minute creao_attribution cookie carrying the same type of information so attribution survives the redirect, and a 10-minute HttpOnly creao_visitor_id cookie carrying the per-device identifier used by our abuse-detection system; this identifier is already sent as a request header during non-OAuth sign-in, and the cookie exists solely to carry it across the OAuth provider redirect, where custom headers cannot be attached. We use Cloudflare Turnstile for bot protection, which is a privacy-preserving alternative to traditional CAPTCHAs and does not use tracking cookies.

AI & Model Usage

Most CREAO model-provider API paths do not use your data to train AI models. Conversations and files sent to Anthropic, OpenAI, Google, MiniMax, Z.AI, Moonshot AI, Thinking Machines, Fireworks AI, Meta, and BytePlus are processed under API agreements or provider API terms that prohibit use of your data for model training. MiniMax M3 conversation requests are served by Fireworks AI directly under CREAO’s own Fireworks account; Fireworks’ API terms prohibit use of your data for model training. If Fireworks returns a capacity error (a rate limit or transient server error), the request is automatically retried once via OpenRouter and served by DeepInfra, Novita, or Together AI — that fallback path is governed by CREAO’s API agreement with OpenRouter, whose API terms prohibit training use. MiniMax’s own API is used for CREAO’s internal response-quality evaluation under MiniMax’s API terms, which likewise prohibit use of your data for model training. Z.AI and Moonshot AI models are reached via OpenRouter — CREAO’s API agreement for these providers is with OpenRouter, whose API terms prohibit training use. Thinking Machines’ Inkling is likewise reached via OpenRouter, whose API terms prohibit training use. DeepSeek V4 Flash is an open-weights model that CREAO self-hosts: conversation requests are served by CREAO’s own inference servers (running on GPU infrastructure rented from Nebius), so conversation content for this model is processed on CREAO-managed systems and is not sent to DeepSeek or to any third-party model provider. No model training occurs on this path — CREAO does not train models on your data, and no external provider receives it. During maintenance or failover CREAO may temporarily route DeepSeek V4 Flash requests via OpenRouter (served by third-party inference hosts, preferring Fireworks AI under CREAO’s own Fireworks account; DeepSeek’s own API endpoint is excluded from that routing), under OpenRouter and Fireworks API terms that prohibit training use. This includes automatic per-request retries: if CREAO’s self-hosted servers return a capacity or availability error for an individual request (for example while the node restarts), that request is automatically retried on the same DeepSeek V4 Flash model via this OpenRouter path — up to two sequential attempts. The first retry prefers Fireworks AI; if that attempt itself hits a capacity error, one final retry may be served by any of the other OpenRouter inference hosts for this model (DeepSeek’s own API endpoint remains excluded), under the same OpenRouter no-training API terms. Separately from that failover path, if CREAO’s client detects that a self-hosted response stream was corrupted in transit (for example a malformed or dropped tool invocation in the model’s output), it may automatically regenerate that response on the same self-hosted model and CREAO-managed infrastructure — this quality retry involves no additional destination and no third party; the request is simply re-processed on the same path it was already on. DeepSeek itself never receives conversation content on any of these DeepSeek V4 Flash paths.DeepSeek V4 Pro is a different arrangement, and the difference matters. Unlike V4 Flash, CREAO does not self-host DeepSeek V4 Pro. Conversation requests for this model are relayed via OpenRouter and served either by DeepSeek’s own API (the preferred host) or, as a fallback, by GMICloud — so conversation content for DeepSeek V4 Pro is sent to DeepSeek, and may be sent to GMICloud. Both paths are governed by CREAO’s API agreement with OpenRouter together with the serving provider’s own API terms, which prohibit use of your data for model training. If you want a DeepSeek-family model whose conversation content stays on CREAO-managed systems, choose DeepSeek V4 Flash instead.Requests relayed through OpenRouter may also be served by Fireworks AI under CREAO’s own Fireworks account (currently GLM 5.2, and potentially other OpenRouter-routed open models such as Kimi K3); Fireworks’ API terms prohibit use of your data for model training, and Fireworks states it does not log or store prompt or generation data for open models by default.Muse Spark is reached directly via the Meta Model API under Meta’s developer API terms, which prohibit use of your content to train Meta’s models; Meta may use aggregated, anonymized service-usage data (not your content) to improve its services. This includes image inputs sent for generation tasks (for example, image-to-video with Veo). Providers may retain data briefly for abuse monitoring and safety as required by their terms, but not for training purposes on these paths.Fugu Ultra via Sakana AI is a qualified exception while governed by Sakana’s public Fugu terms. Those terms may allow submitted content to be used for Sakana training and improvement unless an opt-out or separate no-training/DPA arrangement is in place. Do not select Fugu Ultra for regulated, sensitive, confidential, or personal data unless your workspace has confirmed the required Sakana terms.

How is data sent to AI models?

When you chat with the super agent, your messages and relevant context (files, memory, Dream profile, skill instructions, and — for organizations that have connected their own database — the names of the connected databases and schemas, plus any standing instructions your organization configured for those databases) are sent to the selected LLM provider via their API. All API calls use encrypted connections. Responses are streamed back to your browser in real time.Scheduled agent runs use the model selected for that schedule and send the run’s prompt, inputs, and relevant agent context through the same provider channel and under the same provider terms, including the Fugu Ultra exception above.After an agent run completes, CREAO may send a size-bounded excerpt of the run’s request or output to a configured supported LLM to generate the title and summary shown on its run card. This metadata request uses the same encrypted provider channels and provider terms described above.When you approve a dynamic workflow, individual workflow task prompts and scoped task context may be sent to LLM providers as isolated worker or synthesis requests. CREAO stores task summaries and copies generated artifacts into the parent thread’s file store, but worker intermediate transcripts are not inserted back into the parent conversation context.When you use the Developer Platform to create or edit a personal agent from natural-language instructions, that free-text input is sent through the same agent/LLM workflow used by the main CREAO app so the agent definition can be designed and persisted. No additional AI provider or data category is introduced for this path.Connected-database metadata is limited to the source name, type, and the database/schema NAMES that the workspace owner chose to expose. Database row contents are not sent to the LLM unless the agent is explicitly asked to query the data; in that case, the query result rows flow through the same provider channel as the rest of your conversation.When a warehouse-backed answer is produced, CREAO also records a query receipt for that turn: the SQL text the agent ran (truncated), the data source it targeted, how long the query took, the row count, and — on failure — an error code. Receipts are shown to you alongside the answer so the SQL behind a number is inspectable. They are stored with the conversation and are NOT inserted into the model’s context, so they add no new data flow to any LLM provider. Note that the SQL text itself can embed values you asked the agent to filter on.Separately, CREAO staff can review agent-written SQL that FAILED, to find and fix cases where the agent writes queries a database rejects. An internal dashboard, restricted to administrators, shows a rolling window of recently failed statements (truncated to 600 characters) together with the database’s error message. This reads query history the data warehouse itself retains — typically about seven days — rather than a copy CREAO stores, and it covers only statements that errored: a query that ran successfully never appears there. As above, failing SQL can embed values you asked the agent to filter on. Today this surface covers CREAO’s own analytics warehouse; if it is extended to customer-connected databases, this notice will be updated first.When the agent uses a connector tool (X, Gmail, Slack, GitHub, custom MCP servers, etc.), the tool’s response flows into the agent’s context so it can act on the result — and this includes error responses, not just successful ones. If a connector call fails, the provider’s error message (for example, “this action requires a higher access tier” or “missing required field”) is forwarded to your selected LLM provider so the agent can explain the failure or correct and retry. CREAO applies a best-effort pass to strip credential-shaped tokens from these error messages before they enter the context.When the agent invokes a capability on your paired CREAO Connect device (including a custom MCP server you configured on that device), the result the device returns — arbitrary local output such as command output, file contents, or an MCP tool’s response — is inserted into the agent’s context and forwarded to your selected LLM provider, the same way other tool results are. This output is explicitly framed to the model as untrusted, since it originates from code CREAO does not control running on your own machine.For a connected AWS account (Bring Your Own Cloud), the results the agent reads from your account — CloudWatch log events, metric data points, and alarm states — flow into the agent’s context to answer your request. Like other connector data, that means these tool results are sent to your selected LLM provider as part of the conversation context. The agent reads only what the tool you triggered returns; CREAO does not bulk-export or continuously ingest your cloud account.If you install the CREAO Slack Agent App in a Slack workspace, messages that @mention the bot or are sent to it directly are sent to your selected LLM provider as part of the agent’s context, and the agent’s reply is posted back into that Slack thread or DM. See Connector Data Access below for what’s collected, from whom, and how consent works for this feature.Organizations can also configure standing instructions for a connected database — free text (up to 20,000 characters per data source) authored by your own organization’s members, not by CREAO. When that data source is connected to a chat, these instructions are injected verbatim into the agent’s system prompt for every conversation in the organization, so they are forwarded to your selected LLM provider as part of the context window. Organizations can likewise save reusable prompt templates (a name plus a prompt body); a template’s prompt body is only sent to the provider if a member actually inserts it into a message. Both surfaces are editable by any member of the organization.When reflection retrieval is enabled for your request, CREAO may use your current prompt/query text with CREAO’s reflection search and inject reflection profiles/playbooks as summarized excerpts into the model context. This means reflection-derived summaries can be forwarded to your selected LLM provider as part of the context window. The reflection capability runs in CREAO-controlled infrastructure; no additional subprocessor is used for this reflection step.Dream profiles are generated using Claude Haiku and may be included in agent context alongside your selected LLM provider. This means profile summaries generated by one provider may be forwarded to another as part of the agent’s context window.Follow-up suggestion chips shown under an answer are generated by the same LLM provider you selected for the conversation, as part of the agent’s own turn: the agent records the suggestions through an internal tool call at the end of its answer, drawing on the conversation context it already has plus the names of your saved agents and available integrations. No additional provider or separate platform model is involved, and no extra copy of your conversation is sent anywhere — the suggestion step is simply part of the same model call flow (and, like the rest of the turn, part of its normal usage-based billing).In organization context, memories and Dream profiles contributed by any member of your organization may be included in the agent context for other members’ sessions in that organization. For a shared team agent, reflection-derived agent playbooks work the same way: playbooks learned from any member’s conversations with that agent may be included in the agent context when other members run it, once approved for shared use. The agent’s creator can view, approve, reject, or delete these playbooks from the agent’s Playbooks tab; other org members can view but not change them.

Which AI providers does CREAO use?

CREAO supports multiple LLM providers:

Anthropic (Claude Fable, Opus, Sonnet, Haiku)
OpenAI (GPT-5.5, GPT-5.6)
Google (Gemini Pro, Gemini Flash, Veo for video generation)
MiniMax (MiniMax M3 — internal response-quality evaluation via the MiniMax API; for conversations flagged as possibly integration-related, this evaluation may also include the list of service names you have connected (for example “gmail, slack” — names only, never tokens, credentials, or account contents) so quality problems can be attributed to missing or misused integrations; conversation requests are served by Fireworks AI)
Z.AI (GLM 5.2)
Moonshot AI (Kimi K3, via OpenRouter)
Thinking Machines (Inkling via OpenRouter)
DeepSeek (model publisher, and — for DeepSeek V4 Pro only — an inference provider. DeepSeek V4 Flash is open-weights and CREAO self-hosts it: conversation content is not sent to DeepSeek; during maintenance or failover, requests may be temporarily routed via OpenRouter to third-party inference hosts, with DeepSeek’s own API endpoint excluded — this includes up to two sequential automatic retries of any individual request that hits a self-hosted capacity error, on the same model; independently, a response whose stream is detected as corrupted may be automatically regenerated once on the same self-hosted infrastructure, involving no third party. DeepSeek V4 Pro is not self-hosted: it is relayed via OpenRouter and served by DeepSeek’s own API by preference, so conversation content for that model is sent to DeepSeek, under DeepSeek’s API terms, which prohibit training use)
Fireworks AI (direct inference for MiniMax M3 conversation requests, and inference for GLM 5.2 requests relayed via OpenRouter, both under CREAO’s Fireworks account; may also serve other OpenRouter-routed open models, and is the preferred host for the automatic same-model OpenRouter retry of self-hosted DeepSeek V4 Flash requests that hit a capacity error)
DeepInfra / Novita / Together AI (MiniMax M3 conversation requests relayed via OpenRouter, only as an automatic fallback when Fireworks returns a capacity error)
GMICloud (DeepSeek V4 Pro conversation requests relayed via OpenRouter, only as a fallback when DeepSeek’s own API is unavailable)
Meta (Muse Spark 1.1 via the Meta Model API)
BytePlus (Seedance video generation, Seedream image generation)
Sakana AI (Fugu Ultra model orchestration)

Anthropic, OpenAI, Google, MiniMax, OpenRouter-served Z.AI, Moonshot AI, and Thinking Machines Inkling, Fireworks AI, OpenRouter-served DeepInfra, Novita, and Together AI (the MiniMax M3 fallback path), OpenRouter-served DeepSeek and GMICloud (the DeepSeek V4 Pro path), Meta, and BytePlus are accessed via API paths with no-training commitments. DeepSeek V4 Flash is self-hosted on CREAO-managed infrastructure (GPU hosting: Nebius) — its conversation content is not sent to any model provider; its maintenance/failover fallback rides the OpenRouter path above, including up to two sequential automatic retries (same model — first preferring Fireworks AI, then any other OpenRouter host for the model; DeepSeek’s own endpoint excluded throughout) for any individual request that hits a self-hosted capacity or availability error, under the same no-training API terms. DeepSeek V4 Pro is NOT self-hosted, and is the one path on which DeepSeek itself receives conversation content: it is relayed via OpenRouter and served by DeepSeek’s own API by preference, or by GMICloud as a fallback, under those providers’ API terms, which prohibit training use. Providers may retain data briefly for abuse monitoring and safety per their terms, but not for model training on those paths. Fugu Ultra is accessed through Sakana AI’s orchestration API, whose public Fugu terms may allow content to be used for Sakana training and improvement unless an opt-out or separate no-training/DPA arrangement is in place; the service may also route content to external LLM providers. Do not use Fugu Ultra for regulated, sensitive, confidential, or personal data unless your workspace has confirmed the required Sakana terms. CREAO may also send a sampled subset of completed conversations and assistant responses to MiniMax M3 for internal response-quality evaluation, independent of the model selected for the original conversation.For eligible users, some Claude requests may be served through Google Vertex AI or Amazon Bedrock (AWS) rather than Anthropic’s first-party API; in the Amazon Bedrock case, AWS’s Bedrock enterprise terms govern processing and your data is not used for model training. Similarly, eligible users’ Veo video generation jobs may be served through Vertex AI rather than the Gemini API. If a Veo video generation job encounters a transient provider error during processing, CREAO may automatically retry the job through an alternative provider, such as BytePlus Seedance, to complete your request. In all Google Vertex AI cases, Google’s Vertex AI enterprise terms govern processing, and your data is not used for model training.

What about code execution?

Code generated by the AI runs in an isolated sandbox. The sandbox has no access to other users’ data, no persistent network access to internal systems, and is destroyed after the session ends. Generated files are stored encrypted and associated only with your account. If you share a thread via the Share feature, files and artifacts within that thread become accessible to anyone with the share link.

Connector Data Access

Connectors provide scoped access to third-party systems (OAuth/API-key based). See Skills and Connectors for the full feature overview and Security for auth model and security controls.

Connector group	Auth mode	Typical data categories	Revocation
Google Workspace (Gmail, Calendar, Docs, Sheets, Drive, Tasks)	OAuth	Mail, calendar events, docs, spreadsheets, files, tasks	Disconnect in CREAO + revoke in Google account if needed
Google Marketing (Ads, Analytics, Search Console)	OAuth	Campaign/reporting and web analytics data	Disconnect in CREAO + revoke in Google account if needed
Meta Ads (Meta Marketing API)	OAuth	Advertising objects in the Meta ad accounts you grant access to: campaigns, ad sets, ad creatives and ads, their budgets, bid strategies, targeting and schedules, plus delivery/performance insights. The scopes CREAO requests (`ads_management`, `ads_read`) permit writes — creating and updating campaigns, ad sets and ads, including budget and status changes that can cause ad spend on your account. CREAO also stores your Meta user ID and name for connection display	Disconnect in CREAO (deletes the stored token) + remove CREAO under Meta Settings → Business integrations
Microsoft (Outlook, Outlook Calendar, Teams, OneDrive, Word, Excel)	OAuth	Mail, calendar events, collaboration messages, files, documents, workbook data. Outlook tools can also read folder metadata (folder names, item/unread counts) from a shared or delegated mailbox your account has been granted access to — which may belong to another person — subject to the access Microsoft’s OAuth consent grants CREAO. Outlook Calendar is a separate connector from Outlook mail (connecting one does not connect the other) and covers calendar events including subject, location, attendee email addresses and online-meeting join details; free/busy availability for mailboxes you query, which may belong to other people, subject to the access Microsoft’s OAuth consent grants CREAO; and contact/directory lookups for scheduling.	Disconnect in CREAO + revoke in Microsoft account if needed
Collaboration (Slack, Discord, Notion, Asana, Linear)	OAuth or API key	Messages, channels/pages, tasks/issues/project data	Disconnect in CREAO + revoke in provider account
Developer (GitHub, Webflow)	OAuth	Repository metadata/content, issue/workflow data; CMS collections, site content, and publishing metadata	Disconnect in CREAO + revoke in provider account
Social/commerce (X, YouTube, Reddit, Shopify, eBay, Telegram)	OAuth or token	Social content, publishing metadata, user-uploaded and agent-generated media files (images/video) forwarded from CREAO storage to X when you post, storefront/listing data, bot messaging data	Disconnect in CREAO + revoke in provider account. For a store connected through the CREAO Shopify app, uninstalling the app in the Shopify admin also revokes CREAO’s stored token
Logistics (Hapag-Lloyd, CMA CGM)	User-supplied API credentials	Ocean freight rate offers (Quick Quotes / Spot for Hapag-Lloyd; SpotOn instant quotes and contract quote lines for CMA CGM), routing and price data; the Hapag-Lloyd Online Business email you provide at connect time	Disconnect in CREAO (deletes stored credentials, cached tokens, and email) + rotate or delete the application on the carrier’s API portal
Logistics (MSC)	User-supplied API credentials	Ocean freight contract-rate data (service-contract references, ports, container specifications, freight and surcharge amounts, validity windows) fetched from your own MSC account	Disconnect in CREAO (deletes the stored subscription key) + regenerate or revoke the key on the MSC Developer Portal
Custom MCP servers	API key, bearer token, or none	Tool schemas fetched from user-specified HTTPS endpoints during setup or refresh; no user message content is sent during schema discovery	Disconnect in CREAO + revoke or rotate credentials at the server

Some connectors run through direct provider API integrations; others may run through integration relay infrastructure. In all cases, access is bound to your authenticated connector account and approved permissions. Slack app (bot install) is a different model from the “Collaboration” row above. A single workspace member (“the installer”) installs the CREAO Slack app and grants it standing, workspace-wide read access — channel, group, and DM message history and files, not just the installer’s own OAuth-scoped data — for every channel the bot is subsequently added to. The installer explicitly acknowledges a consent notice before the integration activates, but other members of the workspace whose messages become readable once the bot joins their channel have not individually authorized anything themselves; their consent is provided at the workspace level, through whoever installs the app. Every agent run triggered from Slack executes as the installer’s CREAO account (their agent, credits, and connected tools), regardless of which workspace member sent the triggering message. The installer can revoke access at any time by uninstalling the app from Slack or CREAO’s integration settings, which best-effort revokes the bot token. Posting media to X (attaching user-uploaded or agent-generated images and video to a tweet) requires the media.write OAuth scope. When you post, CREAO fetches the media bytes from your CREAO storage and uploads them to X’s API; each posting action still requires your explicit approval. If you connected X before this scope was introduced, you may need to reconnect X to grant media.write before media attachments will work.

Slack Agent App (Inbound)

This is a separate feature from the “Collaboration” Slack connector above, which lets your agent send messages out to Slack. The Slack Agent App instead lets people bring a CREAO agent into a Slack workspace by @mentioning it or messaging it directly — and it involves a different set of data subjects, so it’s documented on its own.

Who installs it and who’s bound to it: A CREAO account holder (“the installer”) authorizes the app into a Slack workspace via Slack OAuth. Every @mention or direct message to the bot in that workspace — from any member, whether or not they have a CREAO account — runs as the installer’s own agent, on the installer’s credits, using the installer’s connected integrations. The installer must explicitly acknowledge this before the integration activates: anyone with access to a channel the bot is in, or who can message it directly, can trigger a run on the installer’s behalf.
What’s collected from a triggering message: the Slack workspace/channel/thread identifiers, the triggering member’s Slack user ID, and the text of the message or mention (plus references to any attached files) needed to generate the agent’s response. This is retained only long enough to process the request and support troubleshooting — see Data Retention below — and is not linked to a CREAO account unless the triggering member happens to also be the installer.
Where it goes: the message text is sent to the installer’s selected LLM provider as agent context (see AI & Model Usage above) and the agent’s reply is posted back into the originating Slack thread or DM, visible to that thread’s Slack participants. If the installer’s selected agent is a routing agent (CREAO auto-provisions a default “Team Request Router” the first time the app is installed), it may forward the message on to a second, more specific agent it selects — still executing as the installer’s account, on the installer’s credits, so the same data-flow guarantees above apply to that second agent’s LLM provider and connected tools as well.
Removing it: the installer can disconnect the app from CREAO settings at any time, which revokes CREAO’s Slack access token; removing the app from the Slack workspace has the same effect. A workspace member whose message was processed and who is not the installer can request deletion of their retained data via privacy@creao.ai.

Skill Data Handling

Built-in skills are instruction packages — they do not create new third-party data sharing paths by themselves. See Skills and Connectors for the full feature overview and Security for safety boundaries. Built-in skills may operate on:

User prompts and conversation context
User-provided files and generated artifacts
Connected-service data when relevant connectors are authorized

Data leaves CREAO only when required by tools/providers used during execution.

Subprocessors

The following third-party services process data on behalf of CREAO:

Subprocessor	Purpose	Data Processed
Google Workspace (Google LLC)	Event registration collection and organizer reporting through Apps Script and Google Sheets	Event registrant name, professional role, practice area, experience range, optional question, referral source tag, and submission timestamp
AWS (Amazon Web Services)	Cloud infrastructure, data storage, compute; Claude model inference via Amazon Bedrock for eligible users; AWS IoT Core for CREAO Connect device transport (paired-device invoke/result messaging)	All service data
Anthropic	LLM provider (Claude models)	Conversation messages, context
OpenAI	LLM provider (GPT models); image generation and editing (GPT Image)	Conversation messages, context; image-generation prompts and user-provided reference images for image generation/editing tasks
Google Cloud	AI provider (Gemini models; Veo video generation via the Gemini API, or via Vertex AI for eligible users; Gemini image generation; Claude model inference via Vertex AI for eligible users)	Conversation messages, context, user prompts, image/video/audio inputs for video generation tasks (Veo); image-generation prompts and user-provided reference images for image generation tasks (Gemini)
MiniMax	Internal response-quality evaluation (MiniMax M3 via the MiniMax API). MiniMax M3 conversation requests are served by Fireworks AI, with an automatic OpenRouter fallback — see the Fireworks AI and OpenRouter rows	Sampled completed conversations and assistant responses used for quality evaluation; for conversations flagged as possibly integration-related, the names of services the user has connected (names only — never tokens, credentials, or account contents)
Z.AI	LLM provider (GLM models)	Conversation messages, context
Moonshot AI	LLM provider (Kimi models)	Conversation messages, context
Meta Platforms (Meta Model API)	LLM provider (Muse Spark models) — distinct from the Meta Pixel advertising row below and from the Meta Ads connector (see Connector Data Access: a user-authorized flow to your own ad account, not a CREAO subprocessing relationship); this is a conversation-content data flow	Conversation messages, context, and user-provided image inputs for Muse Spark requests
Thinking Machines	LLM provider (Inkling model), reached via OpenRouter	Conversation messages, context
OpenRouter	LLM API gateway — relays requests to Z.AI, Moonshot AI, Thinking Machines, and DeepSeek models (GLM 5.2 requests are served by Fireworks AI under CREAO’s Fireworks account; DeepSeek V4 Pro rides this path for ALL of its conversation requests — served by DeepSeek’s own API by preference, or GMICloud as a fallback (see those rows) — while DeepSeek V4 Flash rides it only during maintenance/failover — served by third-party inference hosts, the first attempt preferring Fireworks AI and any second capacity-error retry unpinned within the pool, with DeepSeek’s own endpoint excluded from CREAO’s routing throughout; see the Fireworks AI and Nebius rows). Also carries MiniMax M3 conversation requests as an automatic fallback when Fireworks returns a capacity error — served by DeepInfra, Novita, or Together AI (see those rows)	Conversation messages, context (relayed to the serving model provider)
Fireworks AI	LLM inference provider — serves MiniMax M3 conversation requests directly under CREAO’s Fireworks account (with an automatic OpenRouter fallback to DeepInfra, Novita, or Together AI when Fireworks returns a capacity error — see those rows) and GLM 5.2 requests relayed via OpenRouter, also under CREAO’s Fireworks account; may also serve other OpenRouter-routed open models (e.g. Kimi K3, and DeepSeek V4 Flash during maintenance/failover — including the automatic OpenRouter retries, same model, of any self-hosted request that hits a capacity or availability error: up to two sequential attempts, for the first of which Fireworks is the preferred host, while a second is unpinned within the OpenRouter pool)	Conversation messages and context for requests served by Fireworks. Per Fireworks’ API terms, not used for model training; Fireworks states prompt and generation data for open models is not logged or stored by default
Nebius	GPU infrastructure provider — hosts CREAO’s own self-hosted inference servers (currently serving DeepSeek V4 Flash conversation requests). Inference runs on CREAO-managed servers; Nebius provides the underlying hardware and network and has no application-level access to request content	Conversation messages and context for self-hosted model requests are processed transiently in memory on CREAO-managed servers hosted at Nebius; not used for training by anyone
DeepSeek	LLM provider and model publisher — serves DeepSeek V4 Pro conversation requests via its own API, relayed through OpenRouter (the preferred host for that model; GMICloud is the fallback). Does NOT receive DeepSeek V4 Flash conversation content, which CREAO self-hosts — see the Nebius row	Conversation messages and context for DeepSeek V4 Pro requests, relayed via OpenRouter under DeepSeek’s API terms, which prohibit use of your data for model training
GMICloud	LLM inference provider — serves DeepSeek V4 Pro conversation requests relayed via OpenRouter, only as a fallback when DeepSeek’s own API is unavailable	Conversation messages and context for fallback-served DeepSeek V4 Pro requests, relayed via OpenRouter under OpenRouter’s no-training API terms
DeepInfra	LLM inference provider — serves MiniMax M3 conversation requests relayed via OpenRouter, only as an automatic fallback when Fireworks returns a capacity error	Conversation messages and context for fallback-served MiniMax M3 requests, relayed via OpenRouter under OpenRouter’s no-training API terms
Novita	LLM inference provider — serves MiniMax M3 conversation requests relayed via OpenRouter, only as an automatic fallback when Fireworks returns a capacity error	Conversation messages and context for fallback-served MiniMax M3 requests, relayed via OpenRouter under OpenRouter’s no-training API terms
Together AI	LLM inference provider — serves MiniMax M3 conversation requests relayed via OpenRouter, only as an automatic fallback when Fireworks returns a capacity error	Conversation messages and context for fallback-served MiniMax M3 requests, relayed via OpenRouter under OpenRouter’s no-training API terms
Sakana AI	LLM orchestration provider (Fugu Ultra)	Conversation messages and context for Fugu Ultra requests. Under Sakana’s public Fugu terms, content may be routed to external LLM providers and may be used for Sakana training or improvement unless an opt-out or separate no-training/DPA arrangement is in place
BytePlus (a ByteDance group company)	AI provider (Seedance video generation, Seedream image generation)	User prompts, generation parameters, user-provided image inputs (for image-to-video generation), and user-provided video and audio inputs (for video editing and motion/style/audio reference) for video / image generation tasks. Generated media is also delivered directly from BytePlus CDN infrastructure (short-lived signed URLs), through which BytePlus receives the user’s request metadata (IP, browser) at delivery time
E2B	Sandbox execution	Code, files during execution
Stripe	Payment processing	Billing and payment data. Payments are routed to a regional Stripe account based on your country (see Billing Routing below)
Cloudflare	CDN, DDoS protection, bot detection	Request metadata, and country plus a coarse city/region estimate derived from IP address (used for billing routing, login geolocation analytics, abuse detection, and internal regional analytics)
Better Auth Cloud	Email validation during signup (disposable, invalid-MX, reserved-TLD detection); supplementary abuse signals (IP reputation, bot / impossible-travel detection); auth event telemetry across all auth operations (signup, signin, password-reset, session-refresh, OAuth callbacks) for the Sentinel security dashboard	Email address; IP address; auth event metadata (event type, timestamp, user ID, user email, user display name, IP address, derived city / country / country code)
Sentry	Error monitoring	Error diagnostics (no conversation content)
incident.io	Incident management and on-call alerting	Operational alert metadata only — CloudWatch alarm names and service status (no conversation content, no user PII)
Amplitude	Product analytics and event data export	Usage events and session metadata (no conversation content)
Google Analytics / Google Ads (Google LLC)	Web analytics, advertising attribution, and conversion measurement on CREAO marketing and product domains	Browser GA4 client identifier (`_ga` cookie), session identifier (`_ga_<container>` cookie) sent via Measurement Protocol for live-session stitching on run-scoped events, CREAO user identifier after sign-in, first-touch UTM/referrer parameters, Google click ID (`gclid`), conversion events such as sign-up, login, purchase, and subscription cancellation, and hashed email match data for sign-up and purchase enhanced conversions (no conversation content)
Meta / Facebook (Meta Platforms, Inc.)	Advertising attribution and conversion measurement through Meta Pixel and server-side Conversions API on CREAO marketing and product domains — CREAO advertising its own product, not the Meta Ads connector, which acts on your ad account only when you connect it	Hashed email for advanced matching, hashed CREAO user identifier, IP address, user agent, Meta browser/click identifiers (`_fbp`, `_fbc`), Meta click ID (`fbclid`), and conversion events such as sign-up and purchase (no conversation content)
Reddit (Reddit, Inc.)	Advertising attribution and conversion measurement through the Reddit Pixel on CREAO product domains	Reddit browser identifier (`_rdt_uuid`), Reddit click ID (`rdt_cid`), page and pricing views, sign-up and purchase conversion identifiers, normalized email submitted to the Pixel for client-side hashing, and a namespaced SHA-256 hash of the CREAO user identifier (no conversation content)
Impact.com	Affiliate partner attribution and paid-conversion reconciliation for Impact.com campaigns	SHA1-hashed email, CREAO user identifier, Impact click ID (`IM_REF`), order ID, conversion timestamp, event type, subscription or credit-purchase amount, and promo code for eligible sign-up and paid-conversion events (no conversation content)
Statsig	Feature flag management and A/B experimentation	User identifier, email address, and feature-targeting custom attributes (e.g. trial eligibility status)
Pipedream	Connector OAuth and integration relay (user-triggered, when you authorize a connector). CREAO also periodically calls Pipedream’s tool schema API for operational reliability monitoring; these automated calls send only internal app identifiers and receive only tool metadata — no user data is involved	OAuth tokens for connected services; connector tool inputs and file content when the agent executes integration actions on your behalf (e.g. email attachments relayed via time-limited URLs)
People Data Labs	Company data enrichment (premium data tool, when you request company intelligence)	User-provided company identifiers such as website, name, ticker, LinkedIn URL, and location hints
TinyFish	Research search (scholarly-paper and news search agent tools) and web page reading (`web_fetch` agent tool), when the corresponding feature is enabled for your account and the agent runs a search or reads a page on your behalf	Search: search query text and optional search-intent text composed by the agent (both may derive from your prompt), plus corpus type and recency parameters. Web page reading: the page URL(s) the agent supplies — which may come from a link in your prompt or from a search result — optional intent text describing what is needed from the page, and the rendered page content returned to the agent. When the agent additionally requests page metadata, the page’s own descriptive tags are returned as well — canonical URL, site name, Open Graph type and preview image, last-modified time, favicon, and any robots directive — all of it published by the page itself, with no additional data sent about you. Do not paste links containing private access tokens (e.g. password-reset or magic-login URLs) if you do not want the agent to send them. In both cases requests are made server-side with CREAO’s API key — no user identifiers, account data, or conversation history are sent
Google PageSpeed Insights (Google LLC)	Web page speed and Core Web Vitals audits (`pagespeed_audit` agent tool, when enabled for your account and the agent audits a page on your behalf)	The page URL(s) the agent supplies — which may come from your prompt, a search result, or a site’s own sitemap, and may reference your site or a third party’s (e.g. a competitor you name) — plus the device strategy (mobile/desktop) and which audit categories to run. Requests are made server-side with CREAO’s API key — no user identifiers, account data, or conversation history are sent. Only send URLs for pages you are comfortable disclosing to Google, and do not audit URLs containing private access tokens; Google returns aggregate real-user performance data it already publishes for the site, and may retain the request per its own terms
LlamaIndex (LlamaCloud / LlamaParse)	Full-content PDF extraction (`read_pdf` agent tool, when enabled for your account and the agent reads a PDF on your behalf)	The PDF document fetched from the public URL the agent supplies (a scholarly paper, report, filing, or any public PDF link from your prompt) and the extracted document text returned. Requests are made server-side with CREAO’s API key — no user identifiers, account data, or conversation history are sent. CREAO caches the extracted text keyed by the source URL and may serve a cached copy across accounts to avoid re-parsing the same public document
Discord	Rewards verification (platform-level — checks Discord account link and CREAO server membership for the Rewards hub)	OAuth access token, Discord user id, username, avatar, server membership status
X (Twitter)	Rewards account linking (platform-level — confirms ownership of an X account when you connect it from the Rewards hub); agent connector (when you authorize the X connector, the agent posts on your behalf with your approval — e.g. `x_create_tweet`)	OAuth access token (held to bind the identity), X user id, username, display name, avatar. When you post through the X connector, CREAO also transmits the tweet content and any attached user-uploaded or agent-generated media files (images and video) — fetched from CREAO storage and uploaded to X’s API — subject to your approval. The `media.write` scope is required for media attachments
Apple (Apple Inc.)	Identity provider for Sign in with Apple (authentication flow)	Apple user identifier, verified email address (or Apple-relay email address), display name, and authorization code/tokens exchanged during the OAuth flow. Apple processes these on their servers to authenticate the user and return an ID token to CREAO
WEEX	Demo trading challenge account access and performance tracking (when you join a WEEX-backed campaign and configure WEEX API credentials)	WEEX UID/email, signed account-balance requests, demo-account equity, PnL, available balance, unrealized PnL, and trade count/performance metadata
debot	Robinhood Chain on-chain trading challenge monitor callbacks, wallet execution, and performance tracking when you join a debot-backed campaign	Submitted debot email, submitted Robinhood Chain wallet address, Debot monitor callbacks posted to CREAO’s community Agent webhook wrapper (then forwarded to your Platform Agent app), signed on-chain action requests, wallet equity/PnL/trade-count metadata, and debot trade-history metadata used for campaign ranking and audit
Kite / GoKite (`agentpassport.ai`, `cli.gokite.ai`, `gokite-ai`)	Optional Season 2 Kite Agentic Wallet side event: Passport skill install from the public `gokite-ai/passport-skills` GitHub repository, pinned `kpass` CLI download from `cli.gokite.ai`, and participant interaction with Kite Passport (`agentpassport.ai`) through the cloned CREAO agent	Skill/repository paths installed onto your CREAO account; CREAO server-side download of the pinned `kpass` binary (not user PII); wallet registration and on-chain actions you initiate with the Kite agent may be processed by Kite Passport services under Kite’s terms. CREAO does not send your CREAO password or debot credentials to Kite
Base (public Base-chain RPC, default `mainnet.base.org`, or a CREAO-configured `S2_BASE_RPC_URL`)	On-chain verification for the Season 2 Kite Agentic Wallet side event when you submit a Base wallet or transaction hash	Confirmed Base wallet address and submitted transaction hash queried by CREAO servers for ERC-20 `balanceOf` via `eth_call` (Circle native USDC on Base) and receipt checks; the RPC operator sees those identifiers and CREAO’s server request metadata (not your CREAO account password or private keys)
Apple (Apple Inc.)	iOS push notification delivery via the Apple Push Notification service (APNs), when you enable push notifications on the CREAO mobile app	Your device push token (an opaque per-device delivery credential issued by Apple) and the notification payload metadata sent at delivery time — the notification title and body (localized) plus identifiers such as the notification id and related thread id. By default, no conversation content, message text, or generated output is sent to Apple. If you opt into the Account Settings “Show names in notifications” toggle, the related chat thread’s title (which for an ordinary chat thread defaults to the start of your first message, truncated to 100 characters), agent app name, and/or organization name are rendered into the push body and sent to Apple as part of that opt-in
customer.io	Marketing automation and lifecycle messaging (email / in-app campaigns)	Read directly from the data warehouse by customer.io’s Reverse ETL over an SSL connection restricted by IP allowlist, and limited to a curated, read-only set of fields: email, name, account status, subscription plan/status and history (including Stripe subscription/customer identifiers), recorded spend and credit purchases, credit-usage logs, reward claims, first-touch acquisition attribution, connector lifecycle metadata (name, provider, auth mode, status, and timestamps), agent / thread / session / schedule lifecycle metadata, and a coarse city/region/country location estimate derived from IP for regional campaign segmentation. customer.io does NOT receive credentials (passwords, secrets, API keys, tokens), connector URLs or tool schemas, scheduled-run inputs or error details, conversation/message content, or forensic IP / user-agent logs (only the derived city/region/country estimate crosses, never the raw IP)

Billing Routing

CREAO uses Stripe Connect to route payments through regional Stripe accounts so that charges are processed by a merchant entity closer to the cardholder, reducing payment declines. The country associated with your IP address (provided by Cloudflare via the cf-ipcountry header) determines which Stripe account processes your payment:

United States and Canada — payments are processed by New Boundary, Inc. (US Stripe account) as a connected account on the CREAO platform
All other regions — payments are processed directly by the CREAO platform Stripe account (Hong Kong)

No new personal data is collected for this routing — only the country code already present in the request metadata is used. Your billing region is stored alongside your subscription record so that subsequent charges, portal sessions, and webhook processing use the same account. This value is cleared if your subscription is reset.

Data Retention

Data Type	Retention Period	Notes
Event registration submissions	Event date + 30 days	Name, professional role, practice area, experience range, optional question, referral source tag, and submission timestamp stored in the event organizer’s access-restricted Google Workspace Sheet for attendance planning and session preparation; the supplied event script stops accepting submissions and clears response rows after the retention deadline
Conversations & messages	Until deleted by user	Users can delete individual threads or all data
Harness cycle feedback	Until workspace or cycle deleted	Optional free-text input on the Self-Improve hero between cycles (e.g. “focus more on the conversion funnel”). The current-cycle draft lives on `harness_processes.loop_state.nextCycleFeedback` and is cleared once the next audit dispatches; the value that informed each completed cycle is snapshotted onto `harness_sessions.summary.userFeedback` so the cycle history can show “your focus for this cycle”. Deleted via the workspace cascade when the workspace is removed
API keys	Until revoked by user, or automatically when the associated agent app is deleted	HMAC hash stored; raw key shown once at creation and never stored. Account-wide keys remain until the user revokes them; agent-scoped keys are also soft-revoked automatically when their target agent app is deleted so orphaned credentials stop counting toward the per-user active-key limit
API run data (inputs, outputs)	Until deleted by user	Prompts and results from API-triggered agent runs; same retention as conversations
Developer API request logs (`developer_api_http_requests`)	Until account deletion	One row per authenticated Account API key `/v1/*` Developer API request that passes authentication and account rate-limit checks. Stores account/API-key identifiers, method, route/path, handler, status/error code, run/agent/conversation links, timing, byte counts, and credited usage for run-producing calls. No request payloads, response payloads, headers, raw API keys, or tokens are stored. Rows are hard-deleted on account deletion; raw path is excluded from the Redshift ODS warehouse view
Workflow definitions	Until account deletion	Saved workflow templates from approved dynamic-workflow proposals (staged via the `/workflow` command or proposed by the agent in ordinary chat), including name, description, and JSON task spec. Deleted during account deletion
Workflow runs, tasks, and events	Until the parent thread is deleted	Approved workflow execution records, including run/task status, task prompts, summaries, parent-thread artifact copies, progress events, and cost metadata. Deleted when the associated thread is deleted or when the account is deleted. Internal ODS warehouse views mirror these records for analytics under the same deletion controls
Generated files	Until deleted by user (cloud copy); device copies persist locally	Stored encrypted in cloud storage. On the iOS/Android app you may additionally save a generated file to your device: images and videos to your Photos library, and other files to the app’s on-device Files area. Once written to your device these copies leave CREAO’s control — the cloud retention and deletion controls above do not reach them, and you remove them through your device (Photos, Files app, or by uninstalling the app)
Org shared files	Until deleted by the file owner or when the account/organization is deleted	Files a team member shares into their organization’s shared space, the per-member read/write grants on them, and an append-only sharing audit log (who shared, granted, revoked, or deleted, and when). Only the member who shared a file can delete it or manage its grants. All of a member’s shared files and the grants made to them are removed when their account is deleted; the audit log is retained with the departed member’s identifiers scrubbed. Everything is removed when the organization is deleted. Non-secret columns are mirrored to the internal Redshift ODS warehouse for analytics under the same deletion controls
Sandbox environments	Session duration + 30 min idle	Destroyed after inactivity timeout
Memory entries	Until deleted by user (personal) or org member (team)	Personal memories are viewable and deletable from the Memory page. Team memories are shared across organization members and deleted when any organization member clears team memory, or cascade-deleted when the organization is deleted. Associated embedding vectors share the same retention and are removed when the memory entry is permanently purged.
Dream profiles	Active + last 10 versions (personal); org-scoped until org deleted	Personal profiles are deleted on account deletion (FK cascade). Org-scoped profiles cascade-delete when the organization is deleted. Viewable from Memory → Dream tab
Audit logs	90 days	Immutable, used for security monitoring
Team activity logs	Until app deletion	One row per tracked action on a shared agent (member added/removed, share toggled, schedule created/updated/deleted, etc.). Cascades when the agent app is deleted. The acting user’s id is replaced with a deleted-account placeholder when that user closes their account, so the action history remains coherent for surviving collaborators without exposing data tied to a deleted user
Live views (`live_views`)	Artifacts: until unpinned. Dashboards: until the owning agent is deleted	User-promoted bindings between an agent and one of its recurring outputs: the user-chosen view name, the bound artifact file name (or dashboard block id), the view kind, grid-layout position, and owner/organization identifiers. No output content is stored — artifact views resolve to existing generated files, and dashboard views to the latest run’s `app_sessions.dashboards` spec, both at read time. Unpinning an artifact view deletes it immediately; unpinning a dashboard view instead marks it dismissed (hidden from the Views board and never re-pinned) while retaining the binding row until the owning agent app is removed. Both cascade-delete when the owning agent app is removed (including during account deletion). Mirrored to the internal Redshift ODS warehouse for analytics under the same deletion controls
Organization invite records (`org_invites`)	Until revoked or org deleted	Stores the invitee email address, invite status, role, and (for seat invites) a link to the reserved seat (`seat_id`). A seat invite to an email with no CREAO account reserves the seat and, on the invitee’s signup, auto-accepts to place them in the organization as an organization-only account. Pending invites are deleted when revoked by an admin. Expired invites become unusable but remain in the database until the organization is deleted. All invite records cascade-delete when the organization is deleted. Accepted invites are retained for audit until org deletion
Organization billing records (`org_subscriptions`, `org_credits`, `org_member_credit_caps`, `org_credit_operations`)	Until org deleted	Stores the organization’s Stripe subscription state, shared credit pool balance, per-member monthly usage caps and cycle counters, and per-request deduction idempotency log. All records cascade-delete when the organization is deleted
Connected-database configuration	Until admin disconnects the source	Encrypted credentials and discovery metadata (database/schema names) for enterprise BYOD sources. Hard-deleted immediately when an org admin disconnects the source; cascades on organization deletion. No backup copy is retained after disconnect
BYOD sensitivity catalog (`byod_catalog_entries`)	Until admin disconnects the source	Per-object review state for a connected BYOD source: table and column NAMES, the classifier’s sensitivity tag, an `allowed` flag, an optional admin-written business description, and who confirmed the review and when. Metadata only — no customer row values are stored. Cascades with the connection record: hard-deleted when an org admin disconnects the source, and on organization deletion
Connected-cloud configuration (`cloud_connections`)	Until the connection is disconnected/deleted	Non-secret references for a connected AWS account (Bring Your Own Cloud): provider, display name, AWS account ID, cross-account role ARN, region, and grant tier, plus the per-connection ExternalId stored AES-256-GCM encrypted. No long-lived cloud credentials are stored. The row is hard-deleted when you disconnect/delete the connection and is also removed when you delete your account; org-shared connections are removed on a best-effort basis when the organization is deleted (any residual rows become unreachable once the org is gone). When you disconnect a connection, any cached short-lived broker credentials are invalidated immediately; otherwise they expire on their own within the hour
Slack Agent App installation (`slack_installations`, `slack_thread_links`)	Until account deletion	Per-workspace install record for the Slack Agent App: Slack workspace/team identifiers, the installer’s bot token (AES-256-GCM encrypted, dedicated key), routing/allowlist/spend-cap configuration, and the installer’s deploy-time consent timestamp; `slack_thread_links` maps a Slack conversation to its CREAO thread. Disconnecting the app from CREAO settings (or removing it from the Slack workspace) revokes the Slack bot token and marks the installation inactive immediately, but the configuration row itself is hard-deleted only when the installer’s CREAO account is deleted — `installer_user_id` is plain text with no FK cascade, so deletion is performed explicitly in the account-deletion handler, which also removes the installation’s `slack_events` rows (below) regardless of their age
Slack Agent App event queue (`slack_events`)	Terminal rows purged after 30 days; all rows removed on account deletion	Dispatch bookkeeping for the Slack Agent App: the invoking Slack member’s Slack user ID and the raw text of the @mention or DM (plus file references) needed to build the agent run. The triggering member is not necessarily a CREAO account holder — the installer above is the CREAO account of record. Rows in a terminal state (completed, failed, or skipped) are purged by a daily retention job 30 days after last update; in-flight rows are retained only until the run settles. All of an installer’s rows are also hard-deleted immediately when their CREAO account is deleted, regardless of age. The non-secret columns (excluding message text and file references) are mirrored to the internal Redshift ODS warehouse for analytics under the same deletion controls
Connected-database standing instructions (`byod_data_source_instructions`)	Until the data source is disconnected or org deleted	Per-data-source standing instructions — free text (up to 20,000 characters) authored by organization members and injected into the agent’s system prompt for chats that use the data source. Cascade-deleted when the connected data source is disconnected or the organization is deleted. Any organization member can edit or remove the instructions
Organization prompt templates (`byod_prompt_templates`)	Until deleted by an org member or org deleted	Reusable chat prompt templates (template name, prompt body, optional data-source binding) authored by organization members. Deleted when any organization member deletes the template; org-scoped templates cascade-delete when the organization is deleted. Built-in templates (CREAO-managed defaults, not organization data) are seeded by CREAO and not tied to any account
Login records	365 days	One row per session with IP, user agent, device fingerprint, country code, and (when available) a coarse city/region estimate derived from the IP; used for abuse detection clustering and admin geo analytics
LLM transaction forensics (`credit_deduction_logs`)	12 months	One row per LLM API call with billing metadata (cost, model, token counts) and forensic invocation details (source IP, user agent, country code, Cloudflare edge-location code, JWT issued-at and age, upstream response identifier). Used for billing reconciliation, abuse cross-referencing (e.g. detecting stolen sandbox credentials and replay attacks), and audit. After 12 months the IP address and user agent fields are anonymized/dropped; aggregated totals (cost, tokens) may be kept longer for billing analytics
Video generation jobs (`video_generation_jobs`)	Until account deletion	Job records for AI video generation: prompt text, input asset S3 keys (image, video, audio), generated video S3 key, status, billing metadata, and error details. Hard-deleted on account deletion; no FK cascade exists so deletion is performed explicitly in the account-deletion handler
Image generation jobs (`image_generation_jobs`)	Until account deletion	Job records for asynchronous AI image generation: prompt text, reference-image S3 keys, generated image S3 key, provider-returned text, status, billing metadata, and error details. Hard-deleted on account deletion; no FK cascade exists so deletion is performed explicitly in the account-deletion handler
Local media render jobs (`media_render_jobs`)	Until account deletion	Job records for checkpointed local ffmpeg renders: declarative render arguments, workspace input/checkpoint/output S3 keys, status, and error details. Hard-deleted on account deletion; no FK cascade exists so deletion is performed explicitly in the account-deletion handler
In-app notifications (`notifications`)	Until account deletion	In-app notification inbox rows: the notification reason, related thread / agent-app / session identifiers, a stable i18n key plus structured parameters used to render localized copy (no free-text English is stored), and read state. Hard-deleted on account deletion; `user_id` is plain text with no FK cascade, so deletion is performed explicitly in the account-deletion handler
Push device registrations (`push_devices`)	Until device removal or account deletion	One row per registered mobile push device: the device push token (an opaque delivery credential treated as a secret — never logged raw and excluded from the Redshift ODS warehouse view), device platform, delivery environment, app version and device locale captured at registration, and lifecycle timestamps (first registered, last seen, disabled marker). No message content is stored. Removed when you disable push or sign out; hard-deleted on account deletion — `user_id` is plain text with no FK cascade, so deletion is performed explicitly in the account-deletion handler
Rate-limit abuse events (`rate_limit_violations`)	90 days	Sampled record (at most one row per actor + endpoint per minute) of rejected over-limit (HTTP 429) requests: time, path, HTTP method, source IP, an allowlist of non-sensitive request headers, the limiter bucket, and a redacted, size-capped request-body excerpt (body capture skipped entirely for auth / billing / credit / secret / token / payment / login routes). Used to detect scans and brute-force abuse. `user_id` is plain text with no FK cascade, so rows are erased explicitly in the account-deletion handler and are otherwise purged after 90 days by a daily retention job. Request headers and body excerpt are excluded from the Redshift ODS warehouse view
BytePlus task bindings (`byteplus_task_bindings`)	Stale-pending released after 2 hours; terminal rows purged after 30 days	Mapping rows linking a BytePlus task identifier to the internal request identifier so that an asynchronous video-generation poll can be settled against the original credit hold. Each row contains the BytePlus task identifier, internal request UUID, user identifier, model identifier, status, timestamps, and a metadata blob mirroring the per-request forensic context already captured in `credit_history` and `credit_deduction_logs` (request path, country code, edge-location code, source IP, user agent, JWT issued-at). No conversation content or generated assets are stored
Billing coupon records (`billing_coupons`)	As required for billing, tax, audit, fraud-prevention, and dispute records	Stores one-time coupon code, campaign type, discount terms, optional internal distributor note, Stripe coupon/promotion identifiers, creator/disable/redeemer attribution, and redemption timestamps. Redeemer email and user ID are removed when the redeemer’s account is deleted; admin email attribution is limited to internal staff audit context. Coupon email fields are excluded from the Redshift ODS warehouse view
Amplitude analytics events	Per Amplitude default retention	Usage events and session metadata exported to Amplitude for product analytics; no conversation content
Google Analytics / Google Ads conversion events	Per Google account retention configuration	Web analytics and conversion events exported to Google for product analytics, advertising attribution, and conversion measurement. Sign-up and purchase enhanced-conversion events include hashed email match data generated by the Google tag; no conversation content
Meta Pixel / Conversions API conversion events	Per Meta account retention configuration	Advertising attribution and conversion events exported to Meta for sign-up and purchase measurement. Events may include hashed email, hashed CREAO user identifier, IP address, user agent, Meta browser/click identifiers (`_fbp`, `_fbc`), and Meta click ID (`fbclid`); no conversation content
Reddit Pixel conversion events	Per Reddit account retention configuration	Advertising attribution events exported to Reddit for page visits, pricing views, sign-up, and purchase measurement. Events may include the Reddit browser identifier (`_rdt_uuid`), Reddit click ID (`rdt_cid`), a stable conversion ID, normalized email processed by Reddit for client-side hashing, and a namespaced SHA-256 hash of the CREAO user identifier; no conversation content
Impact.com conversion events	Per Impact.com account retention configuration	Affiliate attribution and paid-conversion records exported to Impact.com for eligible sign-up, subscription, and credit-purchase events. Events may include SHA1-hashed email, CREAO user identifier, Impact click ID (`IM_REF`), order ID, conversion timestamp, event type, subscription or purchase amount, and promo code; no conversation content
CREAO reflection interaction analytics, retrieval records, and playbooks	Until account deletion, thread deletion for persisted snippets, agent-app deletion for that agent’s shared playbooks, or per CREAO service retention policy	User chat turns and selected assistant final turns (with compact tool metadata) may be processed for interaction-quality monitoring; retrieval queries and resulting profile/playbook snippets may be processed to build prompt context; generated playbook records may be retrieved by CREAO for display in your Memory page. For a shared team agent, deleting the Agent App triggers a best-effort purge of that agent’s playbook bucket from CREAO’s reflection service. CREAO can disable this by removing reflection configuration. You may request deletion of reflection-held playbook data through privacy@creao.ai
Acquisition attribution	Until account deletion	UTM parameters, platform click IDs (including `gclid`, `fbclid`, `ttclid`, `msclkid`, `twclid`, and `rdt_cid`), Meta browser/click identifiers (`_fbp`, `_fbc`), referring site, landing path, first-touch timestamp, last-touch timestamp, owner-derived affiliate handle or referral code from public shared-thread and agent-install pages, and KOL-defined affiliate sub-tracking parameters such as `media` or `sub_id` stored with the account to measure campaign effectiveness, credit creators, affiliate partner distribution, and signup journeys. Deleted when the account is deleted (FK cascade)
Action approvals	Until the parent is deleted	Proposed connector-write payloads, validation previews, approval/rejection audit metadata, and apply results for guarded actions. For Agent App actions, deleted when the Agent App is deleted (FK cascade). For chat thread actions, retained until the thread is deleted or the user deletes their account
Agent Store views	90 days	Per-impression rows (authenticated viewer ID when available plus a 16-char SHA-256 hash of the IP) used for view counts, deduplication, abuse prevention, and trending ranking. Pruned daily by an automated cron at 03:30 UTC
Agent Store engagement	Until store agent or account deletion	Likes, bookmarks, shares, and written reviews (with star rating) on Agent Store listings. Deleted when the Agent Store agent is removed (FK cascade) or when the user account is deleted
Discover Skills install activity (`discover_skill_installs`)	Until account deletion	One row per Discover Skills entry installed by a user, used for idempotent install counts and product analytics. Deleted when the account is deleted (FK cascade)
Job applications (`career_applications`)	24 months after the final hiring decision	Stores applicant name, email, supplied links, per-question answers, hiring status/interview round, and CV metadata (original filename, S3 storage key, MIME type, size, content hash). The CV file itself lives in CREAO’s private upload bucket under `careers/applications/` and is deleted with the record. Retained to run the hiring process, to answer follow-up questions from candidates, and to satisfy record-keeping obligations for recruitment decisions; deleted or anonymized afterwards unless a legal or dispute hold applies. Applicants may request deletion at any time at support@creao.ai
Candidate identity links (`career_candidate_links`, `career_candidate_match_dismissals`)	Lifetime of the linked applications	Records that two applicant email addresses belong to the same candidate (or that staff dismissed a suggested match), so repeat applications are recognised as one person rather than duplicates. Contains only the two email addresses and the staff user ID that made the decision. Deleted with the underlying applications
Job-alert subscriptions (`career_job_alerts`)	Until unsubscribe request, or 24 months of inactivity	Stores the subscriber’s email address, alert scope (role/category/all), and the job or category the subscription came from. Used solely to send new-role notifications. Removed on request to support@creao.ai
Affiliate commission history (`affiliate_commission_rate_history`)	Campaign duration + 12 months	Stores affiliate link ID, KOL user ID, commission rate, effective timestamp, and admin creator identifier for revenue-share calculation, payout audit, and dispute handling. Rows are deleted when the affiliate link is deleted
Campaign enrollment records (`s1_trading_challenge_participants`)	Campaign duration + 12 months after results	Used for eligibility, audit, fraud prevention, prize administration, and support. Includes CREAO account identifiers, submitted WEEX UID/email, linked public X profile metadata, Discord enrollment requirement status, user-chosen public leaderboard agent name/slug, readiness/freeze status, and final rank/PnL. Total CREAO credits consumed may be computed from billing logs to determine prize eligibility; public pages may disclose eligibility status or prize-claim rank, while exact credit totals are visible only to the participant and CREAO admins. Deleted or anonymized after the retention period unless a legal, tax, security, or dispute hold applies; account deletion removes or anonymizes personal data where legally required. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Campaign enrollment records (`s2_trading_challenge_participants`)	Campaign duration + 12 months after results	Used for eligibility, audit, fraud prevention, prize administration, and support. Includes CREAO account identifiers, submitted debot email, submitted Robinhood Chain wallet address, enrollment ETH balance status, Agent API Trigger setup metadata, user-chosen public leaderboard agent name/slug, readiness status, and final rank/PnL/score. Deleted or anonymized after the retention period unless a legal, tax, security, or dispute hold applies; account deletion removes or anonymizes personal data where legally required. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Campaign leaderboard snapshots (`s1_trading_challenge_leaderboard_snapshots`)	Campaign duration + 12 months after results	Stores time-series equity, PnL, and trade-count snapshots used for ranking, audit, and public results. Deleted or aggregated/anonymized after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Campaign trade and leaderboard records (`s2_trading_challenge_trade_imports`, `s2_trading_challenge_leaderboard_snapshots`)	Campaign duration + 12 months after results	Stores imported Robinhood Chain/debot trades and time-series ETH equity, PnL, score, and trade-count snapshots used for ranking, audit, and public results. Deleted or aggregated/anonymized after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Campaign Agent webhook invoke records (`s2_trading_challenge_api_invokes`)	Campaign duration + 12 months after results	Stores Debot → community Agent webhook wrapper invoke history for Season 2: size-bounded callback payload (or a truncated preview when oversized), payload hash, Debot event id, dry-run flag, campaign phase, Platform run id when available, HTTP status, and dispatch outcome (`accepted` / `dispatch_failed` / `rejected`). Used for My Entry history, idempotent Debot retries, admin dry-run testing, and support. Cascade-deleted with the participant row; otherwise deleted or anonymized after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views mirror metadata under the same deletion controls and do not expose raw callback payloads
Campaign Kite side-event records (`s2_trading_challenge_kite_side_events`)	Campaign duration + 12 months after results	Optional Season 2 Kite Agentic Wallet side-event progress: cloned Kite agent app ID, installed Passport skill paths, confirmed Base wallet address, deposit verification timestamp and USDC balance, submitted Base transaction hash, verification/completion timestamps, and reward-credit grant status/timestamp for the Kite completion bonus. Used for side-event eligibility, leaderboard Kite badge/+100 score bonus, support, and fraud prevention. Cascade-deleted with the participant row; otherwise deleted or anonymized after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls. No wallet private keys are stored
Campaign admin action records (`s1_trading_challenge_admin_actions`)	Campaign duration + 12 months after results	Internal audit trail for admin operations. Actor email is internal staff, not user PII. Deleted after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Campaign admin action records (`s2_trading_challenge_admin_actions`)	Campaign duration + 12 months after results	Internal audit trail for S2 admin operations. Actor email is internal staff, not user PII. Deleted after the retention period unless needed for prize, fraud, security, legal, or dispute records. Internal ODS warehouse views (`creao.ods.community_v1_*`) mirror these records for analytics under the same deletion controls
Scheduled-run email deliveries (`schedule_email_deliveries`)	30 days	Delivery records (schedule ID, run status, delivery outcome, error) created each time CREAO sends a scheduled-run summary email. Deleted automatically by nightly cron after 30 days. No email content is stored
Account data	Until account deletion	Deleted within 30 days of account closure (per GDPR Article 17 and CCPA requirements)
Account deletion requests (`account_deletion_requests`)	Minimum 5 years, or longer where required by applicable law	A record of each request to delete an account and how an admin handled it. Holds request metadata (status and timestamps, source IP), an email/name snapshot captured at request time, an optional selected reason code (or codes) and optional free-text detail on why the user is leaving, and any admin handling notes. This record deliberately has no foreign key to the user, so it survives deletion of the underlying account in order to evidence — for legal, compliance, and audit purposes — that the deletion request was received and actioned. Only non-PII fields (identifiers, status, timestamps, and the closed-set reason codes) are mirrored to the internal ODS warehouse; the email/name snapshot, IP address, cancel token, free-text reason detail, and admin notes are excluded from that view
Developer profile (`developer_profiles`)	Until account deletion	Optional developer-portal profile fields (display name, company, website) on developer.creao.ai, keyed to your account. No cross-database FK exists, so the row is hard-deleted explicitly in the account-deletion handler
Linked social profiles	Until account deletion or auth-state revocation	X / Discord profile data and OAuth tokens. Discord tokens are reused for server-membership verification; X tokens are held only as proof of the link and are not used for outbound reads. Bindings are permanent (the same external identity cannot be re-linked to a different CREAO account, to prevent reward-farming). Deleted when the CREAO account is deleted (FK cascade) and also automatically wiped whenever authentication state is revoked (password reset, admin force-logout, account ban) so an attacker-attached link cannot outlive the security event. Provider-side revocation (X / Discord settings) immediately invalidates the stored token but leaves the binding row in place
Payment data	As required by law	Managed by Stripe; CREAO does not store card numbers

Contact

For privacy and compliance inquiries or Data Processing Agreement (DPA) requests, contact privacy@creao.ai. CREAO, Inc. acts as the data controller for personal data processed through the platform.

Get Started

Features

Agent Brain

Advanced

Trust & Safety

AI & Model Usage

Connector Data Access

Slack Agent App (Inbound)

Skill Data Handling

Subprocessors

Billing Routing

Data Retention

Contact

​AI & Model Usage

​Connector Data Access

​Slack Agent App (Inbound)

​Skill Data Handling

​Subprocessors

​Billing Routing

​Data Retention

​Contact

AI & Model Usage

Connector Data Access

Slack Agent App (Inbound)

Skill Data Handling

Subprocessors

Billing Routing

Data Retention

Contact