Privacy Policy

1. Identity of the Data Fiduciary¶

Daemon AI LLP ("Daemon AI", "we", "us", "our") is a Limited Liability Partnership incorporated in India under the Limited Liability Partnership Act, 2008.

Daemon AI LLP is registered with limited liability. This statement is made in compliance with section 21 of the Limited Liability Partnership Act, 2008, which requires every official correspondence and publication of an LLP to carry it.

This document is the notice we are required to give you under section 5 of the Digital Personal Data Protection Act, 2023 (the "DPDPA" or "the Act"). It is a statutory notice and a statement of our actual practices.

It is not a contract. It does not form part of any contract, and it creates no contractual rights or obligations. Where you have or later enter into a separate written agreement with us, that agreement governs the commercial relationship between us; this notice governs how we handle personal data. If the two ever conflict on a matter of data protection, the stricter protection for the individual applies.

Words such as Data Fiduciary, Data Principal, Data Processor, personal data and processing carry the meanings given to them in the DPDPA. In plain terms: you are the Data Principal — the individual the data is about; we are the Data Fiduciary — the entity that decides why and how it is processed.

Language¶

Sections 5(3) and 6(3) of the DPDPA give you the right to be given the option of accessing this notice, and the request for your consent, in English or in any language specified in the Eighth Schedule to the Constitution of India. This notice and the notice presented at the early-access form are published in English. If you would rather have either of them in any Eighth Schedule language, write to contact@daemonai.tech and we will provide it in that language. You do not need to give a reason, and there is no charge.

Status of the law, and why we are complying now¶

The DPDPA commences by notification, and the Digital Personal Data Protection Rules, 2025 phase in over a period rather than all at once. Several of the obligations described in this notice are therefore not yet enforceable against us. We have chosen to comply now rather than wait to be compelled, and we would rather say that plainly than imply a settled regime that does not yet fully exist. Read this document as our statement of the practices we actually follow with effect from the effective date recorded above — binding on us as a matter of practice, whatever the commencement position happens to be on the day you read it. Where a provision commences and changes what is required of us, we will update this notice rather than leave it standing.

---

2. Read this first — which of our three roles applies to you¶

We will, in time, occupy three distinct roles. Only the first is operative today. You should be able to tell within thirty seconds which one concerns you.

If you filled in, or are about to fill in, the early-access form on daemonai.tech, only role (a) applies to you, and sections 3 to 11 and 14 to 21 are the sections you need. Sections 12 and 13 are written for counsel and for prospective customers reviewing our intended position in advance.

---

3. What we collect today, and why¶

DaemonOps has not launched. There is no paid product, no customer account, no login, no connected business tool in production, and no customer data of any kind in our systems.

The only personal data we collect today is what you type into the early-access form.

We do not ask you for your name, telephone number, company name, postal address, job title, payment details, or any government identifier. If you volunteer any of these inside the free-text field they will be carried along with the rest of the submission — please do not put anything there that you would not want sitting in an email inbox.

We do not knowingly collect any special category of data, nor any "sensitive personal data or information" as defined in the SPDI Rules, 2011 (passwords, financial information, health data, biometrics and the like). If you send us such data unprompted, we will delete it rather than retain it.

This site sets no cookies and runs no analytics. See the Cookie Policy for the verified position and how we checked it.

<!-- GDPR: Art 13/14 transparency mapping and the Art 6 lawful-basis table would go here if EU data comes into scope -->

---

4. How the early-access form actually works¶

We describe the mechanism because it materially affects what "erasure" means and who else touches your data.

1. You type a work email address, select one of four roles, and optionally answer the free-text prompt.
2. You read the itemised notice rendered beside the form and tick the mandatory consent box, which is not pre-ticked. The form will not submit without it. A second box, for product updates, is optional and separate.
3. Your browser sends the submission over HTTPS to an API route on daemonai.tech.
4. That route rejects any submission that does not carry the mandatory consent — the check is enforced on the server, not only in the browser. It then checks the email address against a format pattern, and truncates the role to 120 characters and the free-text answer to 2,000 characters.
5. It attaches the consent record: the notice version, an ISO-8601 timestamp, both consent booleans, and the verbatim consent statement you were shown.
6. It then calls the AgentMail REST API at https://api.agentmail.to, from the inbox swarochish-1106@agentmail.to, to send the submission as a plain email to an operator mailbox at swarochish@daemonai.tech. That mailbox is operated by Google LLC (Google Workspace), which therefore receives and stores the whole of it (see section 17).
7. Nothing else happens. There is no database. Your submission is not written to any store we operate. It exists as an email in an operator's inbox, and in whatever transmission and backup copies the mail systems involved create in the ordinary course.

