Data Processing Addendum

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. About this Addendum¶

1.1 This document is forward-looking¶

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. Nothing in this Addendum should be read as a description of an operating service handling live customer data today.

This Addendum is published for one reason: enterprise buyers, and the security and privacy reviewers who advise them, should be able to read our data-protection terms before they talk to us rather than after. It sets out the commitments we intend to be held to, in the form in which we intend to be held to them.

It takes legal effect only when a Customer executes an Order Form that references it. Until then it is a published draft. Where a fact has not been established, this Addendum says so in those words rather than asserting it or leaving a blank. The closing section, "What remains to be established", collects every such item in a single list.

1.2 The parties¶

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

As required by section 21 of the Limited Liability Partnership Act, 2008, we state that Daemon AI LLP is a limited liability partnership and that the liability of its partners is limited.

"Customer" means the legal entity identified on the Order Form. Together the Customer and Daemon AI LLP are the "parties" and each is a "party".

1.3 Incorporation and version-pinning¶

This Addendum forms part of the agreement between the parties comprising the Order Form, the Terms of Service (the "Terms"), and this Addendum (together, the "Agreement"). It is incorporated by reference into the Order Form.

We version this Addendum and publish each version at /legal/dpa. The version in effect on the date the Customer executes its Order Form governs that Customer, and continues to govern it unless and until it is updated in accordance with clause 18.2. A later version published on our website does not silently replace the version the Customer signed.

The current version is stated in the document header, along with its effective date and the date it was last updated.

1.4 This Addendum prevails on data protection¶

Where this Addendum conflicts with the Terms or any other part of the Agreement on the subject matter of data protection, privacy, information security, personal data breach handling, or sub-processing, this Addendum prevails. On every other subject, the Terms prevail. Where the Order Form expressly and specifically varies a clause of this Addendum, and identifies the clause it varies, the Order Form prevails for that Customer.

1.5 How this Addendum is executed¶

No separate signature is required. Executing an Order Form that references this Addendum incorporates it in full. Where a Customer's own procurement process requires a counter-signed standalone document, we will sign one on request; the signed document will reproduce this Addendum without alteration unless the parties expressly negotiate otherwise.

---

2. Definitions¶

Terms defined in the Terms have the same meaning here. This section adds only the definitions this Addendum needs.

Agent Action — an operation performed by the Service inside a Connected Application on behalf of an Acting User, including reads and writes.

Acting User — the natural person, authenticated through the Customer's identity provider, under whose identity, role and granted OAuth scopes a given Agent Action executes.

Applicable Data Protection Law — the Digital Personal Data Protection Act, 2023 ("DPDPA") and the rules made under it, including the Digital Personal Data Protection Rules, 2025 (the "DPDP Rules"); the Information Technology Act, 2000, including section 43A and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (the "SPDI Rules"), subject to the transitional note below; the directions issued by the Indian Computer Emergency Response Team under section 70B(6) of the Information Technology Act, 2000 dated 28 April 2022 (the "CERT-In Directions"); and any other law applicable to a party's processing of Customer Personal Data.

Much of the operative detail of the DPDPA sits in the DPDP Rules rather than in the Act: the content of the notice a Data Fiduciary must give, the form and manner of breach intimation, the period within which a grievance must be answered, the manner in which a Data Principal may nominate another person, and the additional obligations of a Significant Data Fiduciary. Where this Addendum refers to an obligation under the DPDPA, the reference includes the corresponding detail prescribed by the DPDP Rules.

A transitional note on section 43A and the SPDI Rules. Section 44 of the DPDPA omits section 43A of the Information Technology Act, 2000 on commencement of that provision. Section 43A is the parent power under which the SPDI Rules were made. Until section 44 commences, section 43A and the SPDI Rules remain in force and we treat ourselves as bound by them; on commencement we will restate this definition, and clause 8.1, to reflect the position that then applies. We flag this rather than citing the SPDI Rules as though the question were settled.

Connected Application — a third-party service that the Customer or an Acting User authorises the Service to access, such as a mailbox, calendar, or CRM. Annex 5 governs these.

Customer Content — data, documents, messages, files and records that the Customer or its Users submit to the Service, or that the Service reads from a Connected Application on the Customer's behalf, together with material derived from that data by the Service, including the personal knowledge graph.

Customer Personal Data — personal data contained in Customer Content, or otherwise processed by us on the Customer's behalf under the Agreement.

Data Fiduciary, Data Processor, Data Principal, personal data and processing have the meanings given in the DPDPA. Where a Customer's own applicable law uses the terms "controller" and "processor", those terms correspond to "Data Fiduciary" and "Data Processor" respectively as used in this Addendum, and this Addendum is to be read accordingly.

Data Protection Board — the Data Protection Board of India constituted under the DPDPA.

Personal Data Breach — any unauthorised processing of Customer Personal Data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to Customer Personal Data, that compromises the confidentiality, integrity or availability of that data.

This definition deliberately tracks the DPDPA rather than the narrower formulation used in many processor addenda, which is drafted on the model of Article 4(12) of the EU General Data Protection Regulation and is confined to a breach of security leading to destruction, loss, alteration or unauthorised disclosure or access. The DPDPA definition is wider in two respects that matter to a Customer: it reaches any unauthorised processing, whether or not security was breached to achieve it, and it reaches loss of access, meaning availability events as well as confidentiality events.

The narrower drafting creates a trap for the Data Fiduciary. An event can be a personal data breach under the Act — triggering the Customer's duty under section 8(6) to give intimation to the Data Protection Board and to each affected Data Principal — while falling outside a contractual definition built on the Article 4(12) model. The Customer would then owe a statutory duty it had not been told it was under, because its processor's contract did not require us to tell it. We would rather carry the wider definition than hand a Customer that problem.

A Personal Data Breach does not include an unsuccessful attempt that does not compromise the confidentiality, integrity or availability of Customer Personal Data, or a routine event such as a blocked login, a rejected request at the input security gate, or a port scan.

Service — DaemonOps, in the edition identified on the Order Form.

Service Data — the categories of data described in clause 3.2, and no others. Clause 3.2 also states, category by category, whether we process that category as a Data Processor or as an independent Data Fiduciary.

Sub-processor — a third party engaged by us that processes Customer Personal Data in the course of providing the Service.

User — a natural person authorised by the Customer to use the Service.

---

3. Roles of the parties¶

3.1 Customer as Data Fiduciary, Daemon AI LLP as Data Processor¶

In relation to Customer Personal Data, the Customer is the Data Fiduciary and Daemon AI LLP is a Data Processor acting on the Customer's behalf.

This allocation covers all Customer Personal Data processed through the Service, and specifically includes:

1. data the Customer or its Users submit directly to the Service;
2. data read from a Connected Application by the Sense stage of the Service, including mailbox and calendar contents, attachments, participant lists and CRM records;
3. data written to a Connected Application by an Agent Action, up to the point at which it leaves our processing environment (see Annex 5);
4. data derived by the Service from any of the above, including the per-user personal knowledge graph, relationship graphs, project associations, and inferred attributes; and
5. prompts, instructions and approvals submitted by Users, and outputs generated in response to them.

We do not determine the purposes for which this data is processed. The Customer does, through the instruction surface described in clause 5.

3.2 Service Data — and the narrow set for which we are an independent Data Fiduciary¶

Service Data means the following categories, and no others:

