Sub-processors

Forward-looking. DaemonOps is pre-launch: there is no paid product, no customer, and no connected business tool in production. This document sets out the terms we intend to be bound by. It takes legal effect only on execution of an Order Form that references it. Items marked "not yet established" are facts we have not established and will not assert.

1. What this register is¶

This page is a maintained register, not a narrative. It lists every third party that processes personal data on our behalf in the provision of DaemonOps, together with what each one does, what it receives, where it sits, and — the part most registers omit — whether it is actually in use today.

It serves two purposes at once:

1. It is Annex 3 to the Data Processing Addendum at /legal/dpa, and is incorporated into that Addendum by reference. The commitments in clause 9 of the DPA — general written authorisation, advance notice of changes, a right to object on data-protection grounds, flow-down of obligations, and our continuing liability for our sub-processors — attach to the entries below.
2. It is the mechanism by which a Data Fiduciary can answer a Data Principal's right under the Digital Personal Data Protection Act, 2023, and the Digital Personal Data Protection Rules, 2025 made under it, to know with whom their personal data has been shared. A customer answering that question about data processed through DaemonOps can point to this page and to its change log.

---

2. Status: Daemon AI LLP is pre-launch¶

Read this before reading the tables.

Daemon AI LLP is pre-launch. There is no paid product, there are no customers, and no business tool is connected to DaemonOps in production.

Entries marked Planned below are not in use. No customer data flows through them. They are listed because our published technical specification names them, and because an enterprise reviewer is better served by seeing the intended architecture early than by seeing a short register today and a long one on the day of purchase.

A register that mixes live vendors and planned vendors without labelling which is which is a misrepresentation, whichever direction it errs in. Every row below carries a status, and the status is the most important column.

What is actually running today is a marketing website and a waitlist form. That accounts for the whole of Table 1, and Table 1 is short because the surface is small.

---

3. How to subscribe to change notifications¶

We will give at least 30 days' advance notice before a new or replacement sub-processor begins processing customer personal data, in accordance with clause 9.3 of the Data Processing Addendum. Moving a row in this register from Planned to Live is a change requiring that notice.

To receive notifications:

• Customers — email contact@daemonai.tech with the subject line Subprocessor notifications and the email address that should receive them. We will record it against the account. Notice is sent to that address in addition to being published here.
• Prospective customers and reviewers — the same address works. You do not need to be a customer to be told when this page changes.
• Everyone — the change log in section 11 is the authoritative record of what changed and when. It is dated, and it is what makes the notice obligation in the DPA auditable rather than merely stated.

Customers with a data-protection objection to a new sub-processor should raise it within the notice period. Clause 9.4 of the Data Processing Addendum sets out how objections are handled and what happens if we cannot resolve one.

---

4. How to read the tables¶

Status vocabulary. Every row carries exactly one status:

Region. Where a region is stated, it is what we have verified. Where it is not established, the cell says so in those words. We do not guess at regions, and we do not describe a vendor as "EU-hosted" or "India-hosted" on the strength of a marketing page.

A note on what is absent. There is no analytics vendor in this register, no tag manager, and no advertising or attribution vendor, because the site runs no analytics of any kind and sets no cookies. We verified this across every JavaScript bundle the site serves. The absence is a fact about the product, not an omission from the register.

---

5. Table 1 — Current sub-processors (verified in production)¶

Vercel, AgentMail and Google are the only third parties that receive personal data from us today. The Vercel Speed Insights and Web Analytics row is listed for completeness and receives nothing; section 5.1 explains why it is declared rather than omitted.

5.1 Three disclosures about Table 1¶

There is no database — the storage is a mailbox. Waitlist submissions are not written to a datastore. They are emailed, and they come to rest in a Google Workspace mailbox, where Google stores and backs them up as it does any other mail. That is the whole of the storage arrangement, and it is stated here because "we store your details securely in our systems" would be a more comfortable sentence and a less accurate one. It also means a deletion request for waitlist data is executed by deleting email, and we will do that on request to contact@daemonai.tech. Google's presence in Table 1 follows directly from this: a mail host that receives and retains the submission is a sub-processor of it, and a register that named the sender but not the destination would be wrong.

Speed Insights and Web Analytics are provisioned but have never run. The project carries a speedInsights identifier and a webAnalytics identifier, which is why /_vercel/speed-insights/script.js answers 200 at platform level. The script appears zero times in the served HTML of any page, /_vercel/insights/script.js returns 404, and the project reports no collected data. Neither product has ever collected anything. We state this as the established position rather than leaving it as a caveat, and we have kept the row so that switching either product on is visible here as a change.

AgentMail's jurisdiction is not established, and that has a consequence we will not paper over. We have not established which entity operates AgentMail or in which jurisdiction it processes the submissions it carries. Until we do, we cannot complete the check under section 16 of the DPDPA that no transfer is being made to a country restricted by notification of the Central Government. We are not asserting that AgentMail is US-linked, EU-linked or India-linked, because we do not know. Clause 14 of the Data Processing Addendum qualifies our section 16 statement on precisely this ground.

---

6. Table 2 — Planned sub-processors (not in production)¶