This is a deliberately small design for a pre-launch site, and we would rather describe it accurately than dress it up. It has one consequence you should know about: because the record is an email, honouring an erasure request means deleting the message and any copies held by the mail providers involved, and we are dependent on those providers' own deletion behaviour for the last of it (see section 16).

---

5. Lawful basis — and why "legitimate interests" does not exist in Indian law¶

Under the DPDPA, personal data may lawfully be processed only:

• with the consent of the Data Principal under section 6; or
• for certain legitimate uses under section 7, which is a closed and specific list.

The DPDPA contains no "legitimate interests" ground. There is no balancing test under which an organisation may process your personal data because it considers its own interest to outweigh your privacy. This is the single most frequently mistranslated point when a GDPR-derived privacy template is applied to India, and it is why a template that says "we rely on our legitimate interests to run analytics" is simply wrong as a matter of Indian law. It is also why any analytics or tracking we introduce in future must be consent-gated before it loads — there is no other ground available to us for it.

Section 7 "certain legitimate uses" is not an equivalent of legitimate interests. It is an enumerated list — for instance, the specified purpose for which the Data Principal has voluntarily provided their personal data and in respect of which they have not indicated an objection (section 7(a)), performance of certain State functions, compliance with law or a court order, medical emergency, employment purposes, and similar defined situations.

Our position on the waitlist. On the facts, section 7(a) would very likely cover the early-access form: you voluntarily give us an email address for the specified purpose of being contacted about early access. We nonetheless treat the waitlist as processed on consent under section 6, and we do so deliberately: consent gives you a clean, unambiguous right to withdraw at any time, and it puts the burden of proof on us rather than on you. We do not want to be in the position of arguing that you cannot withdraw because we never asked for consent in the first place.

Request metadata, and why we do not claim a ground for it. The IP address, user agent and URL that our hosting provider handles in order to serve you a page are an unavoidable technical incident of delivering content you asked for. We do not assert that this processing rests on necessity, on contract, or on any other ground, because the DPDPA contains no such ground. Section 4 admits consent under section 6 or an enumerated legitimate use under section 7, and nothing else. A notice that invents a third ground for its server logs is making the same mistake it warns you about two paragraphs above.

Our position instead is this: request metadata handled transiently by our host, which we never receive, never retain, never combine with your submission, and never use to identify anyone, is not personal data in our hands within the meaning of sections 2 and 3(a) of the Act. We state that as our position rather than as settled law, because it is a position and you are entitled to know that we are taking one. It is also why we do not receive an analytics feed derived from those logs, and why the Cookie Policy can say that no analytics runs on this site at all. Were we ever to receive, retain or use that metadata ourselves, the position would change and we would have to obtain consent for it — which is precisely why we do not.

---

6. Consent, and how to withdraw it¶

How we obtain consent¶

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the specified purpose. Our practice:

• The itemised notice is rendered at the form itself, in an expandable block beside the fields, not merely linked from a footer. It sets out six things in plain language: what we collect, why we collect it, how it is handled and who else touches it, how to withdraw, what your rights are, and the route to complain to the Data Protection Board of India. The full text is reproduced at Annex A.
• A mandatory, unticked checkbox gates submission. The form cannot be submitted until you tick it, and it reads: "I am 18 or over, and I agree that Daemon AI LLP may use my email address and the details I provide to contact me about DaemonOps early access." It is followed by a link to this Privacy Policy. Ticking that box is the clear affirmative action — not the act of pressing submit.
• Consent is not bundled. Product updates are a separate, optional, unticked checkbox. You can give us consent to contact you about early access without agreeing to marketing, and access to this site does not depend on giving either.
• Nothing is pre-ticked, and there is nothing to opt out of after the fact.
• The requirement is enforced on the server as well as in the browser. A submission that arrives without the mandatory consent is rejected, so disabling client-side validation does not get around it.
• We ask only for what the stated purpose requires, which is why the form has three fields and not fifteen.