1. Security and operational logs — records of authentication events, requests to the governed boundary, decisions of the input security gate, connector executions, errors and system telemetry, generated for the purposes of operating, securing and debugging the Service, and for meeting our obligations under the CERT-In Directions;
2. Audit records — the append-only record of AI actions, tool actions and provisioning actions, retained for integrity, governance reporting and dispute resolution;
3. Billing and account data — the identity and contact details of the Customer's administrative and billing contacts, subscription records, invoices, payment records, and metered usage counts; and
4. Aggregated and de-identified usage statistics — volumetric and behavioural statistics derived from operation of the Service that do not identify and cannot reasonably be used to identify the Customer, any User, or any Data Principal.

We do not claim independent Data Fiduciary status across all of that set, and the reason is a limitation in the Act rather than a matter of preference. Under section 4 of the DPDPA, personal data may be processed only for a lawful purpose for which the Data Principal has given consent under section 6, or for a legitimate use enumerated in section 7. Section 7 contains no network-and-information-security limb and no general legitimate-interests limb. There is therefore no enumerated basis on which we could process, in our own right, personal data about people we have never dealt with — and categories 1 and 2 contain exactly that, because a log or an audit entry can name the Acting User and can name the target individual, who may be a counterparty in the knowledge graph who has never heard of us and to whom notice under section 5 is not practicable.

The allocation is therefore split:

We do not describe ourselves as an independent Data Fiduciary for anything containing third-party personal data. Retaining that label for categories 1 and 2 would assert a lawful basis we do not have.

Service Data expressly excludes Customer Content. We do not treat Customer Content, or any part of it, as Service Data. Aggregation cannot manufacture Service Data: taking Customer Content, summarising it, counting it, describing it or deriving statistics from it does not convert it into data we hold in our own right, and we will not treat it as having done so. The only route by which material derived from Customer Content becomes category 4 is genuine de-identification, and if it can reasonably be re-identified it has not been de-identified. Where the Service Data set overlaps with Customer Content — for example an audit record that names a document an Agent Action touched — the record itself is Service Data, the document is not, and we process the record only for the purposes listed above.

In respect of category 3, and of category 4 so far as it is personal data at all, we are responsible for our own lawful basis, our own notice to affected Data Principals, and our own compliance with Applicable Data Protection Law. That processing is described in our Privacy Policy at /legal/privacy. In respect of categories 1 and 2 we process as a Data Processor, and every obligation in this Addendum that attaches to our processing of Customer Personal Data attaches to them.

3.3 Joint determination, and the derived layer¶

The DPDPA defines a Data Fiduciary as a person who, alone or in conjunction with other persons, determines the purpose and means of processing personal data. The words "in conjunction with" do real work, and a processor that ignores them is not being careful.

The Sense stage does not merely store what it reads. It derives a layer that did not exist in the source systems: relationship graphs, project and topic associations, and inferred communication tone per contact. The Customer determines the purpose of that processing, and determines the inputs — which mailboxes, which calendars, which scopes, which date ranges. But the means by which raw mailbox data becomes an inference about a named individual is determined by the design of the Service.

We state the consequence rather than avoiding it:

1. Where the Customer cannot configure what inferences are drawn, we are determining a means of processing in conjunction with the Customer in respect of the derived layer, and we may on that footing be a Data Fiduciary for it jointly with the Customer. We do not rely on the label "processor" elsewhere in this Addendum to escape that conclusion, and we will not argue the point against a Customer that raises it.
2. The Customer therefore has configuration control over derived processing. The Customer can determine which classes of inference the Service draws, can disable the drawing of inferences about individuals altogether, and can exclude identified individuals or identified sources from the derived layer while continuing to use the rest of the Service. Those controls are listed in Annex 4.6 alongside the Customer's other model-governance controls.
3. Where the Customer exercises that control, the Customer determines both the purpose and the means of the derived processing, and our role in respect of it is that of a Data Processor under clause 3.1 like any other.
4. Nothing in this clause reduces the Customer's obligations under clause 6.2 in respect of individuals who are not its Users, or transfers to us the notice obligations owed to them.

We flag this because the derived layer is the part of an agentic product most likely to be mischaracterised in a data processing addendum, and because a Customer's own assessment of the arrangement should start from an accurate statement of who decides what.

3.4 Where the Customer is itself a Data Processor¶

If the Customer processes Customer Personal Data as a Data Processor on behalf of a third party — for example, where the Customer is an agency, adviser, or service provider handling its own clients' data — then:

1. the Customer warrants that it has the authority of that third party to appoint us as a sub-processor, and that its own contract with that third party permits our engagement on the terms of this Addendum;
2. references in this Addendum to the Customer's instructions include instructions the Customer is contractually required to pass through from that third party;
3. we will act only on instructions received from the Customer, and not on instructions received directly from that third party, unless the Customer authorises otherwise in writing; and
4. the Customer remains solely responsible, as between the parties, for responding to that third party and to its Data Principals.

3.5 Terminology mapping¶

Because buyers reviewing this document may operate under laws that use different vocabulary, we restate the mapping plainly:

This mapping is provided as a reading aid. It is not a representation that we comply with any regime other than Applicable Data Protection Law as defined in clause 2.

---

4. Scope, nature and purpose of processing¶

4.1 Subject matter, duration and purpose¶

We process Customer Personal Data for the sole purpose of providing, securing, supporting and maintaining the Service in accordance with the Agreement and the Customer's instructions. Processing continues for the term of the Agreement and for the limited period after termination described in clause 12.

Full particulars — subject matter, nature and operations, categories of personal data, categories of Data Principals, and duration — are set out in Annex 1, which forms part of this Addendum.

4.2 The nature of the processing: Sense → Decide → Act → See¶

DaemonOps is an AI operations layer. It runs a four-stage loop, and each stage processes personal data differently. Reviewers should read Annex 1 against this description rather than against a generic SaaS processing description, because the risk profile is not the same.

Sense. The Service ingests data from the Customer's Connected Applications — mailbox, calendar, CRM and similar — and builds a per-user personal knowledge graph from it. This graph is a derived, structured representation of the individual's working context: who they correspond with, what projects those exchanges relate to, and how those relationships behave over time.

Decide. Model inference classifies the request, plans a response, and routes the work to the agents and workflows that are both provisioned to the Acting User and permitted to that person's role.

Act. The Service executes reads and writes inside the Customer's own third-party tools as the Acting User, under that person's identity, role and granted OAuth scopes. The Service does not hold a privileged identity of its own inside those tools and does not act with elevated scope.

See. The Service generates dashboards, documents and other artifacts from the results, and presents them to Users.

4.3 A specific consequence the Customer must plan for¶

The Sense stage means the personal knowledge graph will contain personal data about people who have no relationship with the Customer's organisation and who have never heard of DaemonOps: email counterparties, job candidates, suppliers, professional advisers, and the Customer's own customers. This is inherent in ingesting a mailbox and a CRM; it is not an incidental side effect.

Under the DPDPA the Customer is the Data Fiduciary in respect of those individuals. The Customer, not Daemon AI LLP, must have a lawful basis for that processing and must discharge the notice obligations owed to those individuals. Clause 6.2 records the Customer's warranty on this point in express terms, and Annex 1 lists these individuals as a distinct category of Data Principal.

We flag this here rather than burying it because a generic data-processing addendum does not surface it, and because it is the single item most likely to require the Customer to change something in its own privacy programme before deployment.

---

5. Customer Instructions¶

5.1 Instructions are a three-layer surface, not a single document¶

Standard processor clauses speak of processing on the Data Fiduciary's "documented instructions", contemplating a static schedule agreed once at signature. That model does not describe an agentic product accurately, and a Customer relying on it would not in fact know what it had instructed. For the purposes of this Addendum, the Customer's documented instructions comprise all three of the following layers, and each layer is equally an instruction:

Layer 1 — Standing configuration. The Ops Packs the Customer installs; the roles it defines and assigns; the capability templates and per-member grants its Department Admins author; the Connected Applications it authorises and the OAuth scopes it grants; the model-governance settings it selects, including any allowed-model list, usage limits, autonomy levels and approval gates; and the retention and deletion settings it configures. This layer is durable and is changed deliberately by the Customer's administrators.

Layer 2 — Each prompt. Every request a User submits to the Service is an instruction from the Customer, given through that User, and is bounded by the standing configuration in Layer 1.

Layer 3 — Each approval. Where the Service presents an action for human confirmation before executing it, the Customer's approval of that action is an instruction to perform it, and its refusal is an instruction not to.

The Agreement — this Addendum, the Terms and the Order Form — is itself the Customer's complete and final documented instruction as to the subject matter and duration of processing.

5.2 We process only on instructions¶

We will process Customer Personal Data only on the Customer's documented instructions as defined above, including with regard to transfers, unless required to do otherwise by a law to which we are subject. Where a law requires us to process Customer Personal Data other than on the Customer's instructions, we will inform the Customer of that legal requirement before processing, unless that law prohibits us from doing so on important grounds of public interest.

5.3 Instructions that appear to infringe the law¶

If we form the view that an instruction from the Customer infringes Applicable Data Protection Law, we will inform the Customer without undue delay. We may suspend performance of that instruction until the Customer confirms, withdraws or amends it. This clause does not oblige us to conduct a legal review of the Customer's instructions, and we do not assume the role of assessing the Customer's lawful basis.

5.4 Changing instructions¶

The Customer may change its standing configuration at any time through the Service's administrative surfaces. Where a change to instructions would require processing that the Service is not designed to perform, or that we consider unlawful or technically infeasible, we will tell the Customer, and the parties will discuss in good faith; we are not obliged to implement it.

<!-- GDPR: Art 28(3)(a)-(h) obligations and SCC module selection would go here if EU personal data comes into scope -->

---

6. Customer warranties and responsibilities¶

6.1 Lawful basis, notice and consent¶

The Customer warrants that, in respect of all Customer Personal Data it causes to be processed through the Service:

1. it has a valid lawful basis under Applicable Data Protection Law for the collection, use and disclosure of that data, including for its disclosure to us and to our Sub-processors;
2. it has given each affected Data Principal the notice required by the DPDPA, and has obtained and can evidence any consent that is required;
3. it has the right to transfer that data to us and to authorise us to process it as described in the Agreement; and
4. its own instructions, configuration and use of the Service comply with Applicable Data Protection Law.

6.2 Individuals who are not the Customer's Users¶

Because the Sense stage ingests mailbox, calendar and CRM data, the Customer specifically acknowledges and warrants that Customer Personal Data will include personal data about individuals who are not the Customer's Users, are not employed or engaged by the Customer, and have no relationship with the Customer's organisation through which they would learn of the Service. Those individuals include, without limitation:

• email and message counterparties — anyone who has corresponded with a User, in either direction, within the ingested period;
• calendar participants — internal and external attendees named in meetings and invitations, including free-text notes about them;
• job applicants and candidates, including material contained in applications, referral threads and interview correspondence;
• suppliers, contractors, agents and professional advisers, and their personnel;
• the Customer's own customers, clients and prospects, including individuals named in CRM records; and
• third parties merely mentioned in the body of a message, a document, an attachment, or a meeting note, without themselves being a party to the exchange.

The Customer warrants that it is the Data Fiduciary in respect of each of these categories, that it has its own lawful basis for their inclusion, and that it has discharged, or is lawfully exempt from discharging, the notice obligations owed to them. Daemon AI LLP is not the Data Fiduciary for these individuals and does not assume the Customer's obligations to them.

The Customer is responsible for deciding which mailboxes, calendars, applications and date ranges to connect, and for limiting the scope of ingestion where its lawful basis does not extend to the whole of it.

6.3 Connected Application scopes¶

The Customer, and each Acting User to whom the Customer delegates the decision, determines which Connected Applications are authorised and which OAuth scopes are granted. Granting a broader scope than the Customer's intended use requires is the Customer's decision and its responsibility. Annex 5 sets out how Connected Applications are treated.

6.4 Special categories of personal data¶

The Service is not designed for, and must not be used to process, categories of personal data attracting heightened protection — including data concerning health, financial account information, biometric or genetic data, sexual life or orientation, caste or tribe, religious or political belief, or official identifiers such as government-issued identity numbers — except where the parties have expressly agreed in writing in advance, and have recorded any additional safeguards required.

The Customer acknowledges that ingestion of a general-purpose mailbox may incidentally capture such data. Where the Customer knows or reasonably ought to know that a Connected Application contains material volumes of it, the Customer must raise this with us before connecting, so the parties can agree whether and on what terms it may proceed.

6.5 Accuracy, oversight and configuration¶

Model output is probabilistic. The Customer is responsible for configuring the level of human review appropriate to its use, for the autonomy levels and approval gates it selects, and for reviewing outputs before relying on them for any decision that has a legal or similarly significant effect on an individual. Annex 4 describes the governance controls available to the Customer.

---

7. Confidentiality and personnel¶

We will treat Customer Personal Data as confidential information of the Customer and will not disclose it except as permitted by the Agreement or required by law.

We will ensure that each person authorised to process Customer Personal Data:

1. is subject to a written obligation of confidentiality that survives the end of their engagement;
2. is granted access only to the extent strictly necessary for their role, on a least-privilege basis; and
3. is made aware of the confidential nature of the data and of their responsibilities in relation to it.

We have not yet established a programme for background verification of personnel, and have not yet fixed the frequency or content of security-awareness training. Both are measures we intend to have in place before the Service processes Customer Personal Data under an executed Order Form, and Annex 2.2 records them as commitments of that character rather than as present controls. We will not describe either as operating until it does.

---

8. Security measures¶

8.1 Standard of care¶

We will implement and maintain reasonable security safeguards to prevent a Personal Data Breach, within the meaning of section 8 of the DPDPA, appropriate to the nature of the Customer Personal Data and the risks of the processing.

We reconcile that commitment against what exists today rather than asserting a standard we do not yet meet. Rule 8 of the SPDI Rules — while those Rules remain in force, per the transitional note in clause 2 — treats "reasonable security practices and procedures" as requiring a comprehensive documented information security programme and information security policies, containing managerial, technical, operational and physical controls commensurate with the information assets being protected. A comprehensive documented programme of that kind is not yet in place, and it would be wrong for this clause to imply otherwise.

What that means in practice:

1. Annex 2.1 states the measures actually implemented. They are built into the design of the Service — the single governed boundary, identity propagation, role-based access control enforced at multiple points, the fail-closed input security gate, encrypted storage of connector credentials, per-tenant isolation, the append-only audit log, encryption in transit, server-side secrets, scoped provisioning and audited superadmin override. Those we can point to today.
2. Annex 2.2 states the measures not yet implemented — encryption at rest and key management; backup encryption, retention and restore testing; multi-factor authentication on internal administrative access; vulnerability management; penetration testing; personnel background verification; security-awareness training; and business continuity and disaster recovery objectives. These are commitments to implement before launch, not descriptions of present controls, and Annex 2.2 labels them as such.
3. We undertake to have a documented information security programme covering the Annex 2.2 items in place before the Service processes any Customer Personal Data under an executed Order Form. Until that point, this clause is a commitment of future performance in respect of those items and a description of present controls only in respect of the Annex 2.1 items.

