Acceptable Use Policy

Effective date: 8 September 2026
Last updated: 8 September 2026
Version: 1.0

1. Status of this Policy¶

1.1 It is part of the contract¶

This Acceptable Use Policy is incorporated by reference into the Terms and Conditions published at /legal/terms and forms part of them. It is enforceable as a contractual term.

It applies:

(a) to every visitor to and user of the daemonai.tech website (the "Site"), under Part A of the Terms, from the Effective Date above; and

(b) to the Customer and every User of the DaemonOps service (the "Service"), under Part B of the Terms, from the date Part B is activated for that Customer.

1.2 Breach is material¶

A breach of this Policy is a material breach of the Terms. It entitles Daemon AI LLP to act under the enforcement ladder in clause 14, and, where the breach causes loss, to be indemnified under the Terms.

1.3 Defined terms¶

Capitalised terms used here — including Agent Action, Approval Gate, Authorisation Scope, Autonomy Level, Connected Application, Customer, Customer Content, Customer Instruction, Model Provider, Named User / Acting User, Ops Pack, Service Data and User — have the meanings given in clause 16 of the Terms. That clause is the single canonical definition set; this Policy does not redefine them.

1.4 Not exhaustive¶

The prohibitions below are examples of unacceptable use, not an exhaustive list. Conduct that is not expressly listed may still breach this Policy if it is inconsistent with the governing principle in clause 2, with the Terms, or with applicable law. If you are unsure whether an intended use is permitted, ask us at contact@daemonai.tech before proceeding.

2. The governing principle¶

Everything in this Policy follows from a single rule.

The Service acts as a person. Anything you may not lawfully do yourself, or may not do in a given system, you may not instruct the Service to do.

DaemonOps performs Agent Actions inside your own third-party business tools, using credentials and scopes you grant, under the identity and permissions of a named individual. An email the Service sends is an email from that person. A record it updates is a record that person updated. The Service does not create a new legal actor, a separate identity, or a layer of insulation between you and the consequences of what is done in your systems.

The correct test for any intended use is therefore simple: could the Acting User lawfully and properly do this themselves, in that system, right now? If the answer is no, the Service must not be instructed to do it.

Automation changes the speed and the scale of an action. It does not change its legality, its authorisation, or who is answerable for it.

3. Authority and scope¶

This section closes a gap the product cannot close by itself.

The Service is designed and configured to act within the permissions of the Acting User and within the Authorisation Scope granted to it. You configure and control that scope. And the Service cannot judge whether that person should have had those permissions in the first place. That judgement belongs to you, and the rules below make it your obligation.

No system is represented as incapable of error. Nothing in this Policy is a representation that the Service, or any control within it, cannot fail, be defective or be circumvented. The controls, and their limits, are described in the Documentation; clause 18.3 of the Terms states the position and allocates the residual gap.

You must not:

(a) Grant scopes exceeding your own authority. You must not connect an application, grant an OAuth scope, supply an API key or provide a credential that confers access broader than the access you are authorised to hold and to delegate within your own organisation.

(b) Connect applications you have no right to connect. You must not connect a Connected Application unless you are authorised by your organisation, and permitted by that application's provider, to do so.

(c) Use another person's credentials. You must not use, share, borrow, request or supply another individual's login, token, session, API key or authentication factor, whether or not that person consents.

(d) Use shared or service accounts to disguise who acted. You must not configure or use a shared, generic, departmental or "service" account in a way that causes Agent Actions to appear to come from a named individual who did not authorise them. Where a non-human integration identity is technically necessary, it must be created and labelled as such in accordance with the Documentation, and must not carry a human's name or credentials.

(e) Use the Service to widen a user's effective access. You must not configure roles, scopes, Ops Packs, delegations or automations so as to give a User access — directly or by asking the Service to retrieve, summarise, forward or act on data on their behalf — that the User does not hold in their own right in the underlying system. Routing a request through the AI is not a permission grant.

(f) Grant persistent scope for a one-off need. Where a narrower, time-limited or read-only scope is sufficient, you must not grant a broader, persistent or write-capable one.

(g) Retain scopes after they cease to be appropriate. See clause 12(d).

4. Third-party systems¶

You must not use the Service to:

(a) breach the terms of service, API terms, developer policy, automation policy, fair-use policy or rate limits of any Connected Application or other third-party system;

