Privacy Policy

Effective August 17, 2026

Applies to the AgentBrowser website (getagentbrowser.com), the hosted control plane and API (app.getagentbrowser.com), the console, the MCP server, the Python SDK, and related client software.

This document is the detailed, engineering-grounded backing for the short notice published at getagentbrowser.com/legal. Where the two differ on a factual point, this document is the current source of truth — the short notice is a summary of it, not a separate policy.

Data controller: Transition 2 Consulting Inc, the entity operating AgentBrowser.
Governing law: the laws of the State of Delaware, USA (see Terms of Service §10 for venue).
EU/UK customers: a Data Processing Addendum (DPA) is available on request — contact us (§8).

1. What we collect, and why

1.1 Account and billing information

Email address, workspace/team membership, and role are collected at signup. Paid-plan billing would be handled by Stripe via Stripe Checkout — AgentBrowser never receives or stores your card number, Stripe collects it directly — but Stripe is not configured in production today (confirmed live: GET /api/plans returns "billing_enabled":false), so no paid plan can currently be purchased and no billing data is flowing to Stripe. If and when an operator enables it, what we'd store is your billing email, Stripe customer/subscription identifiers, plan tier, and subscription state (internal/billing, cmd/gb-server/billing.go), and Stripe webhook events would be deduplicated by Stripe's event ID so a redelivered event can't double-apply.

1.2 Waitlist / early-access signups