A Customer is entitled to ask us to evidence each Annex 2.2 item at the point of execution, and clause 13.1 makes the then-current Annex 2 available for that purpose.

8.2 Reference framework, not certification¶

Rule 8 of the SPDI Rules recognises the standard IS/ISO/IEC 27001 as a benchmark for reasonable security practices and procedures. We use that standard as a reference framework informing the design of our controls.

We are not certified to ISO/IEC 27001, or to any other information security standard. We hold no SOC 2 report, no ISO certification, and no third-party attestation of any kind. Nothing in this Addendum is a representation that we do. Clause 13.4 states the consequence of this for audit rights honestly rather than deferring the question.

8.3 Changes to measures¶

We may update the measures in Annex 2 from time to time, provided that no update materially reduces the overall level of protection for Customer Personal Data. Where we materially change the measures, we will update Annex 2 and the version history of this Addendum.

8.4 The Customer's own security responsibilities¶

Security of the Service depends on both parties. The Customer is responsible for: configuring its identity provider and enforcing multi-factor authentication for its own Users; defining roles and grants that reflect the access its people should actually have; managing joiners, movers and leavers promptly; selecting appropriate OAuth scopes; safeguarding its administrative credentials; and reviewing its audit records. We do not compensate for the Customer's failure to do these things.

---

9. Sub-processors¶

9.1 General written authorisation¶

The Customer gives us a general written authorisation to engage Sub-processors to process Customer Personal Data, subject to this clause 9.

9.2 The published list¶

The Sub-processors we engage are listed in a maintained register published at /legal/subprocessors, which is incorporated into this Addendum as Annex 3. The register states, for each entry, the vendor, the processing it performs, the categories of data it receives, and — importantly — whether it is live in production or planned and not yet in use.

The Customer authorises the Sub-processors listed in the register as at the date of its Order Form.

9.3 Notice of new or replacement Sub-processors¶

We will give the Customer at least 30 days' advance notice before a new or replacement Sub-processor begins processing Customer Personal Data. Notice will be given by updating the published register and, where the Customer has subscribed to change notifications as described in the register, by email to the address the Customer has registered for that purpose. The register's change log records the date of each change so that this obligation is auditable.

Moving an entry in the register from "Planned" to "Live" is a change requiring notice under this clause.

9.4 Objection¶

Within the notice period, the Customer may object to a new or replacement Sub-processor on reasonable, documented grounds relating to data protection. Dissatisfaction with a vendor's commercial terms, brand, or country of incorporation absent an identified data-protection concern is not such a ground.

On a valid objection we will use reasonable efforts to make the affected functionality available without involving that Sub-processor, or to propose an alternative. If we cannot do so within a reasonable period, the Customer may terminate the affected part of the Service, or the Order Form if the affected part is material to it, on written notice, with a pro-rata refund of prepaid fees for the terminated period. That is the Customer's sole remedy for a sustained objection.

9.5 Flow-down and our liability¶

Before a Sub-processor begins processing Customer Personal Data we will put in place a written contract imposing on it data-protection obligations no less protective than those imposed on us by this Addendum, to the extent applicable to the services it performs.

We remain fully liable to the Customer for the acts and omissions of our Sub-processors in relation to Customer Personal Data as if they were our own.

9.6 The edition split¶

Where the Customer uses a self-hosted or bring-your-own-model (BYOM) enterprise edition of the Service, and the Customer selects and contracts directly with its own model provider, its own connector providers, or its own hosting provider:

• those providers are not our Sub-processors;
• we do not receive, route or retain the Customer Personal Data they process;
• clause 9.5 does not extend to them, and we accept no liability for their acts or omissions; and
• the Customer is responsible for its own contractual arrangements with them.

Table 3 of the register applies this split to model providers explicitly, and the Order Form records which edition the Customer has purchased.

---

10. Assistance with Data Principal rights¶

10.1 Self-service tooling first¶

We will make available functionality within the Service enabling the Customer to access, correct, export and delete Customer Personal Data, so that the Customer can respond to Data Principal requests itself without depending on our manual intervention. The Customer should use that functionality as its first route.

10.2 The Customer is the first responder¶

The Customer, as Data Fiduciary, is responsible for receiving, verifying, assessing and responding to requests from its Data Principals — including requests for access, correction, completion, updating, erasure, grievance redressal, nomination, and the right to know with whom personal data has been shared. We do not assess the merits of those requests and do not respond to them on the Customer's behalf.

The published sub-processor register is also the mechanism by which a Customer can satisfy the DPDPA's right of a Data Principal to obtain the identities of the parties with whom their personal data has been shared, to the extent that sharing occurs through the Service.

10.3 Requests we receive directly¶

If a Data Principal contacts us directly with a request concerning Customer Personal Data, we will not respond to the substance of it. We will inform the individual that we process the data on behalf of a customer and direct them to that customer, and we will notify the Customer of the contact without undue delay, unless prohibited by law.

10.4 Assistance and cost¶

Taking into account the nature of the processing, we will provide the Customer with reasonable assistance by appropriate technical and organisational measures, insofar as this is possible, to fulfil the Customer's obligations to respond to Data Principal requests and to conduct any impact assessment or prior consultation required by Applicable Data Protection Law.

Assistance that cannot be delivered through the Service's self-service functionality, and that requires material engineering effort, may be charged at our then-current professional-services rates, notified in advance.

---

11. Personal Data Breach¶

Three separate clocks apply to a security incident affecting Customer Personal Data in India. They are not the same clock, they run from different triggers, and they are owed to different recipients. This clause states each of them and reconciles them.

11.1 Detection and internal escalation¶

We maintain processes to detect and investigate events affecting the security of Customer Personal Data. On becoming aware of an event that may be a Personal Data Breach, we will investigate promptly to establish whether a Personal Data Breach has in fact occurred. The notification obligation in clause 11.2 does not wait for that investigation to conclude.

11.2 Notification to the Customer — 24 hours to tell, 72 hours to assess¶

We will notify the Customer of a Personal Data Breach affecting Customer Personal Data without undue delay, and in any event within 24 hours of forming a reasonable belief that a Personal Data Breach has occurred. We will follow that initial notification with a fuller assessment within 72 hours, and with further updates as the investigation progresses.

Why the clock runs from reasonable belief rather than from confirmation. The Customer, as Data Fiduciary, must under section 8(6) of the DPDPA give intimation of a personal data breach to the Data Protection Board and to each affected Data Principal, and must do so without delay on becoming aware of it. The Customer cannot become aware until we tell it. A processor that waits for internal confirmation and then takes a further 72 hours can consume the whole of the Data Fiduciary's window before the Data Fiduciary knows a clock is running. That would put our Customer in breach of its own statutory duty while we remained in compliance with our own contract — a defect in the contract, not a feature of it. We have therefore moved the trigger.

Reasonable belief is a real threshold, not a synonym for suspicion. An alert, a single anomaly, or a failed integrity check is not by itself a reasonable belief that a breach has occurred. A credible indication that Customer Personal Data has been subject to unauthorised processing, or has been disclosed, acquired, shared, used, altered, destroyed or rendered inaccessible without authority, is.

A 24-hour notification cannot carry a complete assessment, and we do not pretend otherwise. This is the point on which vendor 24-hour promises usually fail: the forensic work needed to say what was affected, and how much, takes longer than a day, and a Customer that receives a fast but wrong account of the scope is worse off than one that receives an accurate account a little later. We have resolved that tension by splitting the obligation rather than by slowing the notification. Our 24-hour duty is to tell the Customer what we then know, expressly flagged as preliminary, so that the Customer can start its own clock and begin its own assessment. Our 72-hour duty is to provide the fuller assessment described in clause 11.6, to the extent it is then available. Where we can do either sooner, we will.