(b) circumvent, disable or defeat any anti-automation measure, CAPTCHA, bot detection, device fingerprinting, throttling or access control operated by a third party;

(c) scrape, crawl, harvest or systematically extract data from any system, website or service, or build or enrich a dataset by such means, other than where you are expressly permitted to do so by the operator of that system;

(d) access, or attempt to access, any computer resource, account, network, data or system without authorisation, or exceed authorised access — conduct which may constitute an offence or a civil wrong under section 43 and section 66 of the Information Technology Act, 2000, among other laws;

(e) probe, scan or test the vulnerability of any system or network without written authorisation from its owner (see also clause 9(g));

(f) use the Service to pivot, chain or move laterally between systems — for example, using access granted to one Connected Application to discover, obtain or use credentials, tokens, links or access paths into another system, whether that system belongs to you or to a third party; or

(g) re-identify, de-anonymise or cross-reference data in order to defeat a privacy control applied by a third party.

You are responsible to the provider of each Connected Application for what the Service does in it. Providers may throttle, restrict, suspend or terminate your account for automated access; that risk is yours under the Terms.

5. Communications¶

The Service can send email and messages as you. Everything you would have to comply with when sending manually, you must comply with when the Service sends.

You must not use the Service to:

(a) send unlawful, unsolicited or non-consensual bulk communications of any kind, by any channel;

(b) send commercial communications to a recipient who has not given the consent, or in respect of whom you do not hold the lawful basis, required by the law applicable to that communication;

(c) ignore, delay, obstruct or fail to honour an opt-out, unsubscribe, "stop" or do-not-contact request, or re-add a person who has opted out;

(d) forge, spoof, falsify or obscure a sender identity, a return path, a header, a domain, a display name or a reply-to address, or otherwise misrepresent the origin of a communication;

(e) send phishing, pretexting, credential-harvesting or social-engineering communications, whether for testing, training or any other purpose, without documented written authorisation from the organisation whose people are the targets; or

(f) conceal a material fact about the nature or purpose of a communication where disclosure is required.

5.1 India — TRAI, UCC and DND¶

Where a communication is directed to a recipient in India, you must comply with the Telecom Regulatory Authority of India framework governing unsolicited commercial communications, including the Telecom Commercial Communications Customer Preference Regulations, the applicable Do Not Disturb registration and preference scrubbing requirements, header and content-template registration on the distributed-ledger (DLT) platform where applicable, permitted calling and messaging time windows, and the consent-acquisition and revocation requirements set out in that framework. This applies to SMS, voice and any other channel within its scope.

5.2 Other jurisdictions¶

Where a recipient is located outside India, you must comply with the electronic-communications, direct-marketing, consent, disclosure, sender-identification and opt-out requirements of the law applicable in that recipient's jurisdiction. Determining which laws apply to your communications, and complying with them, is your responsibility. We make no representation that the Service is configured for, or compliant with, the marketing or communications law of any particular jurisdiction.

6. Impersonation and disclosure¶

You must not use the Service to:

(a) impersonate any person or organisation, or falsely state or imply an affiliation, endorsement, employment, agency or authority you do not have;

(b) create or operate a synthetic persona, profile, voice or likeness of a real person, whether living or dead, or generate communications purporting to come from a real person who has not authorised them;

(c) impersonate Daemon AI LLP, DaemonOps, our personnel, or any Connected Application, Model Provider or other third party, or suggest that a communication or output is officially from or endorsed by any of them; or

(d) present AI-generated or AI-assisted communications as human-authored where disclosure is required by applicable law, by the terms of the platform on which the communication is sent, by a professional or regulatory obligation binding on you, or where the absence of disclosure would materially mislead the recipient.

6.1 Where the disclosure line falls¶

Our disclosure rule has two parts:

(a) No AI disclosure is required for a communication that a human has reviewed and sent. Where an individual reviews the content before it leaves and then sends it, that person has authored the act of sending, and the communication is that person's.

(b) AI disclosure is required for autonomous outbound communication — a communication dispatched without a human reviewing it before it left. In that case no human stood behind the specific words at the moment of sending, and the recipient must be told.

This rule maps onto the Service's own Approval Gate and Autonomy Level architecture. Where you operate a class of outbound communication at an Autonomy Level that permits execution without human review, you must configure that class to carry a disclosure.