How to withdraw it¶

Withdrawal must be as easy as giving consent, and here it is. Send an email to contact@daemonai.tech saying "withdraw". You do not need to give a reason, complete a form, create an account, or quote a reference number. We will acknowledge within 2 working days and complete the deletion within 15 days.

On withdrawal we delete the submission record and stop processing. The consequence is that we will not be able to contact you about early access — that is the whole of what you lose. Withdrawal does not affect the lawfulness of anything we did while consent was in force, and it does not affect processing carried out on another lawful ground where one applies.

The burden of proof is ours¶

Under the Act, the burden of proving that notice was given and that valid consent was obtained lies on the Data Fiduciary — on us, not on you. We have therefore built a consent record rather than relying on the submission alone. Every submission carries, alongside your answers:

• the version of the consent notice that was on screen when you submitted (currently version 1.0);
• an ISO-8601 timestamp of the consent event;
• both consent booleans — the mandatory one, and the separate optional one for product updates; and
• the verbatim text of the consent statement you were actually shown, stored word for word rather than described.

That last item matters most. It means we do not have to reconstruct from version control what the page probably said on the day you submitted; we hold the exact sentence you agreed to. The source of this website and of the Annex A notice is additionally held in version control, so the surrounding wording published on any given date can also be reproduced.

---

7. Your rights as a Data Principal¶

Nomination, in practice. Because there is no database (see section 4), a nomination cannot be "recorded against" a row. What actually happens is this: your nomination arrives as a further email into the same operator mailbox that holds your original submission, and the two are associated by your email address — the only identifier we hold. If your nominee later contacts us, we look for a submission and a nomination sent from the same address. We are telling you the mechanism rather than implying a register we do not operate, because it has a consequence you should weigh: if you later withdraw consent and we delete the submission, the nomination goes with it.

Verification. We will ask for enough information to be reasonably satisfied that you are the person who made the submission — for a waitlist entry, confirmation from the same email address is normally sufficient. We will not ask you for identity documents to action a request about a mailing list entry, and you should refuse if anyone does.

Cost and time. There is no fee. We acknowledge within 2 working days and answer substantively within 15 days. If a request is genuinely complex we will say so within those 15 days, explain why, and give you a date.

Limits. We may decline a request that is not yours to make, or where complying would require us to disclose another person's personal data, or where retention is required by law. If we decline, we will tell you why and tell you how to escalate.

---

8. Your duties as a Data Principal (section 15)¶

The DPDPA is unusual among data protection statutes in imposing duties on the individual as well as on the organisation. We set them out because the Act intends them to be known, and because their absence is a reliable sign that a policy was copied from a European template. Under section 15, a Data Principal shall:

• comply with the provisions of all applicable law while exercising rights under the Act;
• not impersonate another person while providing personal data for a specified purpose;
• not suppress any material information while providing personal data for any document, unique identifier, proof of identity or proof of address issued by the State or its instrumentalities;
• not register a false or frivolous grievance or complaint with a Data Fiduciary or with the Data Protection Board of India; and
• furnish only such information as is verifiably authentic while exercising the right to correction or erasure.

Breach of these duties may attract a penalty imposed by the Data Protection Board. We say this for completeness and not to discourage you: we would far rather receive a complaint we can fix than have a problem go unreported.

---

9. Consent Managers¶

The DPDPA contemplates Consent Managers — entities registered with the Data Protection Board of India through which a Data Principal may give, manage, review and withdraw consent through an accessible, transparent and interoperable platform.

We are not a Consent Manager. We are not registered as one. We are not currently integrated with one. If we integrate with a registered Consent Manager in future, we will name it on this page before the integration goes live.

For the avoidance of doubt, and because the claim appears in circulation: there is no registration regime for Data Fiduciaries under the DPDPA. We are not "registered with the Data Protection Board of India", because no such registration exists for an entity in our position. Registration under the Act applies to Consent Managers.

---

10. Grievance redressal, and escalation to the Board¶

Our Grievance Officer¶

We maintain one contact address for everything. There is no separate privacy@ or grievance@ address, and we would rather tell you that than publish addresses nobody monitors.

