Acceptable Use Policy

1. Purpose

This Acceptable Use Policy (“AUP”) sets out the workload-acceptance posture for the Service rented from Operator under the Terms of Service at /legal/tos. The AUP enumerates the workloads Operator does not permit on Operator-procured infrastructure, the operator-side response process for credible reports of an AUP violation, and the operator-side response process for jurisdictional requests received in relation to the Service.

The AUP forms part of the Terms. Customer accepts the AUP as a condition of Service use. Counsel finalises the AUP wording before deploy; the placeholder posture below is operator-side intent, not counsel-finalised text.

2. Hard-list of prohibited workloads

The following workloads are not permitted on Operator-procured infrastructure under any circumstance, regardless of the Customer’s account standing, the procured-infrastructure jurisdiction selected, or the asset used to settle the Order. The hard-list is non-negotiable; an Order that surfaces a hard-list workload is grounds for immediate suspension under section 5 and termination under section 6.

2.1 Child sexual abuse material

Hosting, distribution, indexing, transmission, mirroring, archival, or any other operational involvement with material depicting the sexual abuse or exploitation of minors. The prohibition is absolute. Operator cooperates fully with law-enforcement requests on this category subject to the cross-border jurisdictional posture in section 7.

2.2 Terrorism-facilitation workloads

Hosting, distribution, indexing, transmission, or operational support for material that incites, recruits for, finances, or otherwise materially supports a terrorist organisation listed in the operator-disclosed sanctions and counter-terrorism schedule of the operator’s home jurisdiction. Counsel finalises the schedule reference before deploy.

2.3 Active malware command-and-control

Operating infrastructure as the active command-and-control endpoint for a malware family — meaning the live operational endpoint that infected systems beacon to and receive commands from. The prohibition covers the live C2 endpoint specifically; security-research workloads that analyse, sandbox, or sinkhole malware traffic are not within the prohibition and require operator-side notification under section 4.

2.4 Phishing infrastructure

Hosting credential-harvesting pages that impersonate a third-party brand or institution, hosting the back-end inboxes that collect harvested credentials, or operating the redirector chain that funnels visitors into a phishing landing page. The prohibition applies regardless of the credential type harvested (banking, email, exchange, social, government).

2.5 Fraud and credential markets

Operating a marketplace that traffics in stolen credentials, stolen payment-card data, stolen identity documents, fraudulently-obtained accounts, or any other unauthorised-access primitive. The prohibition extends to the operator-side hosting role for the marketplace front-end, the back-end database, the escrow component, and any ancillary support workload (payment, communication, dispute-resolution).

2.6 Non-consensual intimate imagery

Hosting, distribution, indexing, mirroring, archival, or any other operational involvement with intimate imagery of an identifiable adult subject hosted, distributed, or indexed without that subject’s freely-given, specific, informed, and revocable consent. The prohibition applies whether the imagery is authentic or synthesised, whether the subject is publicly identifiable or known only to the uploader, and regardless of the asserted source.

2.7 Network-abuse workloads

Operating the Service as a deliberate denial-of-service amplification surface, the deliberate origin of unsolicited bulk email outside opt-in marketing channels, a deliberate scan-and-exploit endpoint targeting third-party infrastructure without authorisation, or any other workload that systematically degrades the network experience of identifiable third parties. Counsel finalises the enumerated event list before deploy.

3. Anti-takedown stance and jurisdictional request processing

Operator processes only legally-binding requests from courts of competent jurisdiction. “Court of competent jurisdiction” means a court of the Russian Federation, the Republic of Belarus, the Republic of Kazakhstan, or the operator’s home jurisdiction. Requests originating outside these jurisdictions are processed only when accompanied by the customary mutual-legal-assistance instrument that binds the operator’s home jurisdiction to the requesting jurisdiction. Counsel finalises the MLA reference before deploy.

Operator does not process DMCA-format notices. The Digital Millennium Copyright Act is a statutory instrument of the United States; the Operator’s home jurisdiction and the procured-infrastructure jurisdictions are not subject to the DMCA’s notice-and-takedown regime. A DMCA-format notice received by Operator is acknowledged as received and is not actioned. The acknowledgement is recorded in the operator-side log of received notices for audit purposes; the underlying Service is not suspended on the basis of a DMCA-format notice alone.