This is a floor, not a ceiling. It does not displace any stricter disclosure duty imposed on you by law, by a regulator, by a professional obligation, or by the terms of the platform on which the communication is sent, and it does not displace clause 6(d) where the absence of disclosure would materially mislead the recipient. You must determine and apply the disclosure standard appropriate to your industry, your regulators, your platforms and your recipients, and configure the Service accordingly. The Service does not make that determination for you.

7. Consequential decisions about people — human review is mandatory¶

You must not use the Service as the sole or determinative basis, without meaningful human review, for any decision that has a legal effect on an individual or that similarly significantly affects an individual.

This applies, without limitation, to decisions concerning:

(a) Employment — hiring, screening, shortlisting, ranking, rejection, assignment, compensation, promotion, discipline, performance rating, redundancy selection or termination;

(b) Credit and lending — eligibility, approval, denial, limits, pricing, collections or default classification;

(c) Insurance — underwriting, eligibility, pricing, exclusions, claims acceptance, claims denial or fraud classification;

(d) Housing and tenancy — tenant selection, referencing, eviction or renewal;

(e) Education — admission, placement, assessment, progression, disciplinary action or exclusion;

(f) Healthcare — diagnosis, triage, treatment selection, medication, escalation or denial of care;

(g) Legal rights, benefits and entitlements — eligibility determinations, benefit grant or withdrawal, immigration or visa outcomes, and any determination affecting a person's legal position; and

(h) Anything irreversible affecting an individual — including any action that cannot practically be undone and that materially affects a person's rights, livelihood, safety, reputation or access to a service.

7.1 What "meaningful human review" means¶

A review is meaningful only if the reviewing individual has the authority to reach a different conclusion, has access to the information needed to do so, has the competence to evaluate it, and has the time to exercise judgement. Confirming an Approval Gate without reading what is being approved is not meaningful review, and does not satisfy this clause.

7.2 Configuration obligation¶

Where you use the Service in any of the areas listed above, you must configure Approval Gates for the relevant Agent Actions and set Autonomy Levels accordingly. Operating those workflows at an Autonomy Level that permits autonomous execution is itself a breach of this Policy.

8. Data-category restrictions¶

The Service is not configured or contracted for the categories of data below. You must not cause or permit any of the following to be provided to, ingested by, processed by, generated by or stored in the Service, or to be reachable within any Authorisation Scope you grant, except under a prior written agreement with Daemon AI LLP that expressly covers that category.

8.1 Special-category and sensitive data¶

Without prior written agreement, you must not process through the Service:

health, medical or clinical data;
biometric or genetic data, including facial-recognition templates and voiceprints;
data revealing sexual orientation or sex life;
data revealing religious belief, caste, tribe or ethnic origin;
data revealing political opinion, affiliation or trade-union membership;
criminal convictions, charges, allegations or offence data;
precise geolocation of individuals;
financial account numbers, payment card data, or any data within the scope of a payment-card security standard; or
government-issued identifiers of any kind, including PAN, passport, driving licence, voter and social-security numbers.

8.2 Aadhaar and UID data — prohibited outright¶

You must not provide, transmit, upload, store, display, process or cause the Service to access any Aadhaar number, Virtual ID, Aadhaar-linked authentication data, e-KYC data, core biometric information, or any other identity information within the meaning of the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016.

This prohibition is absolute. It is not subject to the "prior written agreement" exception in clause 8, and clause 24.4 of the Terms confirms that it cannot be relaxed by an Order Form or by any other agreement between us.

The basis for it is broader than the Aadhaar Act alone, and we state it plainly.

(a) The Aadhaar Act, 2016. Section 29 restricts the sharing and use of core biometric information and identity information, and section 37 makes intentional disclosure of identity information in contravention of the Act a punishable offence. Both provisions are directed principally at information collected under the Act, or in the course of enrolment or authentication. Neither is a complete answer to an Aadhaar number that is simply sitting in a customer's own records system, and we do not claim otherwise.

(b) The Aadhaar (Sharing of Information) Regulations, 2016, which restrict the sharing, publication and display of Aadhaar numbers and of identity information by requesting entities and others handling it.

(c) The position after K.S. Puttaswamy (Aadhaar-5J) v. Union of India, (2019) 1 SCC 1, in which section 57 of the Aadhaar Act was struck down insofar as it permitted private entities to require Aadhaar authentication under a contract. A private commercial arrangement is not a lawful foundation for making Aadhaar the basis of identification or authentication, and this Policy will not be read as creating one.

