Skip to main content
CREAO is committed to maintaining robust security practices. This page outlines the measures we take to keep your information safe.

​
Data Protection

Encryption in Transit

All data transmitted between your browser and CREAO servers is encrypted using TLS 1.2+. API calls to third-party LLM providers are also encrypted in transit.

Encryption at Rest

All stored data — including conversations, files, memories, and secrets — is encrypted at rest using AES-256 encryption.

Sandbox Isolation

Every chat thread and agent run executes in its own isolated Linux sandbox. Sandboxes are ephemeral, network-isolated from other tenants, and destroyed after use. Designed to prevent cross-tenant data leakage. One narrow exception runs on CREAO’s own servers instead of the sandbox: /slide deck rendering, where a headless browser converts a schema-validated deck bundle into your PDF/PPTX with all network access disabled. Deck HTML is rewritten server-side against a strict allowlist before it is rendered: only listed tags and attributes survive, and anything unlisted is removed. <script>, <style>, <iframe>, <object> and <embed> are dropped together with their contents; event-handler attributes cannot survive, because they are not on the allowlist; and javascript: is not among the permitted URL schemes. Presentational, accessibility and linking markup is deliberately retained — decks are documents meant to be presented, so that markup is kept on purpose rather than stripped. Execution is contained by the renderer instead: it runs on CREAO’s own servers with network access disabled and a default-src 'none' content-security policy. The renderer never loads sandbox-controlled URLs and never executes sandbox-authored code.

Secret Management

API keys and credentials stored as Secrets are encrypted at rest and managed via a dedicated secrets store. They are injected into sandboxes as environment variables at runtime and never logged or persisted in plain text by automated execution systems. Trading-campaign secrets follow the same path: WEEX API credentials and the Season 2 debot developer API credentials (DEBOT_API_KEY / DEBOT_API_SECRET) are not stored in campaign tables, and the S2 credentials are used only by the participant’s Agent runtime for debot execution when a live non-dry-run event is processed. S2 never collects a wallet private key — debot’s custodial wallet API signs Robinhood Chain (EVM) transactions server-side, and the credentials are revocable in debot’s developer center. The optional Season 2 Kite Agentic Wallet side event likewise never collects a Base or Kite wallet private key: CREAO stores only the confirmed Base address, deposit/tx verification metadata, and a pinned kpass CLI binary as an agent app file (downloaded server-side from cli.gokite.ai with checksum verification); Passport skills are installed from the public gokite-ai/passport-skills repository onto the participant’s CREAO account, and on-chain checks use a Base RPC endpoint with the submitted address/tx hash only. Authorized campaign admins may access campaign participant credentials through logged audit exports when needed to verify trading-campaign activity, and may view or roll back Kite side-event progress through write-gated admin actions. Connected-database credentials provided by enterprise customers (Bring Your Own Data) are encrypted under a dedicated key separate from the one used for user-uploaded secrets, so the two key lifecycles can be rotated independently. Hapag-Lloyd connector credentials (the Client ID and Client Secret you paste when connecting, plus your Online Business email) follow the same pattern: the key pair is encrypted at rest under its own dedicated key, used only server-side to authenticate CREAO’s calls to the Hapag-Lloyd API — credentials never enter agent sandboxes or LLM context — and everything is deleted when you disconnect the integration. CMA CGM connector credentials follow the identical pattern under their own dedicated key, additionally covering the short-lived bearer tokens CREAO mints from them, which are likewise encrypted at rest, used only server-side, and deleted on disconnect. The CREAO Shopify app stores one offline access token per connected store, encrypted at rest under its own dedicated key and used only server-side to call the Shopify Admin API. Unlike a session-scoped token it does not expire on its own, so it is deleted on three triggers: when you disconnect the store in CREAO, when the app is uninstalled from the Shopify admin, and when Shopify sends its shop-redaction request 48 hours after uninstall. MSC connector credentials (the Developer Portal subscription key you paste when connecting) follow the same pattern: the key is encrypted at rest under its own dedicated key, used only server-side to authenticate CREAO’s calls to the MSC API — credentials never enter agent sandboxes or LLM context — and it is deleted when you disconnect the integration. CargoAI connector credentials (the CargoCONNECT API key you paste, plus the office identity you supply — email address, first and last name, company name, IATA code, CASS code, and country) follow the same pattern with one deliberate distinction: only the API key is encrypted at rest, under its own dedicated key, while the identity fields are stored in plaintext columns because CREAO must read them to build the caller identity CargoAi requires on every request; those fields are never projected to the analytics warehouse, the key and the identity are used only server-side and never enter agent sandboxes or LLM context, and the encrypted key, the identity, the rate-quote cache, and the booking index are all deleted when you disconnect the integration. This covers every credential on the connection, not just the database password: where a connection reaches the database through an SSH bastion, the SSH private key and passphrase are held under the same dedicated key, as is any CA certificate supplied to verify the database’s TLS certificate. An SSH private key is a materially more powerful credential than a database password, so it is called out explicitly here; like the rest of the connection secret it is never returned by the API and is decrypted only in-process for the duration of a connection attempt. As a narrow operational exception, if a platform process approaches an out-of-memory crash it may capture a one-shot diagnostic heap snapshot — a full memory image that can transiently include decrypted secrets and in-flight data — to a private, access-restricted, encrypted store that auto-expires after 90 days; it is used solely to debug the crash and is never exposed to users.

