Subprocessor List
Version 2026-11-02.1 · Effective November 2, 2026
Providers that may handle account, billing, repository, or workspace data.
Core and conditional providers
The exact provider set depends on deployment and customer configuration. A provider receives only the categories needed for its role.
- Paddle — merchant-of-record checkout, customer sales taxes, receipts, subscriptions, refunds, and related billing identifiers when Paddle is selected. Paddle also acts as an independent controller for its own payment and legal obligations; it does not receive repository/workspace content for subscription billing.
- Stripe — legacy subscription billing where configured, and the separate agent-card integration when selected; receives the account and payment information required for those functions, not repository/workspace content for subscription billing.
- OpenAI and Anthropic — prompts, selected repository/workspace context, attachments, and outputs when their model or connected subscription is selected. BYOK uses the customer’s provider account; managed usage uses the operator’s account.
- E2B, Daytona, Fly.io, Hetzner Cloud, Amazon Web Services (AWS) or Google Cloud — isolated compute (on Fly.io, Hetzner, AWS and Google Cloud, a virtual machine and its disk volume in the region the organization or operator chose), repository checkout, workspace files, environment variables made available to the world, command traffic, and resulting artifacts when that cloud world provider is selected. An organization’s own provider account is used when it connects one; otherwise tasks run on the operator’s account (managed compute), where available.
- one.com — VPS hosting and server backups where used by the operator. This can include application databases and encrypted vault material, plus, until it is removed in November 2026, the copy of stored objects made before they moved to Cloudflare R2. A core-hosting location is not a location guarantee for model calls, sandboxes or integrations.
- Cloudflare (R2, Email Routing) — managed object storage in R2’s EU jurisdiction, which keeps stored objects in EU data centres: world checkpoints and project resource data (encrypted by tavya before upload), review attachments and conversation exports; and, in a separate bucket, encrypted backups of tavya’s databases (encrypted before upload; kept 31 days); and, for agent mailboxes, inbound email routing that delivers messages to tavya without storing them. Deleted objects are kept up to 30 days so backups stay restorable. Data an organization places in a storage bucket it connects itself goes to that bucket instead.
- Cloudflare (Workers) — carries resource saves and reads between task sandboxes and the organization’s storage (managed R2, or a bucket it connects), so they need not pass through tavya’s servers. The data is encrypted before it leaves the sandbox, passes through the Cloudflare location nearest the sandbox (which may be outside the EU), and is not stored there.
- Resend — transactional account, verification, security and support-notification email where configured; receives recipient addresses and message contents, not unrestricted repository access.
- Composio — managed connection brokerage where configured; may handle connection credentials and tool requests/results. A broker engaged by the operator is distinct from the customer-selected destination service.
- Configured database, object-storage, hosting, email, monitoring, and support providers — account records, service metadata, stored objects, transactional messages, diagnostics, or support content as needed for their function.
- Customer-selected repository hosts and integrations (for example GitHub) — data the customer directs tavya to read or write under the customer’s connection. These may be independent services as well as processors acting on the customer’s instructions.
Roles, locations and changes
This list includes conditional providers and independent services, not a claim that every named company is a subprocessor for every customer. Providers engaged by the operator to process customer personal data are subject to the DPA; independently selected destinations and payment providers may have different roles. Neither BYOK nor customer selection alone determines the legal role.
The operator must supply the current applicable subprocessor identities, functions and processing-country information before processing under the DPA. A provider offering a choice of regions does not establish which region is in use. Ask the DPA contact for the deployment-specific record; unknown locations must not be represented as verified.
The operator will notify affected customers before adding or replacing a subprocessor and allow a reasonable opportunity to object on data-protection grounds before the change, as described in the DPA. Publishing an updated list alone does not replace a required notification.