Where an initial notification proves to have been about an event that was not a breach, we will tell the Customer that in writing. We would rather notify a Customer about an event that turns out to be nothing than leave it uninformed about an event that turns out to be something.

Notification will be sent to the Customer's designated security contact recorded on the Order Form, or failing that to the Customer's administrative contact.

11.3 CERT-In — 6 hours¶

Separately, the CERT-In Directions dated 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, require certain classes of cyber incident to be reported to CERT-In within 6 hours of noticing the incident or being brought to notice about it. Where an incident affecting the Service falls within a reportable category, we will make that report as the entity operating the affected infrastructure, and will inform the Customer that we have done so. A CERT-In report is a regulatory filing about our infrastructure; it is not a substitute for, and does not delay, the notification we owe the Customer under clause 11.2.

Two further requirements of the same Directions apply to us, and we state them because they are as often omitted from vendor documentation as the six-hour clock is quoted:

1. Clock synchronisation. The Directions require all ICT system clocks to be connected to and synchronised with the Network Time Protocol server of the National Informatics Centre or the National Physical Laboratory, or with NTP servers traceable to them. This is not a formality: a six-hour reporting obligation and a 180-day log-retention obligation are both worth much less if the timestamps across systems do not agree, and a common, traceable time source is what makes a reconstructed sequence of events evidentially useful.
2. A Point of Contact filed with CERT-In. The Directions require the designation of a Point of Contact for interaction with CERT-In, whose details must be filed with CERT-In in the prescribed format and kept current when they change. Our Point of Contact is Swarochish Chekuri, Designated Partner, contact@daemonai.tech. Naming that individual in this Addendum is not the same act as filing the designation with CERT-In, and we distinguish the two deliberately: the filing, and the discipline of keeping it current, is a step we will complete before the Service processes Customer Personal Data under an executed Order Form.

11.4 DPDPA section 8 — who notifies whom¶

Section 8 of the DPDPA requires a Data Fiduciary to give intimation of a personal data breach to the Data Protection Board and to each affected Data Principal, in the form and manner prescribed. That form and manner — what the intimation must contain, how it must be given to affected Data Principals, and the follow-up filing owed to the Board — is prescribed by the DPDP Rules rather than by the Act, and a Customer preparing its own breach playbook should work from the Rules.

As between the parties:

• the Customer, as Data Fiduciary, is responsible for making any intimation to the Data Protection Board and to affected Data Principals in respect of Customer Personal Data;
• Daemon AI LLP, as Data Processor, notifies the Customer and assists it;
• we will not notify the Customer's Data Principals or the Data Protection Board on the Customer's behalf, and will not do so independently in respect of Customer Personal Data, except where we are separately required to as an independent Data Fiduciary in respect of Service Data, or where a law directly obliges us; and
• where we are required to make our own filing that names or concerns the Customer, we will inform the Customer before doing so unless prohibited by law.

11.5 ICT logs, the 180-day rule, and where they may be held¶

The CERT-In Directions require that logs of all information and communications technology systems be maintained securely for a rolling period of 180 days, and maintained within Indian jurisdiction.

This is a real architectural constraint, not boilerplate, and we state its consequences plainly:

1. the Directions require our ICT logs to be retained for a rolling 180 days and maintained within Indian jurisdiction;
2. this limits the log-aggregation, error-monitoring and observability vendors we may use. We state the limit as we understand it rather than more absolutely than the source supports: CERT-In's FAQ of 18 May 2022 is understood to permit logs to be stored outside India provided they can be produced to CERT-In on demand within a reasonable time. That is our understanding of the position, not a certainty, and we will confirm it before relying on it in a vendor decision. What is not in doubt is that a vendor which cannot produce logs to CERT-In on demand within a reasonable time is unusable for this category;
3. it interacts directly with the deletion obligation in clause 12: logs that fall within this requirement cannot be deleted on request before the 180-day period expires; and
4. we have not yet established our log-retention and log-hosting arrangements. The "still to be determined" section of the sub-processor register records this as an open vendor decision rather than a settled one.

11.6 Content of notification, and no admission¶

Our notification will describe, to the extent then known and as it becomes known: the nature of the breach; the categories and approximate volume of Customer Personal Data and Data Principals affected; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point for further information. We will provide updates as the investigation progresses.

Our notification of a Personal Data Breach is not an acknowledgement of fault or liability.

---

12. Deletion and return¶

12.1 Retrieval window¶

On expiry or termination of the Agreement, the Customer may retrieve Customer Content, including Customer Personal Data, through the Service's export functionality for a period of 30 days from the effective date of termination. During that window we will not delete Customer Content, save as directed by the Customer.

Where the Customer requires assistance with an export that the Service's functionality does not support, we will provide reasonable assistance, chargeable at our then-current professional-services rates.

12.2 Deletion¶

After the retrieval window closes, we will delete Customer Personal Data from our production systems, and instruct our Sub-processors to do the same, within a reasonable period, unless retention is required by clause 12.3 or by a law to which we are subject.

12.3 What we retain, and why — stated honestly¶

Many data processing addenda promise unqualified deletion and then breach that promise the first time it is tested, because the vendor operates an immutable audit log or is subject to a mandatory log-retention rule. We would rather name the carve-out than commit to something the architecture cannot deliver.

We will retain, after deletion under clause 12.2:

1. The append-only audit trail — for a defined period, not indefinitely. The audit log of AI actions, tool actions and provisioning actions is append-only by design; that immutability is what makes it evidentially useful to the Customer, and it cannot be selectively rewritten to excise individual entries without destroying the property that makes it worth keeping. Audit entries record who did what, to which target, with what status, and when — which means they contain personal data about the Acting User, and frequently about the individual who was the target of the action.

   We retain the audit trail for three years from the date of each entry. We do not retain it indefinitely, and we no longer claim to. An earlier draft of this Addendum retained the trail permanently by design and offered no basis for doing so. That position is not defensible. Section 8(7) of the DPDPA requires personal data to be erased once the specified purpose is no longer served and its retention is no longer necessary for compliance with law, and section 12(3) gives a Data Principal a right to erasure subject only to those same necessities. "Our architecture is append-only" describes a design choice; it is not a legal basis for keeping personal data about a third party for ever, and we could identify no obligation that mandates permanence here.

   Three years corresponds to the limitation period for suits founded on contract under the Limitation Act, 1963, which is the period over which the trail's dispute-resolution purpose remains live. Immutability and a retention period are reconciled by destroying the trail in whole time-bounded tranches rather than by editing it: entries older than the retention period are destroyed together, and no entry inside the retained period is ever altered or removed. Where a legal claim, regulatory proceeding or investigation is pending or reasonably anticipated, the affected tranche is placed on hold and retained until it concludes, and we will tell the Customer when a hold is applied to records concerning it.

2. ICT logs required under the CERT-In Directions. As described in clause 11.5, these must be retained for a rolling 180-day period and held within Indian jurisdiction. We cannot delete them on request before that period expires.

3. Records required for legal, accounting or tax purposes, and records required to establish, exercise or defend legal claims, for the period required.

4. Data in routine backups, until those backups expire on their normal cycle.

Retained records remain subject to this Addendum. Specifically: they continue to be protected by the security measures in Annex 2; they will not be used for any purpose other than the purpose for which they are retained; they will not be used to reconstitute the deleted Customer Content; and they will be deleted when the retention basis expires.

