> ## Documentation Index
> Fetch the complete documentation index at: https://docs.creao.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Privacy
> How CREAO handles your data, respects your privacy rights, and works with AI providers.
CREAO respects your privacy and gives you control over your data.
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. 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 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, 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** — country derived from your IP address by Cloudflare (ISO 3166 alpha-2 country code) is recorded with each login event for analytics, abuse detection, and billing routing. No city-level or precise location is stored
* **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. 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. 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. 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 (currently a successful completion), 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. No conversation content, message text, or generated output is stored — only stable keys and identifiers. 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. 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
* **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. 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 you use the `/workflow` command, 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
* **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](mailto:privacy@creao.ai)
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 to bridge browser and server-side analytics events. 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, Fireworks AI, Meta, and BytePlus are processed under API
agreements or
provider API terms that prohibit use of your data for model training. MiniMax
is reached directly via the MiniMax API under MiniMax's API terms, which
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. Requests relayed through
OpenRouter may 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.
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.
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 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](#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 after each completed turn using Claude Haiku, from a truncated copy of your latest message and the agent's answer plus the names of your saved agents and available integrations — regardless of the LLM provider selected for the conversation. Suggestion generation is a platform feature and is not billed to your account.
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.
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)
* **Z.AI** (GLM 5.2)
* **Moonshot AI** (Kimi K3, via OpenRouter)
* **Fireworks AI** (inference for GLM 5.2 requests relayed via OpenRouter, under CREAO's Fireworks account; may also serve other OpenRouter-routed open models)
* **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 and Moonshot AI, Fireworks AI, Meta, and BytePlus are accessed via API paths with no-training commitments. 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.
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](/features/skills-and-connectors) for the full feature overview and [Security](/trust-and-safety/security#connector-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 |
| Microsoft (Outlook, Teams, OneDrive, Word, Excel) | OAuth | Mail, collaboration messages, files, documents, workbook data | 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 |
| 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](#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](#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](mailto: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](/features/skills-and-connectors) for the full feature overview and [Security](/trust-and-safety/security#skill-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** | LLM provider (MiniMax models); internal response-quality evaluation | Conversation messages, context, sampled completed conversations and assistant responses used for quality evaluation |
| **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; this is a conversation-content data flow | Conversation messages, context, and user-provided image inputs for Muse Spark requests |
| **OpenRouter** | LLM API gateway — relays requests to Z.AI and Moonshot AI models (GLM 5.2 requests are served by Fireworks AI under CREAO's Fireworks account; see the Fireworks AI row) | Conversation messages, context (relayed to the serving model provider) |
| **Fireworks AI** | LLM inference provider — serves GLM 5.2 requests relayed via OpenRouter under CREAO's Fireworks account; may also serve other OpenRouter-routed open models (e.g. Kimi K3) | 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 |
| **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, country derived from IP address (used for billing routing, login geolocation analytics, and abuse detection) |
| **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), 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 | 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) |
| **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, when research search is enabled for your account and the agent runs a research search on your behalf) | Search query text and optional search-intent text composed by the agent (both may derive from your prompt), plus corpus type and recency parameters. Requests are made server-side with CREAO's API key — no user identifiers, account data, or conversation history are sent |
| **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 |
| **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. No conversation content, message text, or generated output is sent to Apple |
| **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, acquisition attribution, and agent / thread / session activity timestamps and titles. customer.io does NOT receive credentials (passwords, secrets, API keys, tokens), conversation/message content, or forensic IP / user-agent logs |
## 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 | HMAC hash stored; raw key shown once at creation and never stored |
| 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 created through `/workflow`, 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) |
| 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, and role. 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 |
| 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-agent-app-inbound): 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](#slack-agent-app-inbound): 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, and country code; 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 |
| 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](mailto: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) |
| 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 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](mailto:privacy@creao.ai)**.
CREAO, Inc. acts as the data controller for personal data processed through the platform.