data & secret handling
What Xymotrone stores, how your credentials and provider keys are encrypted, and who can reach them. These are the app owner's own statements about how the platform is built.
Stored logins, provider API keys and proxy passwords are encrypted server-side with AES-256-GCM before they reach the database. Each value uses a fresh random 96-bit IV and is stored as versioned ciphertext, never as plaintext.
The encryption key is derived from a server-only environment secret (SECRETS_MASTER_KEY) that is never stored in a table, never returned by an API and never present in the browser bundle. Decryption happens only inside server code executing your task.
Secret tables are write-only from the browser: database policies allow inserts and updates by their owner but no client reads. Revealing your own saved password goes through an authenticated server function that decrypts on demand and logs nothing.
Every task, run, credential, proxy, pool and model provider row is scoped to the account that created it and enforced by row-level security in the database. Other customers cannot read your rows, and neither can an unauthenticated request.
Before observations, step logs and error messages are persisted, known secret values for that run are stripped and replaced with [redacted], so credentials do not leak into run history or diagnostics.
Only cookies required to sign you in and keep the app working are set by default. Anything optional is gated behind the consent banner, and you can change your choice at any time.
Xymotrone provides managed headless browser infrastructure. This policy describes the data we handle when you create an account and run browser automation through the platform. It reflects how the product is actually built, not a generic template.
Account data (email address and authentication records), billing data handled by our payment processor, and the operational data you configure: tasks and their instructions, allowed domains, schedules, proxy endpoints, credential entries, model provider endpoints and API keys.
Running a task produces run records: status, timings, step timelines, model latency and token metrics, error codes, diagnostics and optional screenshots of the pages your agent visited. This data exists so you can debug and audit your own runs.
Credential passwords, TOTP seeds, proxy passwords, CAPTCHA provider keys and cloud model API keys are encrypted with AES-256-GCM using a key derived by SHA-256 from a server-only master secret. Ciphertext is stored in dedicated secret tables that the browser can write to but never read. Values are decrypted only in server-side execution — to inject a login into a page, authenticate a proxy, or attach an API key to an outbound model request. Cloud model calls are proxied server-side so your provider key is never exposed to the browser.
Screenshots captured during a run are written to a private storage bucket that is not publicly listable. They are served to you through short-lived signed URLs generated for your authenticated session only.
We use a managed cloud database and authentication provider, a payment processor for subscriptions, and — only when you configure them — your chosen proxy providers, CAPTCHA solving services and AI model providers. Requests to those services are made with the keys you supply, on your behalf, and are governed by their own policies.
We do not sell your data. We do not use the contents of your runs to train models. We do not read your stored credentials for any purpose other than executing the task you configured. Support staff cannot decrypt your secrets through the application UI.
Operational data stays until you delete it: deleting a task, credential, proxy or run removes the associated rows and the secrets attached to them. Deleting your account removes your account-scoped data. Billing records are kept as long as required for accounting and tax purposes.
You can export or delete your tasks, credentials, proxies and runs from within the app at any time, change cookie preferences from the banner or the link below, and request a Data Processing Agreement before onboarding. For access or deletion requests beyond the in-app controls, contact us from your account.
We update this page when the way we handle data changes. Material changes are announced by email or in-app notice before they take effect.
Review the compliance charter for our collection commitments, or adjust what optional cookies you allow.