We have not yet established our backup retention periods or our backup deletion cycles. Annex 2.2 records this as a measure to be implemented before launch, and item 4 above cannot be read as stating a settled period until it is.

12.4 Certification¶

On the Customer's written request made within 90 days of the end of the retrieval window, we will confirm in writing that deletion under clause 12.2 has been carried out, and will identify what has been retained under clause 12.3 and the basis for each retention.

---

13. Audit and information rights¶

We recognise that an enterprise buyer must be able to verify what it has been told. We also recognise that an early-stage company that offers unlimited on-site audit rights to every customer will either not honour them or not survive them. This clause therefore tiers the right, and states the limits at each tier.

13.1 Tier 1 — Documentation and the register, available to every Customer¶

On request, and without charge, we will provide:

• this Addendum and its annexes;
• the current sub-processor register, together with its change log;
• a description of the technical and organisational measures then in force (Annex 2);
• our data-flow description and the categories of data processed (Annex 1); and
• confirmation of the regions in which processing occurs, to the extent known.

13.2 Tier 2 — Annual security questionnaire¶

Once in any 12-month period, we will complete and return the Customer's standard security or vendor-risk questionnaire, or a reasonable industry-standard equivalent, within 30 days of receipt. Where a question concerns a control we have not implemented, we will answer that we have not implemented it. We will not answer a questionnaire inaccurately in order to pass it.

Where a Customer's questionnaire is unusually long or bespoke, we may ask for reasonable additional time.

13.3 Tier 3 — On-site or third-party audit, on conditions¶

The Customer may conduct, or appoint a third party to conduct, an audit of our processing of Customer Personal Data, only where:

• a competent regulator or supervisory authority requires the Customer to do so, and the Customer provides evidence of that requirement; or
• a Personal Data Breach affecting the Customer's Customer Personal Data has been confirmed and the Customer's audit is reasonably directed at that breach.

Every Tier 3 audit is subject to all of the following:

1. at least 30 days' prior written notice, save where a regulator imposes a shorter deadline;
2. no more than once in any 12-month period, save following a further confirmed breach;
3. conducted during business hours, in a manner that does not disrupt the Service or any other customer's data;
4. conducted by the Customer or by an independent third-party auditor who is not a competitor of Daemon AI LLP, and who is bound by confidentiality obligations at least as protective as those in the Agreement;
5. limited to information and systems relating to the Customer's own Customer Personal Data, and expressly excluding any other customer's data, our source code, and our commercially sensitive information;
6. at the Customer's cost, including our reasonable costs of supporting the audit; and
7. with findings treated as our confidential information and shared with the auditor's client only.

13.4 We do not offer reports that do not exist¶

We do not hold a SOC 2 Type I or Type II report, an ISO/IEC 27001 certificate, or any equivalent third-party attestation, and this Addendum does not promise one. Where a Customer's procurement process requires such a report as a condition of purchase, we would rather say so at the outset than accept the order and fail the requirement later. If we obtain an attestation in future, we will make it available under Tier 1 and will update this clause.

---

14. International transfers¶

14.1 The DPDPA position: a negative list¶

Section 16 of the DPDPA operates as a negative list. Transfer of personal data outside India is permitted except to countries that the Central Government restricts by notification. It is not a positive-adequacy regime, and it does not require data localisation for personal data generally.

We will not transfer Customer Personal Data to a country restricted by such a notification. Where a notification comes into force that affects an existing transfer, we will act to bring the processing into compliance and will notify the Customer.

That commitment carries a qualification, and we will not omit it. An assurance that no transfer is made to a restricted country can only be given to the extent we know where each processor actually processes. We do not know that for every processor today. The operating entity and the processing jurisdiction of AgentMail — which today carries every waitlist submission — have not been established, and until they are we cannot complete the section 16 check in respect of that processor. We will not guess at its jurisdiction in order to be able to state the check as complete.

The position stated precisely is therefore: we will not knowingly transfer Customer Personal Data to a country restricted by notification; we have completed the section 16 check for each processor whose jurisdiction we have established; and we have not been able to complete it for AgentMail. Establishing that jurisdiction appears in "What remains to be established" at the end of this Addendum, and the sub-processor register records the same gap in the row itself rather than in a footnote.

14.2 Where processing actually occurs¶

We do not claim that Customer Personal Data stays in India, and the Customer should not assume it does. Several components of the Service are provided by, or depend on, entities that are incorporated in or operate from the United States, and Table 3 of the sub-processor register contemplates model providers that are US-linked. Concretely: the website is hosted by a US company; waitlist submissions come to rest in a Google Workspace mailbox operated by a US company; the service that carries them to that mailbox is of unestablished jurisdiction, as clause 14.1 records; and the planned model providers are US-linked.

The one place where location is not simply a matter of our discretion is CERT-In ICT logs, which the Directions require to be maintained within Indian jurisdiction, subject to the understanding about production on demand recorded in clause 11.5. Everything else is a matter of vendor architecture, and the sub-processor register — not this clause — is the authoritative statement of where each component sits. Regions the register records as not yet established are genuinely unknown to us today, and are recorded in those words rather than guessed at.

14.3 Other regimes¶

This Addendum is drafted to Applicable Data Protection Law as defined in clause 2. It does not incorporate the transfer mechanisms of other regimes, and we make no claim of compliance with them.

<!-- GDPR: Art 28(3)(a)-(h) obligations and SCC module selection would go here if EU personal data comes into scope -->

---

15. Liability¶

Each party's liability arising out of or in connection with this Addendum is subject to the exclusions and limitations of liability set out in the Terms, and all references to a party's liability in this Addendum mean the aggregate liability of that party across the Agreement as a whole.

The position is settled, and stated here rather than left open. Liability for breach of this Addendum — including liability for a Personal Data Breach, and our liability under clause 9.5 for the acts and omissions of our Sub-processors — sits inside the general limitation of liability in the Terms. There is no separate cap, no elevated cap and no uncapped carve-out for data-protection obligations. A single aggregate cap governs the Agreement as a whole.

That is subject to one exception, which is not a matter of negotiation: nothing in this Addendum limits or excludes either party's liability to the extent that such limitation or exclusion is not permitted by law, including Applicable Data Protection Law. A penalty imposed on a party by the Data Protection Board is imposed on that party by the regulator, and this clause does not purport to redistribute it.

We resolve the choice rather than publishing it as an open question, because an addendum that leaves the interaction between its own liability provisions and the cap in the Terms unsettled is not a document a buyer can price, and an unmade commercial decision does not belong in operative text.

---

16. Term, survival and termination¶

This Addendum takes effect on the effective date of the Order Form that incorporates it, and continues for as long as we process Customer Personal Data on the Customer's behalf.

Clauses 7 (confidentiality), 11 (breach, in respect of incidents affecting retained data), 12 (deletion and return), 13 (audit, for 12 months following termination), 15 (liability), 17 and 18 survive termination of the Agreement, together with any clause that by its nature is intended to survive.

---

17. Precedence, variation and severability¶

17.1 Precedence. Clause 1.4 governs conflicts.

17.2 Variation. We may update this Addendum where required to reflect a change in Applicable Data Protection Law, a change in the Service, or a change in our Sub-processors. Where an update materially reduces the protections afforded to the Customer, we will give the Customer at least 30 days' prior written notice, and the Customer may terminate the affected Order Form on written notice before the update takes effect, with a pro-rata refund of prepaid fees. Updates that do not materially reduce protections take effect on publication. Sub-processor changes are governed by clause 9.3, not by this clause.

