Acceptable Use Policy
Version: Draft 1 — 2026-09-10 Governing law: Hong Kong SAR
Status of this document. This is a competent working draft prepared for review by Hong Kong–qualified counsel before it is published or relied on. It has not been reviewed by a lawyer.
This policy forms part of the Terms of Service. It applies to you, to anyone using your API key, and to your end users. You are responsible for all of them.
Read section 1 carefully. Breaching section 1 ends your account immediately and may be reported to the police.
1. Absolute prohibitions
These three are not policy preferences and are not negotiable. There is no warning, no strike count, no appeal on the merits, and no refund. Detection results in immediate termination, preservation of the associated records, and referral to the Hong Kong Police Force or another competent authority where the law requires it or where we judge it appropriate.
1.1 Minors
You must not use the Service to generate, request, attempt, or assist in generating any sexual or sexualised depiction of a person under 18, whether or not that person is real.
This covers, without limitation:
- prompts describing a child, a minor, or any person under 18 in a sexual context;
- prompts using age-coded language — "schoolgirl", "loli", "shota", "teen", "underage", "barely legal", stated ages under 18, school-uniform-and-sex framings, and equivalent terms in any language — to obtain a youthful sexualised depiction;
- uploading an image of a minor as an input to any model, for any purpose, including as a style, pose or background reference;
- uploading an image of an adult and prompting for a de-aged, child-like or pubescent result;
- any attempt to circumvent a refusal in order to reach one of the above.
Hong Kong law is directly engaged. The Prevention of Child Pornography Ordinance (Cap. 579) criminalises the production, publication and possession of child pornography, and its definition expressly covers depictions made or generated by electronic means whether or not the depiction is of a real person. Synthetic material is not a loophole. The Crimes Ordinance (Cap. 200) contains further offences concerning children and young persons. Where material is produced elsewhere, the law of that place applies to it as well.
We prohibit any sexualised depiction of a person under 18 regardless of statutory age definitions in any jurisdiction. Our contractual line is 18, and it does not move.
If you encounter such material through the Service, report it to [ABUSE_EMAIL] immediately. Do not download it, do not forward it, and do not retain a copy for evidence unless a law enforcement agency instructs you to.
1.2 Non-consensual intimate images
You must not use the Service to generate a sexual or intimate depiction of a real, identifiable person who has not given documented consent for that depiction.
This covers, without limitation:
- uploading a photograph or video of an identifiable person and generating sexual content from it — the primary route is the image input on image-to-video models, and it is the vector we watch most closely;
- "nudifying", undressing, or sexualising an image of a real person;
- generating a sexual depiction of a named public figure, celebrity, politician, streamer, colleague, classmate, former partner, or anyone else, from a prompt alone;
- generating a depiction from material that was itself obtained by voyeurism, hacking, or breach of confidence;
- generating sexual material as a means of harassing, coercing, humiliating, extorting or "sextorting" a person.
The Crimes (Amendment) Ordinance 2021 inserted offences into the Crimes Ordinance (Cap. 200) covering voyeurism, the unlawful recording or observation of intimate parts, the publication of images originating from such recording or observation, and the publication or threatened publication of intimate images without consent. The definition of an intimate image for these purposes extends to images that have been altered. Producing a synthetic intimate image of a real person and publishing it, or threatening to, can therefore fall squarely inside these offences.
1.3 Real people's likeness without documented consent
Beyond intimate images, you must not use a real, identifiable person's face, body, voice or distinctive likeness in adult output unless you hold their consent.
The consent must be:
- documented — a written, dated record you can produce to us on request;
- specific — to adult synthetic content, describing the kind of material covered. General model-release language for a photoshoot is not consent to sexual synthetic depiction;
- informed — the person understood that machine-generated sexual material would be produced from their likeness;
- from an adult — verified as 18 or over at the time of consent, with the basis of that verification recorded;
- revocable — with a route for the person to withdraw consent, and a process on your side to stop generating and take down existing material when they do.
You must retain these records for as long as you generate from that likeness, and for at least seven years afterwards. You must produce them to us within five business days of a request. Failure to produce them is treated as an admission that consent does not exist, and the account is suspended.
Performer consent is your record to keep. We do not hold it, do not verify it, and do not act as a records custodian for it. This service is not operated under, and makes no claim to comply with, the United States record-keeping regime at 18 U.S.C. §2257. If you distribute into the United States, satisfying that regime is your problem and you should take US advice on it.
2. Other prohibited uses
Breaching this section will get you suspended or terminated, depending on severity and repetition.
2.1 Unlawful and violent content
- Content depicting non-consensual sexual activity presented as real, or that promotes or normalises sexual violence.
- Content depicting bestiality, incest involving a real identifiable family, or sexual content involving a corpse.
- Content depicting or promoting human trafficking, sexual exploitation, or prostitution of a coerced person.
- Content depicting extreme violence, torture or mutilation in a sexual context.
- Anything else that is a criminal offence to produce or possess where you or your users are.
2.2 Deception and fraud
- Presenting generated material as an authentic photograph or recording of a real event or person.
- Producing material for a romance scam, catfishing operation, fake dating profile, fake escort listing, or any scheme to obtain money or personal data by deception.
- Producing material to impersonate a person, a company or a public authority.
- Producing sexual content of a real person for the purpose of blackmail or reputational attack.
2.3 Harassment
- Producing content targeting a specific person to intimidate, degrade, threaten or harass them.
- Producing content that doxxes a person, or that is combined with their personal data in a way engaging the doxxing offences under the Personal Data (Privacy) (Amendment) Ordinance 2021.
- Producing content that vilifies a person or group on the basis of race, sex, disability, family status, sexual orientation, religion or nationality.
2.4 Unlawful distribution
- Distributing output where adult material is unlawful.
- Distributing output to anyone under 18, or through a channel you cannot age-gate.
- Publishing output in Hong Kong without complying with the Control of Obscene and Indecent Articles Ordinance (Cap. 390) — including the prohibition on publishing an obscene article at all, and the statutory conditions on publishing an indecent article, which include not publishing to a person under 18 and displaying the prescribed warning notice.
- Uploading output to a platform whose terms prohibit it, or to a platform where minors are present.
2.5 Circumventing safety controls
- Prompt injection, jailbreaking, encoding, transliteration, character substitution or any other technique intended to obtain output that a refusal has already denied you.
- Splitting a prohibited request into pieces that are individually innocuous.
- Re-encoding, cropping, watermark-stripping or re-hosting an input in order to defeat the hash denylist.
- Rotating accounts, keys, IP addresses or payment methods to evade a suspension, a rate limit, or the abuse counter.
- Automated probing of the safety filter, including systematic retry loops against refusals. Refused generations are refunded; that refund is a courtesy for genuine mistakes, not a budget for testing where the line is.
- Scraping, reverse-engineering, or benchmarking the Service to reconstruct the underlying models.
2.6 Resale and misrepresentation
- Reselling access without making clear to your customers that the material is AI-generated and synthetic.
- Claiming or implying that we endorse, verify, moderate, review or approve your product or its output.
- Claiming that your product is age-verified, consent-verified or compliance-verified because it uses our API. It is not. We verify none of those things about your end users.
- Presenting our safety filters to your customers as a guarantee of anything.
- Using our name, marks or the name of any upstream provider without written permission.
- Sub-licensing an API key to a third party, or operating a shared key across unrelated businesses.
2.7 Technical abuse
- Exceeding published rate or concurrency limits, or engineering around them.
- Using the Service to attack, overload or degrade any system, ours or anyone else's.
- Uploading input containing malware, or crafted to exploit a decoder.
- Using the Service through an anonymising layer for the purpose of defeating our logging.
3. Your obligations
Using this API means running a compliance function. These are the minimum requirements.
3.1 Age assurance for your users. The Service performs no age verification of your end users. None. It has no such feature. You must operate age assurance yourself, appropriate to sexually explicit material, at least as strict as the law of every jurisdiction you serve requires, and auditable. Be ready to explain to us, for any given user, how they were assessed.
3.2 Consent records. Where you generate from a real person's likeness, keep the records described in section 1.3 and produce them on request.
3.3 Your own terms. Bind your users to restrictions at least as strict as this policy, and keep the ability to enforce them.
3.4 Your own abuse handling. Publish a reporting route, staff it, act on reports quickly, and be able to suspend a user of yours the same day.
3.5 Human review. Do not run a fully unsupervised pipeline from arbitrary user input to public distribution. Something on your side must be able to catch what the filters miss.
3.6 Escalate to us. If you find CSAM, NCII, or credible evidence that a user is attempting either, tell [ABUSE_EMAIL] and do not simply handle it quietly on your side.
3.7 Label your output. Tell your users the material is synthetic.
4. What we log, and why
For every generation we record and retain:
| Recorded | Why |
|---|---|
| The full prompt text | To investigate reports, identify attempts at prohibited content, and evidence a referral |
| A SHA-256 digest of each input media reference | To match against the denylist, correlate repeat submissions, and enforce takedowns |
| The client IP address of the request | To attribute activity and identify evasion across accounts |
| The account and API key that made the request | Attribution and enforcement |
| The outcome, including any policy rejection | To operate the abuse counter |
These records are kept longer than the generated assets are, which are deleted after about 30 days. They are kept so we can investigate abuse, answer a lawful request from a Hong Kong authority, and defend ourselves. They are handled under the PDPO as described in the Terms of Service.
We do not use prompts, inputs or outputs to train models.
5. The hash denylist and what it does not do
We keep a denylist of SHA-256 digests. Every generation request is checked against it before anything is dispatched. A match fails the request with invalid_input_file, is never sent upstream, and is never charged.
Read this next part. It is a real limitation and we would rather you understood it than assumed a protection you do not have.
Input media reaches us in two forms, and the digest means something different for each:
- Inline inputs — a data URI or a base64 blob — are hashed by content. Denylisting one of these genuinely blocks that exact image, whoever submits it, under whatever filename.
- URL inputs are hashed by reference. We digest the URL string, not the bytes it points at. That is an audit and correlation key, not a content fingerprint.
The consequences, stated plainly:
- Re-hosting a denylisted image at a different URL defeats the denylist entirely.
- Adding a query parameter to the URL defeats it.
- Two different URLs serving byte-identical media produce two unrelated hashes.
- One URL whose content changes after submission keeps the same hash, so what we recorded is no longer what was processed.
- Re-encoding or cropping an inline image produces a different digest and defeats the denylist for that image too.
So blocked_hashes means "block this exact reference or this exact inline payload". It does not mean "block this image". Do not design your compliance process on the assumption that a reported image cannot come back. Your own controls have to be the ones that catch it.
Generated outputs are not fingerprinted at all. The lever for an output is a takedown by asset identifier — send it to [ABUSE_EMAIL] and we will delete the object and its record, after which every previously issued link to it stops working.
6. Enforcement
We enforce in this order, but we skip straight to the bottom for anything in section 1.
6.1 Automated suspension. The Service counts content-policy rejections per account over a rolling window. Crossing the threshold suspends the account immediately, across every key, with no prior notice and no human in the loop. The current settings are 25 rejections in 24 hours; both values are configuration and may change without notice. A suspended account can neither generate nor read the API.
6.2 Manual review. A suspension, a report, or our own monitoring may trigger a review of the account's prompts, input digests and IP history. We may ask you for your consent records or your age assurance process. Not answering within five business days keeps the suspension in place.
6.3 Reinstatement. Write to [ABUSE_EMAIL]. If we reinstate you, the violation counter is reset from that moment so the old violations do not immediately re-trip it. Reinstatement is discretionary and we may decline without giving reasons.
6.4 Termination. Repeated violations, a single serious violation, refusal to cooperate with a review, or any breach of section 1 ends the account. Credits are not refunded. Keys stop working immediately. Assets are deleted. The records in section 4 are retained.
6.5 Referral to authorities. Where we hold material or records indicating a criminal offence — in particular under Cap. 579, Cap. 200 or Cap. 390 — we will preserve the relevant records and refer the matter to the Hong Kong Police Force or another competent authority. We do this whether or not you are in Hong Kong. We may be legally required to do it and we do not need your consent.
6.6 Denylisting. Digests of inputs involved in a serious violation are added to the denylist, subject to the limitations in section 5.
6.7 No compensation. We do not compensate you for a suspension or termination under this policy, including one triggered automatically, and including one later reversed on review.
7. Reporting abuse
Send reports to [ABUSE_EMAIL].
Include, as far as you can:
- what you found, in plain terms;
- the asset identifier or signed link, or the generation identifier;
- when you saw it and where;
- for a likeness or NCII complaint, who the person is, your relationship to them, and any evidence that the depiction is of them;
- how we can reach you.
Do not attach suspected child sexual abuse material to your report. Describe it and give us the identifier. We will locate it ourselves.
Targets of published intimate images can report to us at the same address and can also complain to the Office of the Privacy Commissioner for Personal Data or report to the Hong Kong Police Force. We will act on a credible report without waiting for either.
We aim to acknowledge every report within two business days, and to act on reports engaging section 1 immediately on receipt.
Copyright complaints follow the separate notice-and-takedown process in clause 11 of the Terms of Service and should go to [LEGAL_EMAIL].