(d) Section 66C of the Information Technology Act, 2000, which makes fraudulent or dishonest use of another person's electronic signature, password or any other unique identification feature an offence. That provision reaches misuse of an Aadhaar number wherever it is held, without the enrolment or authentication limitation that constrains sections 29 and 37 of the Aadhaar Act.

(e) Our own risk position. Independently of any of the above, the Service is not built, tested, contracted or insured to handle Aadhaar and UID data, and we will not accept it. That is a sufficient basis for the prohibition on its own.

If Aadhaar or UID data is present in a system you intend to connect, you must exclude it from the Authorisation Scope before connecting, and must not rely on the Service to filter it out.

8.3 Children's data¶

A child is any individual who has not completed eighteen years of age. That is the definition given by section 2(f) of the Digital Personal Data Protection Act, 2023. Section 9(1) of that Act then requires verifiable parental consent before a child's personal data is processed.

You must not cause or permit the Service to process the personal data of any child except under a prior written arrangement with Daemon AI LLP that expressly addresses that processing and the verifiable parental consent mechanism you operate.

In no circumstances — with or without any agreement, and with or without parental consent — may the Service be used for:

tracking or behavioural monitoring of children; or
targeted advertising directed at children.

Section 9(3) of the DPDPA 2023 prohibits those activities. The prohibition is not qualified by consent: parental consent does not make tracking, behavioural monitoring or targeted advertising directed at a child permissible.

It is, however, not unqualified in the abstract. Section 9(4) empowers the Central Government, by notification, to exempt prescribed classes of data fiduciary, and processing for prescribed purposes, from specified obligations of section 9, subject to such conditions as may be prescribed. That is a statutory exemption granted by the State. It is not something the parties can create between themselves.

No commercial arrangement between you and us can authorise any activity prohibited by section 9(3), we rely on no exemption under section 9(4), and we will not agree to any configuration that permits those activities. If you consider that a notified exemption under section 9(4) applies to you, that is a matter to be established with the Board and the relevant authority, and it does not alter this Policy or entitle you to operate the Service in that manner.

8.4 Your responsibility to know what is in scope¶

Granting an Authorisation Scope over a mailbox, a records system or a document store means granting access to whatever is inside it. It is your responsibility to know what categories of data exist in the systems you connect, to narrow the scope so that restricted categories are excluded, and to confirm that before connecting. We cannot inspect your systems for you, and the absence of a warning from us is not a clearance.

9. Governance integrity¶

The Service's oversight controls are the mechanism by which risk is managed. Interfering with them is a serious breach.

This clause applies from the date Part B of the Terms is activated for you. Where it refers to a control of the Service — an audit trail, an Approval Gate, an allow-list, a threshold or a rate control — it refers to that control as it is actually implemented and described in the Documentation. Nothing in this clause is a representation that any such control exists, exists in a particular form, or has a particular scope, retention or completeness. The Documentation is the binding description.

You must not, and must not permit any User to:

(a) disable, bypass, tamper with, delete, truncate, backdate, falsify or otherwise interfere with the audit trail or any audit or logging record produced by the Service, to the extent that such records are produced by the Service as described in the Documentation;

(b) remove, disable, weaken or circumvent an Approval Gate applicable to a consequential or irreversible Agent Action, or configure an Autonomy Level so as to achieve the same effect for such actions;

(c) structure, split, batch or sequence Agent Actions so as to evade an Approval Gate, an allow-list, a threshold or a rate control;

(d) attempt to escalate privileges within the Service, to access another customer's data, tenancy, configuration or Service Data, or to access any part of the Service you are not authorised to access;

(e) attempt to extract, reconstruct or exfiltrate the Service's system prompts, internal instructions, policies, guardrails, configuration, model weights or other non-public operating material;

(f) attempt, by prompt injection, adversarial or crafted input, poisoned content, jailbreaking, or any other technique, to induce the Service to act outside its Authorisation Scope, to ignore a Customer Instruction, to disregard an Approval Gate, or to behave contrary to this Policy; or

