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 outline into your PDF/PPTX with all network access disabled. Every outline field is HTML-escaped before rendering, with one bounded exception: the optional rich-content slide body, which is reduced server-side to a fixed allowlist of plain formatting tags (paragraphs, lists, tables, emphasis) with every attribute stripped — scripts, event handlers, styles, links, and references to remote resources cannot survive sanitization. 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. Authorized campaign admins may access campaign participant credentials through logged audit exports when needed to verify trading-campaign activity. 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. 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.

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/*.
  • 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, file management, schedules, or Agent Store publishing.
  • Agent create, replacement update, and natural-language edit creation 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.
  • 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.
  • 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.

​
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.