Recruiting Data (CREAO Careers)

CVs submitted through careers.creao.ai are written to CREAO’s private S3 upload bucket under a careers/applications/ key derived from a random application identifier, with the same AES-256 encryption at rest as other user files. They are never placed behind a public URL and never served through a CDN. Reading an application or downloading a CV requires an authenticated session on the careers admin surface, which is restricted to a named allowlist of CREAO recruiting staff — narrower than the general staff-admin rule applied elsewhere. Download requests resolve the storage key from the application record, never from client input, so a CV cannot be fetched by guessing or supplying a key. Applicant-supplied rich-text answers are reduced to a fixed allowlist of plain formatting tags with every attribute stripped — twice: once server-side when the application is stored, and again in the browser before the answer is rendered on an admin screen. Plain-text answers are rendered as escaped text, never as markup. Applicant-supplied profile and portfolio URLs may be rendered as clickable http(s) links on the authenticated careers admin surface only (with rel="noopener noreferrer"), so recruiters can open them without copying; they are never rendered as arbitrary HTML.

AI-Generated Media Delivery

Google Veo videos are retrieved by CREAO after generation — either downloaded from a Google-signed URL (Gemini API path) or received inline in the generation response (Vertex AI path) — and stored in CREAO’s encrypted S3 storage using the same AES-256 protection as other user files. BytePlus video outputs may be fetched by CREAO from the original provider origin or through a configured CREAO CDN origin mapping before storage. Some provider-hosted media, including BytePlus image outputs, may still be delivered through short-lived, signed URLs served directly from the upstream provider’s content-delivery network. These links expire automatically, are unguessable and time-limited, and should be treated as sensitive.

​
Infrastructure & Controls

Infrastructure

CREAO is hosted on AWS with network-isolated infrastructure, web application firewall protection, and DDoS mitigation.

Access Controls

Internal access follows the principle of least privilege. Production systems require MFA and are audited. No engineer has standing access to production databases — access is provisioned on-demand with time-bound sessions.

Audit Logging

All administrative actions are logged in an immutable audit trail. Logs include the actor, action, target resource, and timestamp. Audit logs are retained for 90 days.

Vulnerability Management

We run automated security scans daily covering dependency vulnerabilities, secret detection, and infrastructure configuration. Critical vulnerabilities are triaged and patched within 24 hours.

​
Account Security