17.3 Severability. If any provision of this Addendum is held invalid or unenforceable, the remainder continues in full force, and the parties will replace the affected provision with a valid one that most closely achieves its intended effect.

17.4 No third-party rights. This Addendum does not confer rights on any person who is not a party to it.

---

18. Governing law and jurisdiction¶

This Addendum is governed by the laws of India. The courts at Hyderabad have exclusive jurisdiction over any dispute arising out of or in connection with it, subject to any dispute-resolution provision in the Terms, which prevails to the extent of any inconsistency on procedure.

Our registered office is at Nellore. Hyderabad is named as the seat because we have a business nexus there, and we state the reason so that the choice reads as a considered one rather than as a convenience clause.

---

19. Contact¶

All notices, requests and communications under this Addendum should be sent to contact@daemonai.tech, addressed to Swarochish Chekuri, Designated Partner, with a copy by post to the registered office stated in clause 1.2 where the Customer requires a written record.

We operate a single contact channel deliberately. It is monitored, and a request sent to it reaches the people who can act on it.

---

Annex 1 — Description of the processing¶

A1.1 Subject matter¶

Provision of DaemonOps, an AI operations layer that senses context from the Customer's Connected Applications, plans and routes work, executes actions inside the Customer's own third-party tools as the Acting User, and produces dashboards, documents and artifacts.

A1.2 Nature and operations of the processing¶

The operations performed on Customer Personal Data map to the Service's four-stage loop. This is the accurate description of the processing and should be read in place of a generic list.

A1.3 Categories of personal data¶

A1.4 Categories of Data Principals¶

1. The Customer's Users — employees, contractors and other personnel authorised to use the Service.
2. The Customer's other personnel named in connected data without themselves being Users.
3. Third parties appearing in Connected Applications — email and message counterparties, calendar participants, job applicants and candidates, suppliers and their personnel, professional advisers, the Customer's own customers, clients and prospects, and any individual merely mentioned within a message, attachment, note or record. These individuals typically have no relationship with the Customer's organisation and no awareness of the Service. Clause 6.2 allocates responsibility for them.
4. The Customer's administrative and billing contacts (also processed by us as Service Data under clause 3.2).

A1.5 Special categories¶

Not permitted without the prior written agreement of the parties, in accordance with clause 6.4.

A1.6 Duration¶

For the term of the Agreement, plus the retrieval window in clause 12.1, plus the retention periods in clause 12.3 for records falling within them.

---

Annex 2 — Technical and organisational measures¶

Annex 2.1 describes only measures that are part of the Service's design and that we can verify today. Annex 2.2 lists controls a reviewer would expect that we have not implemented, and states them as commitments to implement before launch rather than as descriptions of anything now operating. The division between the two is the whole point of this annex, and clause 8.1 explains why it is drawn where it is.

A2.1 Measures implemented in the design of the Service¶

Single governed boundary. All access to the AI runtime passes through one governed boundary. There is no second path into the runtime that bypasses authentication, authorisation, screening or audit.

Identity propagation — actions run as the named person. The Acting User's identity, roles and superadmin status are injected into every runtime call. The runtime acts as that person and never with elevated scope, regardless of what capabilities are provisioned to them.