Service levels¶

• Acknowledgement within 2 working days of receipt.
• Substantive resolution within 15 days of receipt.
• If we cannot resolve a grievance within 15 days, we will tell you within that period why, what remains outstanding, and by what date we expect to close it.

Please include: the email address you used, what happened, what you would like us to do, and any reference from earlier correspondence. Plain language is fine; you do not need to cite the Act.

Escalation¶

If you are not satisfied with our response, or if we fail to respond within the period above, you may complain to the Data Protection Board of India. Section 13 requires you to exhaust our grievance mechanism first, which is why we have committed to a defined and short timetable rather than an open-ended one. We will not treat a complaint to the Board as a reason to stop dealing with you, and nothing in this notice limits any remedy otherwise available to you before a forum of competent jurisdiction.

---

11. Children, and persons with disabilities¶

Under the DPDPA a child is an individual who has not completed eighteen years of age. This is stricter than the GDPR position and stricter than most non-Indian frameworks, and a policy written for another jurisdiction will almost always get it wrong.

• daemonai.tech is a business-to-business site about operations software. It is not directed at children, is not attractive to them, and carries no content aimed at them.
• The early-access form is for adults acting in a professional capacity, and the 18+ confirmation is obtained at the form itself. The mandatory checkbox that gates submission opens with the words "I am 18 or over" — it is not buried in a linked policy, and the form cannot be submitted without it. The confirmation is recorded with the submission, in the verbatim terms shown on screen (see section 6).
• Section 9(1) requires verifiable consent of a parent or lawful guardian before processing the personal data of a child, or of a person with disability who has a lawful guardian. We do not knowingly process either.
• Section 9(3) is a prohibition, not a consent-based restriction. A Data Fiduciary must not undertake tracking or behavioural monitoring of children, and must not direct targeted advertising at children. Parental consent does not cure it — this is the point most often got wrong, because in a consent-based statute the instinct is to assume that a permission exists which would make the conduct lawful. Here none does.
• It is not, however, absolute, and we will not describe it as though it were. Section 9(4) empowers the Central Government to exempt, by notification, prescribed classes of Data Fiduciary and prescribed purposes from the operation of section 9(1) and section 9(3); section 9(5) provides a further power to exempt a Data Fiduciary from section 9(1) where processing of a child's personal data is carried on in a manner that is verifiably safe, and to specify a lower age from which the Act then applies as if the individual were not a child. So there are carve-outs, and a notice that calls the prohibition absolute is overstating the law in its own favour. None of them is relevant to us, because we do none of these things — not for children, not for anyone.

If you believe a person under 18 has submitted the form, write to contact@daemonai.tech and we will delete the entry.

---

12. When DaemonOps launches — our future role as a Data Processor¶

Nothing in this section is operative today. No customer account exists, no business tool is connected, no OAuth grant has been made to us, and no Customer Content is being processed by us. This section is written in the future conditional so that counsel and prospective customers can review the position we intend to occupy before it becomes live, and so that nobody reading this page mistakes an intention for a fact.

What DaemonOps will do¶

DaemonOps is designed as an AI operations layer running a Sense → Decide → Act → See loop. Its defining characteristic is that the AI acts as the user: it executes actions inside the customer's own third-party business tools, using the credentials and OAuth scopes the customer grants, under that user's own role and permissions, with an audit trail of what was done and on whose behalf. It is not a separate super-user with its own standing access.

The Sense step will ingest data from connected applications — mailbox, calendar, CRM — and build a per-user knowledge graph from what it finds.

The role that follows from that design¶

In that arrangement, the customer is the Data Fiduciary for the personal data inside its connected tools. It decides why and how that data is processed. Daemon AI LLP will be the Data Processor, acting only on the customer's documented instructions under a written contract.

A note on section 8(2), which is routinely misdescribed. Section 8(2) does not say that a processor must process "on documented instructions" — that phrasing is imported from the GDPR. What it says is that a Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf only under a valid contract. It is therefore an obligation on the Data Fiduciary — on the future customer — and not on us as processor. The practical consequence is worth stating plainly: a Data Processor's obligations under the DPDPA are largely contractual rather than statutory. What binds us in that role will be what the contract says, which is why the contract matters more here than it would under a statute that imposes direct processor duties, and why we set out below what we intend to be bound to.