Before you have an account, the public signup form on the marketing site (functions/api/signup.js) stores your email address, IP address, user-agent string, and country (derived from Cloudflare's edge, not IP geolocation lookups) in a Cloudflare Workers KV namespace, plus a timestamp. This is used only to invite you to early access and to rate-limit abuse of the form (max 10 submissions/hour/IP). It is not synced to any other system automatically.

1.3 Credentials you store in the vault

AgentBrowser's credential vault (internal/vault, internal/broker) lets you register a username/password/TOTP secret for an agent to use, scoped to an exact origin allowlist. The vault is built so the secret value is never returned to the agent, the API, or your automation's output: it is injected directly into the page over the browser's debugging protocol at fill time, and any value it injects is redacted from later reads (evaluate, snapshot, extract, screenshot text) until it expires. An audit log records that an injection happened — the origin, the decision, and which fields were filled — never the secret value itself (vault.AuditEntry).

Credential material and OIDC/SSO client secrets are encrypted at rest using envelope encryption (see §2). We do not have a documented technical control that prevents someone with full database and master-key access from decrypting a secret if they also had node-level access to the decrypting process — no vendor claim to the contrary should be inferred from this policy.

1.4 Managed identities and SSO/SCIM data

If your workspace uses managed reusable identities (P2-204) or enterprise SSO/SCIM (P2-206): exported browser storage state (cookies/localStorage) associated with a saved identity is persisted encrypted, under the same per-workspace key as vault credentials. OIDC provider configuration (issuer, client ID, client secret) is stored as one opaque encrypted blob per workspace, in a separate namespace from ordinary vault secrets so it can never be listed or requested through the credential-injection API. Domain-ownership claims (for SSO auto-join) and service-account records are stored in plain form — they contain no secret material themselves, only metadata (domain string, verification token, service-account name).

1.5 Browser session recordings and artifacts

A hosted browser session may be recorded: an authoritative event log (WAL) of actions and DOM events, plus artifacts such as screenshots, downloaded files, and screen-capture video (encoded via internal/screencast, CDP screencast frames piped to an mp4 encoder, capped at 768 MB per recording by default). Network request/response bodies captured for a session go through a redaction pass before being written to the recording track (P1-108) so that values you've marked sensitive (e.g. vault-injected credentials) are not captured in the recording even incidentally.

Recordings and other workspace artifacts (downloads, exports) are stored as artifacts (internal/artifacts, cmd/gb-server/artifacts.go) and are subject to the retention, quota, and encryption controls in §2.

1.6 Operational and usage data

To run, secure, and bill the service we record: session metadata (start/end times, duration, instance-hours consumed), API request logs, workspace storage/usage totals used for quota enforcement and cost estimation (cmd/gb-server/cost_budget.go), and webhook delivery records for endpoints you configure (see §4). We do not sell this data, and we do not use it to train third-party models.

1.7 Push notification tokens

If you enable mobile push notifications, we register your device's push token with Apple (APNs, iOS) or Google/Firebase (FCM, Android) to deliver notifications such as vault-approval requests. See §3 (subprocessors) for what each provider receives.

2. How long we keep it, and how it's protected

2.1 Retention

• Artifacts (recordings, downloads, exports): deleted automatically after 90 days by default (ARTIFACT_RETENTION_DAYS, operator-configurable), with a floor of the 5 most recent artifacts per workspace always kept regardless of age (ARTIFACT_RETENTION_MIN_KEEP), so an idle workspace is never silently reduced to nothing. This runs as a scheduled job (cmd/gb-server/artifact_retention_scheduler.go), not a manual process.
• Storage-state / identity data: kept for as long as the identity record exists; deleted when the identity is deleted or the workspace/account is deleted (§2.4).
• Vault credentials: kept until you delete them or the workspace is deleted.
• Operational backups (control-plane database + KMS material, for disaster recovery, not customer-facing download): retained 30 days, minimum 5 backups always kept, sealed with the same key-management service as the vault, stored on the control-plane host. These exist to recover the service after an operational incident, not as a customer data-export mechanism.
• Billing records: retained per Stripe's own retention and any obligations that apply to financial records.
• Signup/waitlist KV records: deleted automatically after 90 days via Cloudflare KV's native expirationTtl (functions/api/signup.js), enforced by the KV store itself at write time rather than a scheduled job. This closes the retention gap only — there is no self-serve export or delete-on-request tooling for waitlist entries specifically (contact us, §8, for a manual request).

2.2 Encryption at rest

Vault credentials, SSO/OIDC configuration, identity storage-state, and (once P1-114 is enabled by an operator) artifact bytes are encrypted using a three-layer envelope scheme (internal/kms, AES-256-GCM throughout):

• A root master key, held as a control-plane/node secret and never stored in the database, wraps a per-workspace key-encryption key (KEK).
• The KEK wraps a per-secret/per-artifact data-encryption key (DEK).
• The DEK encrypts the actual plaintext, bound to an encryption context (workspace ID + resource name) so ciphertext from one workspace cannot be decrypted under another workspace's context even with every key in hand.

Encrypted artifacts are never served through a pre-signed direct-download URL — they are decrypted and streamed through the control plane on every download, specifically so an encrypted artifact can't leak via a bypassable URL.

2.3 Where data physically lives today

Production runs on two DigitalOcean droplets. The control-plane database is self-hosted PostgreSQL running on the control-plane host, not a third-party database service. Artifact bytes are currently stored on the control-plane host's local filesystem — Cloudflare R2 object storage is built and supported but is opt-in and is not configured in production today; if an operator enables it (setting the R2_* environment variables), artifact bytes move to R2 and this document should be updated to reflect that. See the subprocessors list (§3) for exactly what runs where.

2.4 Export and deletion — what works today, and what doesn't yet

Export. A per-workspace data export covers: sessions/recordings metadata, artifact metadata, webhook configuration, identity metadata (never decrypted vault secrets), spend/cost configuration, team/SSO configuration, workflow templates, service accounts, domain claims, and (as of GoodQA #27) full spend-approval history and full workflow-run history.

Deletion. Deleting a workspace/account today cascades across every one of the platform's storage tables — sessions, recordings, artifacts, webhooks, identities, spend policies/approvals, cost budgets, SSO configuration, service accounts, domain claims, workflow templates/runs, and more — not a partial list. It also:

• Cancels the Stripe subscription and confirms Stripe's terminal state before proceeding (not a fire-and-forget call).
• Drains and terminates any live hosted browser sessions fleet-wide.
• Erases the workspace's stored artifact object bytes (filesystem, or R2 if configured, including orphaned/unindexed objects attributable to the workspace) and the index records.
• Waits for any in-flight recording to finish writing before erasing it, rather than deleting out from under an active write.
• Is refused while a workspace is under legal hold (a workspace-wide flag we can set when required to preserve data for a legal process), and skipped by routine retention sweeps while that hold is active.

Legal hold now works at two granularities: a workspace-wide hold (as above), and, separately, a per-item hold on one recording, placed and cleared from that recording's row on the Recordings page. Either one alone is sufficient to protect a recording — placing a per-item hold does not require also holding the whole workspace, and a workspace-wide hold still protects every recording in it regardless of that recording's own flag. A held recording (by either mechanism) is skipped by the retention sweep AND refuses a manual delete (409) until the relevant hold is cleared. Every hold placement or lift, at either granularity, is recorded in a durable, queryable history — who changed it, when, and what it applied to — visible in the Settings page's Legal hold card, so a hold is not just “current status,” it's an auditable record over time.

What is honestly not built yet:

• A workspace's data may still exist in an operational backup until that backup's own retention window expires — backups are not individually purged on a customer deletion request today.
• A known, disclosed, lower-urgency gap: bytes that were previously copied into a reserved quarantine/evidence namespace during startup reconciliation (before they could be attributed to a workspace) are not yet erased by account deletion. These are copies of already-orphaned bytes, not a copy of your live data.

If you need a guarantee beyond what's described above (e.g. for a compliance requirement), contact us (§8) before relying on this policy for that purpose.

3. Subprocessors

See Subprocessors for the current, itemized list of every third party that data actually flows through, with purpose and data category. We do not sell personal information to any third party, and we do not use customer data to train models we distribute to other customers.

4. Data you send to your own configured endpoints (webhooks)

If you configure a webhook URL, AgentBrowser will POST event payloads to it (e.g. session.ended, session.recording_ready, job.completed, vault.approval_requested) — operational metadata about your own workspace's activity, not other customers' data. This is a data flow you control, not a subprocessor relationship: the destination is a URL you provide, and delivery is protected the same way hosted-session network access is — the platform validates the target and refuses to deliver to loopback, private-network, or link-local/metadata addresses (an SSRF guard), so a webhook URL can't be used to make the platform call into your own or another tenant's internal network.

5. Security

We use technical and organizational safeguards described throughout this document (envelope encryption, origin-bound credential injection with redaction, SSRF-safe egress, per-workspace isolation), but no online service can guarantee absolute security. We have not completed and do not claim a SOC 2 audit or an external penetration test as of this writing (both are tracked as separate, not-yet-complete work — LC-304 and LC-305). Avoid placing secrets in prompts, logs, or recorded sessions where the vault's redaction cannot see them (e.g. typing a secret directly instead of through vault injection), use origin-bound vault controls, scope API keys narrowly, and revoke credentials you no longer need.

6. Your choices and rights

You can, today: delete individual artifacts, delete vault credentials and identities, revoke API keys, export your workspace data, and delete your workspace/account (§2.4 for exactly what export and deletion do and don't cover). Contact us (§8) to exercise any of these if you'd rather not do it yourself through the API/console.

If you are located in the EEA, UK, or another jurisdiction with its own data-protection framework, you may have additional region-specific rights (e.g. GDPR/CCPA-style access, correction, or portability rights) beyond what's described above. Contact us (§8) and we'll address the request according to the law that applies to you — a full jurisdiction-by-jurisdiction rights enumeration is not yet published here.

7. Changes to this policy

We'll update the effective date above when this changes. Material changes will be reflected on getagentbrowser.com/legal as well.

8. Contact

Questions about this policy: [email protected].