Operator does not process US-process civil discovery requests, US-process subpoenas, or US-process administrative orders absent the customary MLA instrument referenced in section 3 paragraph 1. Direct-from-claimant correspondence is not processed; Operator processes only the structured request format issued by a court of competent jurisdiction. Counsel finalises the structured-request schema before deploy.

Operator does not process informal takedown requests from private claimants, regardless of the channel (email, support ticket, phone, postal mail). A claimant seeking removal of a Customer-hosted resource is directed to seek an order from a court of competent jurisdiction and to serve that order on Operator through the legal contact channel listed in the operator footer. The brand stance is processor neutrality on private-claimant disputes; Operator does not adjudicate civil disputes between private parties.

4. Operator-side notification process

Customer notifies Operator before deploying any workload that overlaps in form with a hard-list category but does not, on examination, fall within the category — for example, a security-research workload that handles malware artefacts under section 2.3, or an academic research workload that mirrors prohibited material for institutional-review-approved analysis. The notification is sent to the legal@ alias listed in the operator footer.

Operator reviews the notification and confirms whether the workload is permitted on the procured-infrastructure jurisdiction selected. The review is conducted within a reasonable time of receipt; the timeline is operator-disclosed in the response and is not pre-committed in this AUP. Customer does not deploy the workload pending Operator’s confirmation.

5. Suspension on reasonable suspicion

Operator may suspend the Service on reasonable suspicion of a hard-list violation pending investigation. The suspension is logged in the operator-side log with the operator’s reasoning, the timestamp, and the IP-blocking detail. The Customer’s account email is notified of the suspension. The Customer’s data is preserved during the suspension period subject to the data-retention schedule at /legal/privacy.

The Customer’s response window is the operator-disclosed window — pre-launch placeholder pending Operator’s confirmation of the operationally appropriate window. The Customer responds through the legal@ contact channel listed in the operator footer. Operator reviews the response and either lifts the suspension, escalates to termination under section 6, or continues the suspension pending further investigation.

6. Termination on confirmed violation

Operator terminates the Service on confirmation of a hard-list violation. Termination is final; the Customer’s data is destroyed per the data-retention schedule at /legal/privacy after the termination notice issues. The termination notice is sent to the Customer’s account email; the notice references the hard-list section and the confirming evidence as recorded in the operator-side log. Counsel finalises the evidence-disclosure scope before deploy.

Operator may terminate the Service on a repeat-offender threshold for non-hard-list AUP violations. The threshold is operator-disclosed in the termination notice and is not pre-committed in this AUP. Counsel finalises the repeat-offender threshold language before deploy.

7. Cooperation with law enforcement

Operator cooperates with law-enforcement requests received from a competent authority of the operator’s home jurisdiction or a procured-infrastructure jurisdiction. Cooperation is limited to the data inventory disclosed in the Privacy Policy at /legal/privacy and to the response format specified in the request. Operator does not anticipate or pre-position data to facilitate cooperation that has not been formally requested.

Operator does not cooperate with informal law-enforcement liaison requests absent a formally-issued instrument. The brand stance is on-the-record cooperation only; off-the-record liaison is not within the operator-side response surface. Counsel finalises the formal-instrument schema and the liaison-rejection language before deploy.

8. Reporting an AUP violation

A third party may report an AUP violation by emailing the abuse@ alias listed in the operator footer. The report includes the affected resource (URL, IP, port), the violated AUP section, and any evidence the reporter elects to disclose. Operator acknowledges the report on receipt and reviews it under section 5. Operator does not disclose the outcome to the reporter beyond the bare confirmation that the report was received and reviewed.

Operator does not act on bulk-submitted reports issued by an automated abuse-reporting platform unless the report is accompanied by independently-reviewable evidence. The brand stance is on the substance of the violation, not the volume of the reporting. Counsel finalises the bulk-report disposition language before deploy.