What that contract will commit us to, in outline:

• processing only on the customer's documented instructions, and for no purpose of our own;
• scope confined to the OAuth scopes and permissions the customer actually grants, and no wider;
• reasonable security safeguards appropriate to the data and the risk;
• assistance to the customer in meeting Data Principal requests made to it;
• disclosure of every sub-processor, and advance notice before any change;
• notification to the customer of a personal data breach without undue delay, so that the customer can meet its own obligation to intimate the Board and affected Data Principals; and
• deletion or return of Customer Content on termination.

<!-- GDPR: Art 28(3) processor obligations, Art 32 security measures and Art 33 processor breach timelines would go here if EU data comes into scope -->

Service Data — where we would be an independent Data Fiduciary¶

Separately from Customer Content, we would process a narrow set of Service Data in our own right and as an independent Data Fiduciary: security and access logs, audit records of actions the system took and under whose authority, and aggregated, de-identified usage statistics. We would use it to operate and secure the service, to investigate incidents, to improve the product, and to meet our own legal obligations.

Service Data would not include the contents of a customer's mailbox, calendar, CRM records or documents. The boundary between the two will be set out in the customer agreement, because "aggregated usage data" is exactly the phrase under which scope quietly expands.

---

13. Automated decision-making, and how we use AI¶

Today: none. The early-access form involves no automated decision-making, no profiling, no scoring, and no ranking. A person reads the email.

On launch, DaemonOps is by design a system that decides and acts. Decisions will be taken within the scope the customer grants, executed under the acting user's own permissions, and recorded in an audit trail. Actions that are irreversible or high-impact are designed to pause for human review rather than proceed autonomously.

Model training. We do not use Customer Content to train foundation models. We record this as a commitment we intend to hold ourselves — and our model providers — to. Every model provider that processes Customer Content will be named on the sub-processor page before it does so.

---

14. Security¶

Section 8(5) of the DPDPA requires a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. Alongside the DPDPA, the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, made under section 43A of the Information Technology Act, 2000, remain operative. Rule 8 of those Rules recognises that an organisation may demonstrate reasonable security practices through a documented, comprehensive information security programme and policies containing managerial, technical, operational and physical controls commensurate with the information assets being protected. It names an international standard as one route to that; we make no claim to hold that or any other certification, and we are not audited.

The SPDI Rules are transitional, and we would rather say so than present them as a settled steady state. Section 44 of the DPDPA omits section 43A of the Information Technology Act, 2000 on commencement — and section 43A is the parent power under which the SPDI Rules, 2011 were made. The Rules therefore remain in force only until section 44 commences. Until then we treat them as applicable to us and describe our practices accordingly. When section 44 commences we will restate this section rather than leave it citing a rule-making power that has been removed.

What we actually do today¶

• The site is served over HTTPS. Your form submission is encrypted in transit.
• The AgentMail API credential is held as an environment variable in the hosting platform. It is not committed to the source repository.
• Input from the form is validated for email format and truncated (role to 120 characters, free text to 2,000) before use.
• The submission is delivered to a single operator mailbox. Swarochish Chekuri, Designated Partner, is the only person with access. Nobody else in or outside the LLP holds credentials for it.
• The controls we can state on that mailbox are the account protections provided by Google Workspace, and TLS for mail in transit. We are not yet in a position to state that two-factor authentication is enforced on the account — that is a control to be confirmed, and we would rather record it as unconfirmed than assert it. We will state the position here once it is confirmed.
• The daemonai.tech mailbox is operated by Google LLC (Google Workspace), which is therefore itself a processor of your submission. It is named in section 17 and on the sub-processor page.

What we do not claim¶

We do not claim to hold SOC 2, ISO 27001 or any other certification. We do not claim to have been independently audited. We do not describe our security as "bank-grade", "military-grade" or "unbreakable", because those phrases mean nothing and are usually a substitute for saying what is actually in place. We do not guarantee that any system is impenetrable. Security is a set of measures proportionate to the data and the risk, reviewed as both change — and at present the data is a small volume of business email addresses and free text, held in an inbox.

---

15. Personal data breach — the three clocks¶