CREAO employs multiple layers of protection against account abuse and unauthorized access:
  • Rate limiting — per-IP and per-user rate limits on authentication endpoints to mitigate brute-force attacks
  • Bot detection — automated traffic patterns are detected and challenged with proof-of-work puzzles
  • Password security — passwords must meet minimum length requirements at signup and are stored using industry-standard hashing (bcrypt). Plaintext passwords are never persisted
  • Disposable email blocking — signups from known disposable/temporary email providers are blocked
  • CAPTCHA verification — Cloudflare Turnstile challenges on signup and sign-in to prevent automated account creation
  • IP and email blocklists — admin-curated blocklists for known malicious IPs (including CIDR ranges), email domains, glob patterns, and canonical email inboxes (blocks all address aliases resolving to the same inbox, including dot-trick and plus-address variations). Enforcement is applied uniformly across all account-creation and session-transfer paths, including legacy migration flows
  • Unknown device notifications — users are notified when they sign in from an unrecognized device

​
Developer API Keys

Developer Platform Account API keys are server-side secrets for backend use. They can create, edit, and run personal agents owned by the same CREAO account through developer.creao.ai/v1/*, and can also read, overwrite, or clear that agent’s long-term memory, list, download, or delete files in that agent’s skill file space, and list, install, enable, disable, or refresh account-level Agent Brain skills (the same catalog as agent.creao.ai/skills). Disabling a skill unmounts it from the sandbox but does not delete it. Super Agent (/v1/super-agent/*) and product-profile (GET/PUT /v1/product-profile) routes are available only to allowlisted accounts. If you need access, email the CREAO team at support@creao.ai.
  • Keep Account API keys out of browser frontend code, mobile apps, public repositories, client logs, and analytics events.
  • Both Account API keys (cr_sk_) and App-scoped API Trigger keys (capi_) can be passed as a creao-api-key query parameter instead of the Authorization header, for platforms that cannot set custom headers. Prefer the header: a key passed this way may be captured in infrastructure access logs, browser history, and referrer headers, independent of CREAO’s own request logging (which never stores raw keys). Rotate keys used via the query parameter more frequently.
  • Revoke unused or exposed keys from Developer Console.
  • Account API keys cannot authenticate Console session APIs, internal CREAO routes, team-agent management, workspace or personal file browsing outside an agent’s skill file space, schedules, or Agent Store publishing.
  • Agent create, replacement update, natural-language edit creation, memory overwrite/clear, agent-file delete, and account-level skill write (install, enable, disable, refresh) requests are rate-limited separately from run requests to reduce abuse from leaked keys.

​
Connector Security

Connectors provide scoped access to third-party systems. See Skills and Connectors for the full feature overview.
Connector permissions are defined by the provider and the scopes you approve during authorization. Only connect services you trust for your workflow.
  • Connector tools run only for authenticated users with active connections.
  • Meta Ads OAuth tokens are encrypted at rest (AES-256-GCM) and used only server-side to call the Meta Marketing API — the token never enters an agent sandbox or LLM context; sandbox code receives an opaque connection identifier instead. Meta issues no refresh token, so CREAO exchanges the long-lived token for a new one before it expires and discards the previous value; disconnecting deletes the stored token. Because the connector’s scopes permit writes that can cause ad spend, every campaign, ad-set, ad-creative, and ad creation or update — including budget and status changes — is classified as a write action, so under the default Always ask autonomy it is held for your explicit in-chat approval before anything reaches Meta. Selecting Auto autonomy lets those writes proceed without checking in.
  • TikTok OAuth access and refresh tokens are encrypted at rest (AES-256-GCM) and used only server-side — neither token enters an agent sandbox or LLM context. TikTok rotates the refresh token on every use, so refreshes are serialized per connection to avoid two concurrent calls invalidating each other, and the refresh token’s own expiry is tracked so an expired grant asks you to reconnect rather than failing mid-task. The permissions CREAO requests are read-only apart from video.upload (creates a draft in your TikTok inbox that you finish in the app) and video.publish (posts a video directly to your profile). Both are classified as write actions, so under the default Always ask autonomy each is held for your explicit in-chat approval before any bytes reach TikTok. Before a direct post the agent must fetch TikTok’s creator-info and have you confirm the visibility and interaction settings; the visibility you choose is validated against what TikTok currently allows the account. Until CREAO’s app passes TikTok’s content audit, direct posting is restricted by TikTok (the connected account must be set to private) and is disabled for general use behind a feature gate. Video bytes are read only from CREAO’s own storage over a signed, short-lived URL — arbitrary external URLs are rejected — and disconnecting revokes the grant with TikTok before deleting the stored tokens.
  • Etsy OAuth uses mandatory PKCE. Access and refresh tokens are encrypted with a dedicated AES-256-GCM key and used only by the integration service; the sandbox receives only an opaque connector id. Refresh is serialized per seller connection, and both credential/state tables are excluded from the analytics warehouse. CREAO requests only the listing, shop, and transaction read/write scopes needed for seller automation—not buyer-email, saved-address, profile, billing-statement, or permanent-listing-delete scopes—and filters buyer email and street-address fields from receipt responses before they reach the agent. Product photos and digital files are accepted only from CREAO’s own signed storage URLs. Publishing, price/inventory changes, media/file changes, and shipment tracking submissions are classified as approval-required writes under the default autonomy policy. The connector remains gated until Etsy Commercial Access and the required written authorization for seller-requested AI-assisted processing are in place.
  • Agents may invoke connector tools through approved tool calls or generated sandbox code, but both paths resolve through CREAO’s connector runtime and require the same active connection, allowlist, and validation checks.
  • Input validation and tool allowlists are applied before execution.
  • Connection metadata exposed in product responses is sanitized.
  • Disconnect/delete operations invalidate connector use from CREAO.

​
Connector auth model

  1. You initiate a connector connection.
  2. You approve provider permissions (OAuth scopes or API key access).
  3. CREAO stores connection metadata required to execute connector tools for your account.
  4. You can disconnect or remove a connector at any time.

​
Device Connect Security

CREAO Connect lets you pair your own computer or server so the agent can invoke local capabilities on it (running a shell command, reading local files, or calling a custom MCP server you configure on the device). The device — not CREAO — decides whether to run each request.
A paired device executes what it’s configured to allow. Review your device’s consent policy, especially for the built-in shell-command capability, and pair only machines you trust the agent to act on.
  • Pairing — a device is paired explicitly by the user (via CLI or GUI) and issued a per-device access token; the platform stores only a hashed/preview form of that token. You can revoke a device at any time, which immediately invalidates its token.
  • Consent policy — every invoke is checked against a per-device consent.json policy with three tiers: allow (run immediately), deny (refuse), or ask (park the request on an interactive GUI prompt until you approve or deny it). New pairings default to ask for the built-in shell-command capability, so nothing runs unattended until you decide otherwise; a device with no GUI attached denies ask-tier requests rather than running them.
  • Approval prompts and standing grants — an ask-tier request raises an always-on-top prompt that surfaces even when the app’s main window is hidden, and it is on a clock: it shows a visible countdown and denies automatically when the countdown expires. Deny is the default focus and is bound to Esc. The prompt can also record a standing grant for that one capability, which writes allow into the policy so the same action stops asking; this is off by default, is offered per capability only (never per MCP server), and a capability that can make changes that cannot be undone shows an explicit warning when you tick it. An automatic denial never writes a rule. Every standing grant is listed and revocable in the app’s Access tab.
  • Capability labels are self-reported claims — the “can make changes that cannot be undone” / “read-only” labels shown next to a capability come from the device’s own tools and MCP servers, which CREAO does not control and does not verify. They are advisory context for you and the model, never an authorization input: no consent or enforcement decision is relaxed on the basis of a label, and a capability that declares nothing is treated as if it can make irreversible changes.
  • Transport — invoke and result messages travel over AWS IoT Core (MQTT), authenticated per-device and scoped so a device can only publish/subscribe on its own topics.
  • Untrusted output — a capability’s result (command output, file contents, MCP tool response) is treated as untrusted content from code CREAO does not control, and is explicitly framed as such to the model.
  • Pause and revoke — you can pause a device (“do not disturb”) to refuse new invokes without revoking it, or revoke it outright to invalidate its token immediately.

​
Per-Agent Data Access (BYOD)

A connected database is scoped for the organization as a whole, and then again for each agent. An agent’s own grant is a set of tables, and optionally a subset of columns within a table — an agent built to summarize orders can be given orders.id and orders.amount without ever being given orders.ssn.
  • Two layers, intersected — the org-wide catalog decides what anyone may read from the source; the per-agent grant narrows that further. An agent can only ever reach the intersection, so tightening the org catalog immediately tightens every agent.
  • An agent is only shown what it may read — the schema an agent sees is filtered by its own grant, so a withheld column is not in the picture it writes queries from.
  • Queries are checked, not just the schema — a query naming a table outside the grant is refused, as is SELECT * against a table whose grant is a partial column list, and a column reference outside the grant when the query reads a single table. A query the SQL parser cannot analyze is refused rather than allowed.
  • A grant can never exceed the person who set it — an operator cannot give an agent access to a table they cannot read themselves.
Where a query joins several tables, an unqualified column name (SELECT email FROM a JOIN b) cannot be attributed to a specific table from the SQL alone. For that case the guarantee rests on the narrowed schema above — the agent is never shown the withheld column — rather than on the query check.

​
Reviewing failed queries

A database rejecting the agent’s SQL is a quality problem, not a breach — but it is one CREAO has to be able to see in order to fix. An internal dashboard, behind the same administrator gate as the rest of CREAO’s admin tooling, shows the rate of failed agent queries alongside a rolling window of the failing statements and the errors they returned.
  • Failures only — a statement that ran successfully never appears. The surface exists to diagnose queries the database refused.
  • No result data — it shows the statement text (truncated) and the database error. Rows returned by a query are not part of it.
  • Read from the warehouse’s own history — this reads the query log the data warehouse already retains, roughly seven days, rather than a copy CREAO keeps. Nothing new is persisted to build it.
  • Scoped to CREAO’s own warehouse today — it currently observes only CREAO’s analytics database. Extending it to customer-connected sources is a change we would document before making.
Statement text can embed values the agent was asked to filter on, so this is treated as customer data under the same handling rules as the rest of the platform.

​
Cross-Account Cloud Access (BYOC)

When you connect your own AWS account (Bring Your Own Cloud) so the agent can read observability data or provision infrastructure, access is granted through a cross-account trust model — never by handing CREAO long-lived credentials.
You stay in control of the grant. CREAO provides the CloudFormation template; you deploy it in your own account, choose the tier, and can revoke access at any time by deleting the stack or disconnecting in CREAO.

​
Cross-account trust model

  1. You pick a tier in CREAO and receive a per-connection ExternalId plus the CREAO broker principal ARN.
  2. You deploy a CREAO-provided CloudFormation stack in your own AWS account. It creates an IAM role that trusts only the CREAO broker principal and only when the request carries the matching sts:ExternalId — confused-deputy protection that prevents a different CREAO tenant (or anyone else) from assuming your role.
  3. You paste the resulting role ARN back into CREAO and validate. No static access keys are ever exchanged.
Two tiers are offered:
  • Read-only (debug) — grants only read-only CloudWatch logs, metrics, and alarms; creates no other resources.
  • Deploy (provision) — grants PowerUserAccess (all services except IAM and Organizations) plus IAM CreateRole/PassRole scoped to creao-* roles that must carry a required permissions boundary, so a provisioning agent cannot escalate privileges or touch IAM users or your organization. Today the agent exercises only the read-only tools above against a connected account; deploy-and-operate execution (gated behind a plan → human-approve → apply flow) is a later phase.

​
Short-lived credentials, never in the sandbox

A host-side STS broker authenticates as CREAO’s own service identity and assumes into your role with the ExternalId to mint short-lived credentials (≤1 hour), re-minted on demand. These credentials are used in-process on the host by the read-only CloudWatch client; they are never logged and never enter the agent sandbox. When you disconnect a connection, any cached broker credentials are invalidated immediately.

​
Read-only enforcement layers

Read access for the debug tier is enforced by three independent layers, so a misconfiguration in any one does not widen access:
  • The IAM policy in the CloudFormation template grants only read-only CloudWatch/Logs actions.
  • A restrictive STS session policy is applied when assuming the role, capping the session to the same read-only actions regardless of how broad the granted role becomes.
  • A tool allowlist limits the agent to a fixed set of read-classified CloudWatch tools (filter log events, describe log groups, describe alarms, get metric statistics).

​
ExternalId protection

The per-connection ExternalId is the only secret in a connection record, and it is encrypted at rest with AES-256-GCM using a per-deployment key sourced from a SecureString SSM parameter that is never exposed to humans. The key is kept separate from other secret-encryption keys so its rotation lifecycle is independent. The sanitized connection data returned to the product never includes the ExternalId.

​
Template hosting

The only public surface is the CloudFormation templates themselves: they are hosted on a public S3 HTTPS URL so the one-click quick-create link can load them. The templates contain no secrets — the ExternalId and broker ARN are supplied as stack parameters at deploy time, not baked into the files.

​
Slack Agent App Security

The Slack Agent App is an inbound integration — Slack sends CREAO events, rather than CREAO calling out to Slack — so it has a different auth model from the outbound connectors above. See Privacy: Slack Agent App (Inbound) for what data this collects and from whom.
  • Inbound request authentication: every event Slack sends is verified against Slack’s request-signing scheme (HMAC-SHA256 over the request body and timestamp, using a per-app signing secret) within a bounded replay window. Unsigned, incorrectly signed, or stale requests are rejected before any data is processed or persisted.
  • Bot token protection: each workspace’s Slack bot token is encrypted at rest (AES-256-GCM) using a dedicated key, kept separate from other secret-encryption keys so its rotation lifecycle is independent — the same pattern used for the BYOC ExternalId above. The token is decrypted only in-process, at the moment a reply is posted back to Slack.
  • Channel scoping: the bot only processes messages in channels it has been explicitly added to, or direct messages sent to it — it does not read channels it hasn’t been invited to.
  • Installer-scoped execution and rate limits: every triggered run executes as the installer’s own CREAO account, with a per-channel daily cap and a per-installation burst limit to bound how quickly one workspace can consume the installer’s credits.
  • Organization binding protection: a Slack workspace connected on behalf of a CREAO organization stays under that organization’s control. Reinstalling the app cannot silently move the workspace to a personal account or a different organization — any rebind away from the bound organization requires the person completing the install to be an admin of that organization, verified at install-completion time. Managing or disconnecting an organization-bound installation likewise requires organization admin rights, regardless of who originally installed it.
  • Staged rollout: the integration is gated behind an internal rollout control and is not available to installers until explicitly enabled.

​
Skill Security

Skills are instruction packages that shape agent behavior — they do not, by themselves, grant external access. See Skills and Connectors for the full feature overview.

​
Safety boundaries and controls

  • Sandbox isolation: Skill-driven code execution occurs in isolated runtime environments.
  • Connector gating: Skill prompts cannot use connector actions without valid active connector auth.
  • Secret controls: Secrets remain managed via runtime injection patterns and are not expected to appear in normal response payloads.
  • Validation and guardrails: Tool invocation and platform-side checks constrain execution paths.

​
Sensitive-domain guidance

Some official skills cover regulated or high-impact topics (for example: medical, legal/privacy, or financial analysis). For those categories:
  • Outputs are informational and should be reviewed by qualified professionals.
  • Users should validate conclusions before making legal, medical, financial, or compliance decisions.
  • Organizations should define internal approval flows for high-risk outputs.

​
Built-in vs custom skills

​
Responsible Disclosure

If you discover a security vulnerability, please report it to security@creao.ai. We acknowledge reports within 48 hours and aim to resolve critical issues within 7 days. Please do not publicly disclose vulnerabilities until we have had an opportunity to address them.