None of the vendors in this table is in use. No personal data reaches any of them. Each row states what it would do if and when it is engaged. Terms, retention, and regions are unverified for every row.

6.1 Composio is the highest-sensitivity entry in this register¶

We are flagging it separately rather than leaving it as one row among six.

Composio, if engaged, would be a custodian of the customer's credentials to its own third-party systems. That is categorically different from a vendor that receives a copy of some data. A vendor holding OAuth tokens for a customer's mailbox and CRM holds the means of access to those systems, and the blast radius of a compromise at that vendor is the customer's mail and CRM, not a subset of records we happened to send it.

Reviewers should treat this entry as the one requiring the deepest diligence, and should expect us to have completed our own diligence — security posture, credential storage and key custody, incident history, regional hosting, and subcontracting — before this row moves to Live. We will not move it without that work, and we will state what we found.

6.2 The database rows are not yet vendor decisions¶

PostgreSQL and SurrealDB are database technologies, not vendors. The rows above are placeholders for whoever hosts them, and that decision has not been made. Because the knowledge-graph host in particular would hold the derived personal data described in Annex 1 of the Data Processing Addendum, the hosting and regional decision for that row is a material one, and we will publish it here as a named vendor before any customer data exists to be affected by it.

---

7. Table 3 — Model providers and gateways¶

Model inference is the processing that AI-vendor reviews examine first. This table separates providers by edition, because the edition determines whether a provider is our sub-processor at all.

Every row in this table is planned and unconfirmed. No model provider is in production use.

7.1 The gateway question, asked explicitly¶

A gateway is itself a sub-processor. If inference is routed through an aggregation layer rather than sent directly to the model provider, that layer receives every prompt and every piece of context on its way through. It is the entry most often missing from vendor registers, because reviewers ask "which model do you use" and vendors answer that question honestly while never being asked what sits in between.

We have therefore given the gateway its own row rather than folding it into the provider rows, and we have named the candidates our technical specification lists. When the decision is made, the row will name one vendor and carry its terms. If we decide to call providers directly, the row will be removed and the change log will record that.

7.2 The training commitment is an intention until verified¶

Our Data Processing Addendum commits that customer content is not used to train, fine-tune or improve foundation models, and commits to flowing that requirement down to each provider we engage.

That commitment cannot be published as verified fact until each provider's actual contractual terms have been read for the specific plan and endpoint we will use. Providers offer materially different postures across tiers, and a statement true of an enterprise API tier can be false of a consumer or preview endpoint. Table 3 therefore marks the posture as an intended commitment pending verification, and each row will state the verified position, with the plan identified, before it moves to Live.

7.3 Edition split, restated¶

The same split applies to connectors: in a self-hosted or BYOM enterprise edition where the customer contracts directly with its own connector providers, those providers are not our sub-processors either.

---

8. Still to be determined¶

These categories are not yet decided. They appear here so that a reviewer can see what is missing rather than infer that nothing is missing. Each will become a row in Table 1 or Table 2 when a vendor is selected, and will attract the notice period in section 3.

---

9. Affiliates¶

Daemon AI LLP has no affiliates, subsidiaries or group companies. No personal data is shared with any affiliated entity, because there is none. If that changes, affiliates will be listed here as a separate table and the change will be recorded in the change log.

---

10. Design rule for this register¶

We state the rule we hold ourselves to, so that it can be checked against the page:

1. No vendor relationship is listed as fact without verification. A vendor named in a technical specification is marked Planned — unconfirmed. A feature that exists on our account but is not executing is marked Provisioned — not running. Only a vendor we have verified in production is marked Live.
2. No row carries a bracketed placeholder. Where a fact is not known, the cell says "Not yet established" in plain words, so that the gap reads as a statement rather than as unfinished drafting. Before this register is published as the operative annex to an executed Data Processing Addendum, every row must in addition be verified — vendor, purpose, data categories, retention, region, and terms — or removed. Rows still reading "Not yet established" are acceptable in a pre-launch review draft and are not acceptable alongside a live product.
3. Absence is stated, not implied. Where we use nothing in a category — analytics, cookies, affiliates — we say so, so that a later addition is visible as a change rather than as a gap being filled.
4. The change log is the record. Every movement between statuses, every addition, and every removal is dated below.

---

11. Change log¶

Future entries will record, for each change: the date, the register version, the vendor affected, the direction of the change (added, removed, or status changed), and the date on which notice was given to customers under section 3.

---

12. Contact¶

Questions about this register, requests to subscribe to change notifications, objections to a new sub-processor, and requests to delete waitlist data all go to the same place:

contact@daemonai.tech

Requests reach Swarochish Chekuri, Designated Partner, who is our grievance and data-protection contact.

Daemon AI LLP, Door No. 16-7-94, First Floor, First Main Road, Dargamitta, Nellore, Nellore District, Andhra Pradesh, India, 524003. LLPIN ACX-5722. Daemon AI LLP is a limited liability partnership; the liability of its partners is limited.

Related documents: the Data Processing Addendum at /legal/dpa, of which this register forms Annex 3, and the Privacy Policy at /legal/privacy.