If a personal data breach occurs, more than one obligation runs at once, on different timetables, to different recipients. They are cumulative: satisfying one does not discharge another.

Our point of contact for CERT-In purposes is Swarochish Chekuri, Designated Partner, reachable at contact@daemonai.tech. The 28 April 2022 directions do not merely require that such a person be designated internally: the point of contact's details must be filed with CERT-In, and kept current, so that CERT-In can reach a named human when an incident is reported. That is an active obligation on us and we record it here as one rather than treating designation alone as compliance.

If a breach affects your submission, we will tell you what happened, what data was involved, what we have done, and what if anything you should do.

---

16. Retention and erasure¶

Section 8(7) of the DPDPA requires a Data Fiduciary to erase personal data when the Data Principal withdraws consent, or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier, unless retention is necessary for compliance with any law.

Our retention periods are these:

Because the submission record is an email rather than a database row, erasure means deleting the message from the operator mailbox and from any sent-items or transmission copies held by the mail systems involved.

What we cannot promise about backups. The daemonai.tech mailbox is operated by Google LLC (Google Workspace), and Google retains backup copies on its own schedule, which we do not control and cannot override. The same is true of transmission copies held by AgentMail. So while we can tell you that we will delete the message from the mailbox, and when, we cannot tell you the date on which the last backup copy of a withdrawn submission disappears — because that date is not ours to know. We would rather state that limitation than offer you a deletion guarantee that ends at the edge of our own systems and quietly stops there.

---

17. Sharing, and our sub-processors¶

We do not sell personal data. We do not share it for advertising. We do not use data brokers. We run no advertising on this site and no advertising technology on it.

Section 11(1) gives you the right to know the identity of every Data Fiduciary and Data Processor with whom your personal data has been shared, and a description of what was shared. Three processors are engaged today, and they are engaged because the site cannot function without them:

We name Google explicitly because it would be easy not to. A mail provider is the processor people forget to disclose: nobody "sends data to Google", the message simply arrives, and the disclosure gets omitted by inattention rather than by design. But the destination mailbox is where your submission actually lives, which makes Google the processor holding it for longest.

The current list is maintained at /legal/subprocessors. If we add or replace a sub-processor, we will update that page and this notice.

Disclosure required by law. We may disclose personal data where we are required to by law — for instance to a court, or to a statutory or regulatory authority acting within its powers. We will not do so voluntarily. We will require the demand in writing, satisfy ourselves that it is lawful and within the requesting body's powers, disclose only what is actually demanded, and tell you unless we are prohibited from doing so.

<!-- CCPA/CPRA: a notice at collection, a Do Not Sell or Share My Personal Information mechanism, and the sensitive-personal-information limitation would go here if California residents come into scope -->

---

18. Transfer of personal data outside India¶

Section 16 of the DPDPA operates on a negative list. Transfer of personal data outside India is permitted, except to a country or territory that the Central Government restricts by notification. It is not an adequacy regime and it is not an authorisation regime — there is no approval to apply for, and no list of blessed destinations. Where a sectoral law imposes a stricter localisation requirement on a particular kind of data, that stricter requirement prevails over section 16.

We do not claim that your data never leaves India, and you should treat any Indian privacy notice that makes that claim while naming American vendors with suspicion. Vercel is a United States company. Google LLC is a United States company. AgentMail is a United States-linked service. Serving this site through a Mumbai edge location is a latency arrangement; it is not a data-residency guarantee, and we will not present it as one.

As at the effective date of this notice, no restriction notification issued under section 16 has been identified as applying to any of the processors named in section 17. We check this at each update of this notice, and we will name any restriction that comes to apply to a processor we use, together with what we have done about it.

---

19. Significant Data Fiduciary status¶

Section 10 of the DPDPA empowers the Central Government to notify any Data Fiduciary, or class of Data Fiduciaries, as a Significant Data Fiduciary, having regard to the volume and sensitivity of personal data processed, the risk to the rights of Data Principals, the potential impact on the sovereignty and integrity of India, the risk to electoral democracy, the security of the State, and public order.

That status is conferred by notification. It is not self-declared, and it cannot be applied for. Daemon AI LLP has not been notified as a Significant Data Fiduciary.

If we were so notified, we would be required to, and would:

• appoint a Data Protection Officer based in India, being an individual responsible to the board of directors or similar governing body of the Data Fiduciary — in the case of an LLP, answerable to the designated partners — who would be the point of contact for the grievance redressal mechanism under the Act;
• appoint an independent data auditor to carry out data audits and evaluate our compliance with the Act;
• undertake periodic Data Protection Impact Assessments. Section 10(2)(c)(i) of the Act says only "periodic" and fixes no interval; the annual cadence comes from the Digital Personal Data Protection Rules, 2025, not from the Act itself, and we attribute it there rather than putting words into the statute;
• undertake periodic audits; and
• undertake such other measures as prescribed, including algorithmic due diligence — verifying that the algorithmic software we use for processing personal data does not pose a risk to the rights of Data Principals. Given the nature of DaemonOps, this obligation would be a substantial one for us, and we would expect to describe our approach to it publicly.

We would state the fact of notification on this page. Until we do, you should read this section as describing a contingency and not a current programme.

---

20. Changes to this notice¶

This is version 1.0, with effect from 8 September 2026.

We will update this notice when our processing changes — and, in particular, before any change takes effect, not after it. Where a change materially affects the basis on which we hold personal data you have already given us, we will seek fresh consent rather than assume that your earlier consent extends to the new purpose. The source of this page is held in version control, so the wording in force on any given date can be reproduced.

The version, effective date and last-updated date are recorded at the top of this document.

---

21. How to contact us¶

We use one address deliberately. We do not maintain separate privacy@, grievance@ or dpo@ addresses, and we would rather say so than publish addresses that nobody reads.

---

Annex A — Itemised notice presented with the early-access form¶

Section 5 of the DPDPA requires the itemised notice to accompany the request for consent. A link in the page footer does not satisfy it. The text below is what is rendered at the form itself, in an expandable block beside the fields. This is consent notice version 1.0, and that version number is recorded with every submission.

Before you submit this form¶

Who is asking. Daemon AI LLP (LLPIN ACX-5722), a Limited Liability Partnership registered with limited liability, of Door No. 16-7-94, First Floor, First Main Road, Dargamitta, Nellore, Andhra Pradesh 524003, India, is the Data Fiduciary for what you enter here.

What we collect. (i) your work email address; (ii) the role you select; (iii) your free-text answer about the one painful process, or dashboard, you cannot get today — the first 2,000 characters of it.

Why. To reply to you, and to invite you to the DaemonOps private beta when it opens. Nothing else. We do not sell it, share it for advertising, or add you to a marketing list you did not ask for.

Where it goes. Your submission is sent as an email, via AgentMail, to an operator mailbox at daemonai.tech, which is operated by Google LLC (Google Workspace) — so Google receives and stores the whole of it. There is no database and no account. Our host, Vercel, handles the request metadata needed to serve you this page. All three are United States-linked; we do not claim your data stays in India.

Your consent. You give it by ticking the box below, which is not pre-ticked and which the form will not submit without. That tick is your consent under section 6 of the Digital Personal Data Protection Act, 2023. Product updates are a separate, optional box — you can leave it unticked and still ask for early access. Nothing on this site is withheld if you give neither.

What we record. Along with your answers we store the version of this notice, the time you consented, both tick-boxes, and the exact wording of the consent statement you were shown. That record exists because the law puts the burden of proving consent on us, not on you.

Withdrawing is as easy as giving. Email contact@daemonai.tech and say "withdraw". No reason, no form, no account. We acknowledge within 2 working days and complete within 15 days.

Your rights. Get a summary of the data we hold, what we did with it, and who we shared it with (s.11); correct, complete, update or erase it (s.12); nominate someone to exercise these rights if you die or become incapable of exercising them yourself (s.14); and raise a grievance with our Grievance Officer at contact@daemonai.tech (s.13), and thereafter with the Data Protection Board of India.

Adults only. The box you tick begins "I am 18 or over". This form is for adults acting in a professional capacity.

In your language. You may have this notice and this consent request in English or in any language listed in the Eighth Schedule to the Constitution of India. Ask at contact@daemonai.tech — no reason needed, no charge.

This site sets no cookies and runs no analytics. Full detail: Privacy Policy · Cookie Policy