(g) conduct penetration testing, vulnerability scanning, red-teaming, load testing, denial-of-service testing or any other security testing against the Service, its infrastructure, or any third-party system reachable through it, without our prior written authorisation (and, for a third-party system, that system owner's written authorisation). Requests for authorisation should be sent to contact@daemonai.tech.

9.1 Reporting, not exploiting¶

If you discover a vulnerability, a permissions defect, a logging gap or any behaviour that appears to breach the Service's own governance controls, you must report it to contact@daemonai.tech promptly and must not exploit it, publicise it before we have had a reasonable opportunity to remediate, or use it to access data you are not entitled to.

10. Content and conduct¶

You must not use the Service or the Site to create, transmit, store, distribute or process:

(a) content that is unlawful under any applicable law, or that you are prohibited from holding or transmitting;

(b) content that infringes the copyright, trade mark, patent, design right, database right, trade secret, privacy right, publicity right or other right of any person;

(c) malware, ransomware, spyware, viruses, worms, logic bombs, exploit code, or any code or instruction designed to damage, disrupt, disable, degrade or gain unauthorised access to any system or data;

(d) content that harasses, bullies, stalks, threatens, defames or incites violence or hatred against any person or group, or that facilitates such conduct;

(e) content that facilitates fraud, deception, market manipulation, money laundering, terrorist financing, or the evasion of sanctions or export controls; or

(f) content that facilitates serious physical harm, including instructions for weapons, explosives or attacks on critical infrastructure.

10.1 Child sexual abuse material — zero tolerance¶

Any attempt to use the Service or the Site to generate, transmit, store, request, solicit or access child sexual abuse material, or any material that sexually exploits or endangers a child, will result in immediate and permanent termination without notice, preservation of all relevant records, and reporting to law enforcement and any other authority to which we are required or permitted to report. There is no notice period, no cure period and no appeal.

Reporting is not a discretionary policy choice on our part. It is a statutory duty. Sections 19 and 20 of the Protection of Children from Sexual Offences Act, 2012 require any person who has apprehension that an offence under that Act is likely to be committed, or knowledge that one has been committed, to report it to the Special Juvenile Police Unit or the local police — and section 20 places that duty specifically on persons in charge of a media, studio or photographic facility who come across material of that kind. Section 21 makes failure to report an offence in itself, punishable with imprisonment, with enhanced liability under section 21(2) for a person in charge of a company or an institution. Section 67B of the Information Technology Act, 2000 separately criminalises publishing, transmitting, creating, browsing, downloading and facilitating access to material depicting children in sexually explicit conduct.

We will report, we will preserve records for that purpose, and we will not give notice of the report where doing so could prejudice an investigation.

11. Model and Service restrictions¶

You must not:

(a) use the Service, its output or any material derived from it to train, fine-tune, distil, evaluate against, or otherwise develop a machine-learning model that competes with the Service or with any Model Provider's service, or in breach of a Model Provider's terms;

(b) reverse engineer, decompile, disassemble or attempt to derive the source code, architecture, prompts or training data of the Service, except to the extent such restriction is prohibited by applicable law;

(c) copy, frame, mirror, resell, rent, lease, sub-license, time-share, or provide the Service as a service bureau to any third party, or otherwise make the Service available to anyone other than your own Users, except as expressly permitted in an Order Form;

(d) remove, obscure or alter any proprietary notice, mark or attribution in the Service or the Documentation;

(e) benchmark the Service and publish the results without our prior written consent; or

(f) use the Service in a manner that imposes an unreasonable or disproportionate load on our infrastructure or on any Connected Application, or that interferes with any other customer's use of the Service.

12. Responsibility for your Users¶

You are responsible for the acts and omissions of your Users as if they were your own.

You must:

(a) ensure that every User is made aware of this Policy and is required to comply with it;

(b) maintain internal policies, role definitions and approval structures consistent with this Policy, and ensure that individuals who grant Authorisation Scopes or approve Agent Actions are authorised to do so;

(c) monitor use of the Service within your organisation, and investigate anomalies in the audit trail promptly; and

(d) promptly revoke Authorisation Scopes, disconnect Connected Applications, deactivate accounts and remove roles for any individual who leaves your organisation, changes role, or otherwise ceases to require the access — and in any event before that individual's departure takes effect where the departure is known in advance.

Stale scopes belonging to departed staff are one of the most common and most damaging failures in agentic deployments. Revocation is your obligation, not ours, and we have no visibility of your joiners-movers-leavers process.

13. Reporting abuse or misuse¶

Report any suspected breach of this Policy, any abuse of the Service, any security concern and any vulnerability to contact@daemonai.tech.

This is our only reporting address. Please include enough detail for us to investigate — what happened, when, the systems and accounts involved, and any relevant identifiers from the audit trail. We will acknowledge reports and investigate proportionately to the seriousness of what is reported. We may need to contact you for further information.

If a report concerns an urgent, in-progress harm — an active security incident, a live unauthorised access, or Agent Actions currently causing damage — say so in the subject line, and, if you are a Customer, invoke the emergency stop function described in the Documentation rather than waiting for our response.

14. Enforcement¶

14.1 How we respond¶

Our response is proportionate to the seriousness, the risk and the reversibility of the breach. We follow the ladder below, and we apply the narrowest measure that is effective, escalating only where the narrower measure is inadequate or where the risk does not permit it.

Steps 2 to 4 of this ladder describe measures that operate on a Customer's use of the Service, and they apply only from the date Part B of the Terms is activated for that Customer. The granular measures listed in Step 2 are available to the extent the Service implements them as described in the Documentation; where a granular measure is not available for a given breach, we escalate to the narrowest measure that is. Until Part B is activated, our response to a breach by a Site visitor or waitlist submitter is Step 1, the blocking of access to the Site under clause 8 of the Terms, deletion of a submission, and Step 5 where it applies.

Step 1 — Notice and cure. We give you written notice describing the breach and allow thirty (30) days to cure it. This is the default first step for a breach that is not urgent, not unlawful and not causing harm. Thirty days is the same cure period as applies under clauses 25.2 and 26.3(a) of the Terms.

Step 2 — Narrowest-scope suspension. Where the risk requires containment, we act at the narrowest effective level. In order of preference, and to the extent the relevant measure is available:

revoke a single Authorisation Scope or disconnect a single Connected Application;
disable a single Ops Pack, workflow or automation;
restrict or remove a single User's role, or lower an Autonomy Level;
restrict a class of Agent Action.

We suspend a connection or a role before we suspend an account.

Step 3 — Account suspension. Where narrower measures are inadequate, we suspend the account or the Service in whole, in accordance with the suspension clause of the Terms.

Step 4 — Termination. Where the breach is material and uncured, is incapable of cure, or is repeated, we terminate the agreement.

Step 5 — Reporting to authorities. Where required or permitted by law, or where the conduct involves serious criminality, we report to law enforcement, to a regulator or to another competent authority, and preserve relevant records for that purpose.

14.2 Emergency suspension¶

We may act immediately, at any level of the ladder and without prior notice, where we reasonably believe there is a security risk, unlawful activity, an imminent risk of harm to any person, system or data, a compromised credential, or a legal or regulatory requirement to act. We will notify you as soon as reasonably practicable afterwards and state the reason, unless prevented by law from doing so.

14.3 Emergency stop over in-flight Agent Actions¶

This clause applies from the date Part B of the Terms is activated for you, and describes the emergency stop function to the extent that it is implemented and described in the Documentation.

Where Agent Actions are in flight and are causing, or are likely imminently to cause, material harm, we may halt them to the extent the Service permits — cancelling queued actions, revoking active sessions and freezing execution.

We may do this without notice. The emergency stop is a containment measure: it prevents further actions from executing; it does not reverse, recall or undo any Agent Action that has already executed. Nothing in this clause is a commitment that any action can be stopped, or stopped in time, and nothing in it is a representation that the function exists in any particular form or with any particular coverage or latency. The Documentation is the binding description of it, and the Terms are explicit that Agent Actions may be irreversible.

Where the Documentation describes a customer-invocable emergency stop, Customers may invoke it themselves at any time as described there.

14.4 No obligation to monitor, and no waiver¶

We have no obligation to monitor your use of the Service for breaches of this Policy, and we do not do so as a matter of routine. Our failure to act on a breach, or a delay in acting, is not a waiver of our rights and does not preclude action on that or any other breach.

14.5 Consequences¶

Enforcement action under this clause does not relieve you of any obligation under the Terms, including any obligation to pay fees accrued or any indemnity obligation. We are not liable for any loss you suffer as a result of enforcement action properly taken under this Policy.

15. Changes to this Policy¶

We may update this Policy from time to time, and will publish the updated version at /legal/acceptable-use with a new version number and Last Updated date. Where a change materially and adversely affects a Customer, we will give notice in accordance with the changes clause of the Terms. Your continued use of the Site or the Service after an update takes effect constitutes acceptance of it.

16. Contact¶

Questions about this Policy, requests for authorisation under clause 9(g), and reports of abuse or misuse: contact@daemonai.tech.

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