Role-based access control enforced at multiple points. Permissions are checked at every surface, not only at the door: at routing (the roster is scoped to the caller's provisioned capabilities and then filtered by role), at connector execution (each tool execution re-checks the caller's grants for that connection and tool, then writes an audit record), at screens, at the agent registry (roster reads are scoped to tenant and to the caller's grants), and at provisioning.

Fail-closed input security gate. Every request is screened before routing against a threat set drawn from the OWASP LLM risk categories — prompt injection and instruction override, jailbreak and safety bypass, system-prompt or configuration exfiltration, agent and roster enumeration, and exfiltration of secrets or credentials. A high-confidence detection returns a single safe refusal and halts the turn; nothing downstream executes. The gate does not rely on the downstream model policing itself.

Encrypted storage of connector credentials. Credentials for Connected Applications are stored encrypted.

Per-tenant isolation. Data is scoped per tenant, and personal knowledge is scoped per user. Reads and writes carry the caller's tenant and role grants, so a query cannot return another tenant's data.

Append-only audit log. Every AI action, tool action and provisioning action is recorded — actor, action, target, status, governed flag, and timestamp — in an append-only log. The log is the evidential record the Customer can rely on. Its immutability is the reason for the retention carve-out in clause 12.3, which also states the defined period for which it is kept and the tranche-destruction mechanism that reconciles immutability with erasure.

Encryption in transit. Communications with the Service are encrypted in transit.

Secrets held server-side. Runtime credentials are held server-side. The browser never holds them, and no data reaches the client that has not passed the governed boundary.

Scoped provisioning. A Department Admin may create capability templates and per-member grants only within their own team, and only from Ops Packs installed or approved for that team. Provisioning controls availability, never authority: it can never elevate a member's role permissions.

Audited superadmin override. Elevation is an explicit, separate path, and every use of it is recorded in the audit log.

A2.2 Measures not yet implemented — commitments to be met before launch¶

Nothing in this table is a present control. Each row is a measure a reviewer would expect and that we have not implemented. Clause 8.1 commits us to having a documented information security programme covering all of them in place before the Service processes Customer Personal Data under an executed Order Form. They are stated as commitments so that no reader mistakes them for description.

---

Annex 3 — Sub-processors¶

The Sub-processors engaged in the provision of the Service are listed in the maintained register published at /legal/subprocessors, which is incorporated into this Addendum by reference and forms Annex 3.

That register:

• distinguishes live entries from planned entries, and does not present planned vendors as current ones;
• states for each entry the processing performed and the categories of data received;
• identifies the highest-sensitivity entries expressly, including any vendor that would hold the Customer's third-party credentials;
• separates model providers by edition, so that a Customer on an Enterprise BYOM edition can see which entries are not our Sub-processors (clause 9.6); and
• maintains a dated change log, which is what makes the notice obligation in clause 9.3 auditable.

---

Annex 4 — AI and model processing¶

This annex exists because it is the part of the document an AI-vendor security review opens first, and because a generic addendum does not address it at all.

A4.1 Which providers process prompts and Customer Content¶

Model inference is performed by third-party model providers. The register at /legal/subprocessors (Table 3) lists the providers contemplated, what is sent to each, their retention posture, their training-use posture, and their region. Every entry in that table is currently marked planned and unconfirmed, because no model provider is in production use today.

The split by edition is material:

Gateways are sub-processors too. Where inference is routed through an aggregation or gateway layer rather than sent directly to the model provider, that gateway is itself a sub-processor and must be registered as one. This is the entry most often omitted from vendor registers, because reviewers ask "which model do you use" rather than "what sits between you and the model". Whether we will operate behind a gateway at all, and if so which, has not been decided; the candidates under consideration are named in Table 3 of the register, and the decision will be recorded there before any inference is routed.

A4.2 Training and model improvement¶

Customer Content is not used to train, fine-tune or improve foundation models — neither by us nor, under the terms we will require, by our model-provider Sub-processors. We will flow this commitment down to each model provider we engage, and will not engage a provider that will not accept it for the plan and endpoint we use.

This commitment has not yet been verified against any provider's actual contractual terms, and we have not read them. Providers offer different postures on different plans and endpoints; a statement true of an enterprise API tier may be false of a consumer tier or a preview endpoint. Until each provider's terms have been read and the applicable plan identified in Table 3 of the register, the paragraph above is an intended commitment, not a verified fact, and we mark it as such rather than asserting it flatly. No provider will move to live use until its terms have been read and its row in Table 3 states the verified position.

A4.3 Provider retention¶

Model providers may retain prompts and outputs for a period for abuse-monitoring or operational purposes. Where a zero-retention or reduced-retention configuration is available on the plan we use, we intend to enable it. The retention period applicable to each provider, and whether a zero-retention configuration is available on the plan we would use, has not been established for any provider. It will be stated per provider in Table 3 of the register before that provider processes anything.

A4.4 Aggregated and de-identified statistics¶

We may generate aggregated and de-identified statistics from operation of the Service — such as counts of requests, latency distributions, failure rates, and feature-usage volumes — and use them to operate, secure and improve the Service. Such statistics are Service Data under clause 3.2.

We will not attempt to re-identify any individual, Customer or Data Principal from such statistics, and will not publish or disclose them in a form from which the Customer or any individual could reasonably be identified.

A4.5 Human review¶

Our personnel do not routinely read Customer Content. Access occurs only:

1. for support, where the Customer has requested assistance and authorised access to the affected data, limited to what is necessary to resolve the issue; or
2. for security or abuse investigation, where necessary to investigate a suspected security incident, a breach of the acceptable-use policy, or unlawful activity.

Every such access is subject to role-based access control and is recorded in the audit log.

A4.6 Model-governance controls held by the Customer¶

The Customer, not Daemon AI LLP, decides how much autonomy the Service has in its environment. The controls available to the Customer include:

• Allowed-model list — restricting which models may be used for the Customer's tenant;
• Usage limits — capping AI usage at tenant, team and member level;
• Autonomy levels — determining how far the Service may proceed without human confirmation, including modes that reason without acting;
• Approval gates — requiring explicit human approval before defined categories of action execute;
• Provisioning and role grants — determining which agents and workflows each person's assistant may reach at all, and what any action may touch;
• Connected Application scopes — determining what the Service can read and write in each third-party tool; and
• Derived-processing controls — determining which classes of inference the Service draws in the Sense stage, disabling the drawing of inferences about individuals altogether, and excluding identified individuals or identified sources from the derived layer while continuing to use the rest of the Service. Clause 3.3 explains why this control matters to the allocation of roles between the parties and is not merely a preference setting: where the Customer cannot configure what inferences are drawn, we may be determining a means of processing in conjunction with the Customer for that layer.

The precise configuration surface for each of these controls has not been established, because the product is not built. These are the controls the Service is designed to give the Customer, and clause 3.3 and clause 6.5 are drafted on the footing that it will. A Customer executing an Order Form is entitled to see the shipped configuration surface and to hold us to this list.

A4.7 Probabilistic output¶

Model output is probabilistic and may be inaccurate, incomplete or unsuitable for a given purpose. The Service is a tool operated by the Customer's people; it is not a decision-maker. The Customer configures the level of human review appropriate to its use, and is responsible for that configuration and for reliance placed on outputs, particularly for any decision producing a legal or similarly significant effect on an individual.

---

Annex 5 — Connected Applications¶

A5.1 What a Connected Application is¶

A Connected Application is the Customer's own relationship with a third party — its mailbox provider, its calendar, its CRM. It exists independently of the Service and is governed by the Customer's own agreement with that provider. The Service accesses it only because, and to the extent that, the Customer or an Acting User has authorised that access.

A5.2 The Customer controls the scopes¶

The Customer, and each Acting User to whom the Customer delegates the decision, determines which applications are connected and which OAuth scopes are granted. We do not expand a granted scope, and the Service cannot exceed the permissions the third-party provider has actually issued for that person. The Customer may revoke a connection at any time, in the Service or at the provider.

A5.3 Data written by an Agent Action leaves our environment¶

When an Agent Action writes to a Connected Application — sending a message, creating a calendar entry, updating a CRM record — that data leaves our processing environment at the point of the write. From that point it is held by the third-party provider, inside the Customer's own tenancy of that provider, and is governed by the Customer's agreement with that provider and by that provider's terms, not by this Addendum.

We retain an audit record of the action. We do not retain a mirror of the written content beyond what the Service requires to function and what Annex 1 describes.

A5.4 We are not a processor for the Customer's independent use¶

Daemon AI LLP is not a Data Processor in respect of the Customer's independent use of a Connected Application. Data the Customer's people put into their CRM directly, or emails they send from their mail client without involving the Service, are outside this Addendum entirely. Our processor role attaches only to data read into, held within, or written by the Service.

A5.5 The provider's own processing¶

Third-party providers of Connected Applications process the Customer's data under their own terms and their own role. They are not our Sub-processors, because the Customer — not Daemon AI LLP — selects them, contracts with them and pays them.

---

What remains to be established¶

This draft is complete in structure and substance, and deliberately incomplete on facts we have not established. The items below must be resolved before any Order Form incorporates this Addendum. They are collected here so that a reviewer can see the whole of the gap in one place rather than assembling it from the body.

Settled in this version¶

Clause 13.3 states a 30-day audit notice period and a 12-month audit frequency. These are firm figures rather than open items, but should be reviewed alongside the above.

Facts not yet established¶

Security measures (Annex 2.2) — every control in that table. Each is stated there as a measure to be implemented before launch rather than as a present control, and clause 8.1 records the undertaking that a documented information security programme covering them will be in place before any Customer Personal Data is processed under an executed Order Form.

Personnel (clause 7) — background verification and security-awareness training, as above.

Logging (clauses 11.3, 11.5, 12.3) — ICT log retention and hosting arrangements under the CERT-In 180-day requirement; whether logs may be held outside India provided they can be produced to CERT-In on demand within a reasonable time, which we state as our understanding of CERT-In's FAQ of 18 May 2022 and not as settled; clock synchronisation to NIC or NPL NTP servers; the filing of our CERT-In Point of Contact, which has been designated but not filed; backup retention periods and deletion cycles.

AI and model processing (Annex 4) — the no-training commitment has not been verified against any model provider's actual contractual terms, for the plan and endpoint that would be used; per-provider retention periods and whether a zero-retention configuration is available and enabled; whether a gateway will be used and, if so, which — a gateway is itself a sub-processor and must be registered as one; the shipped configuration surface for allowed-model lists, usage limits, autonomy levels, approval gates and derived-processing controls.

Processing locations (clauses 14.1, 14.2, Annex 3) — hosting providers and regions for the control-plane database and the knowledge graph; and, most immediately, the operating entity and processing jurisdiction of AgentMail, which carries every waitlist submission today and for which the section 16 restricted-country check therefore cannot be completed. We will not guess at it.

Joint determination (clause 3.3) — whether, in the shipped product, the Customer's control over derived processing is sufficient that we act as a Data Processor in respect of the derived layer. Clause 3.3 states our position and the controls the Customer is to have; the product surface that makes it good does not yet exist.

Consistency checks¶

1. Every figure in this Addendum must match the published sub-processor register, in particular the 30-day notice period in clause 9.3.
2. No row in the published register may carry a bracketed placeholder. Section 10.2 of the register states that rule; where a fact is unknown the register says "Not yet established" in plain words.
3. The two HTML comments marking the GDPR insertion points (clauses 5 and 14) must be resolved — either by drafting the Article 28(3) obligations and selecting SCC modules, or by confirming that EU personal data remains out of scope — before this document is offered to a customer with EU operations.
4. On commencement of section 44 of the DPDPA, which omits section 43A of the Information Technology Act, 2000, the definition of Applicable Data Protection Law in clause 2 and the standard of care in clause 8.1 must be restated to reflect the position of the SPDI Rules at that point.
5. This document must be reviewed by counsel before execution. It has been drafted to be reviewable, not to substitute for review.