Child safety · each::labs

1. Our Commitment

each::labs gives businesses API access to AI models for images, video, audio and text. We have zero tolerance for child sexual abuse and exploitation.

No one may use each::labs to create, request, upload, store or share child sexual abuse material (CSAM), or to sexualize, groom or exploit a child in any way.

We report apparent child sexual abuse material that we find to the National Center for Missing & Exploited Children (NCMEC), as the law requires. We review other signs of child sexual exploitation and report them to NCMEC when 18 U.S.C. § 2258A requires or allows it.

This page applies to every customer, organization, account, API key, end user, model and request on each::labs, including our own products and our own team.

Protecting children comes first. When child safety conflicts with speed, cost or convenience, child safety wins.

2. What Is Prohibited

These rules cover prompts, inputs, outputs, files and links on every model and workflow. The following are prohibited:

Child sexual abuse material (CSAM) in any form. This includes material that is AI-generated, edited, synthetic, drawn or animated.
Sexualization of minors in any form, including text. This covers sexual descriptions, stories, role-play or chat involving anyone under 18, or anyone presented as under 18.
Grooming, sextortion and trafficking. This includes enticing or coercing a child, and creating messages, scripts or images for any of these.
Nudifying or "undressing" anyone under 18. This includes editing an image of a child to make it sexual.
Real children's images in sexual contexts. This includes using a real child's photo, face, voice or likeness in sexual or sexualized content, such as face swaps and deepfakes.
Tools built for abuse. This includes models, LoRAs, workflows and prompts designed or tuned for any of the above.
Attempts and circumvention. An attempt is a violation, even if it fails or we block it. So is trying to get around our checks or a provider's safety system to do any of the above, for example by rewording a blocked prompt, splitting a request, using coded language or switching models.

No purpose makes any of this acceptable. Fiction, art, research and testing are not exceptions.

3. How We Prevent It

Clear rules. This page, our Terms of Service and our Acceptable Use Policy prohibit child sexual abuse and exploitation. Accounts are for adults only: you must be 18 or older to hold one.
Requests are recorded. Every request to api.eachlabs.ai that runs a model or a workflow is recorded with the organization and the credential it was sent with, and must carry an end-user ID once the rules in Section 7 apply to that organization. When a check runs on a request, we store what it found and what we did. Section 4 says which checks are on.
Identifiers for model providers. For some providers, we send a pseudonymous identifier with requests, so that most safety actions by those providers can be traced to the organization, API key or request they concern.

4. How We Detect It

We are rolling out automated detection, starting with images. It is not on yet. When it is on, images sent to our image and video models, and images those models generate, will be checked against lists of known child sexual abuse material and by an abuse classifier, using Safer by Thorn. Video will follow.

Images: Safer by Thorn, not on yet. When it is on, it will match images against lists of known child sexual abuse material, and Thorn's classifier will check for new and AI-generated material that no list contains yet.
Reports and review. No single check catches everything, and some content cannot be scanned, for example some file formats or files that are too large. A person reviews each flag before we report it, and we act on reports from anyone.

Safer by Thorn (safer.io). Detection of child sexual abuse material for online platforms.
Thorn (thorn.org). The nonprofit that builds technology to defend children from sexual abuse.

5. What Happens When Content Is Flagged

When our checks flag possible child sexual abuse or exploitation, or someone reports it to us, we take the steps below that apply. None of them waits for a warning or for the customer to reply.

Remove from public access. We remove our copies of the flagged material from public access, including from our CDN. The material is not deleted at this step: we keep it as evidence.
Preserve. We copy the material and the related records, such as the organization, which API key was used, the end-user ID, the request, the model, timestamps and file hashes, into separate evidence storage. Retention and deletion settings do not apply to that copy.
Suspend. If your organization or one of its members is responsible, we will suspend your organization. If an end user of your product is responsible, you must ban that user (Section 7). The controls on our side that suspend organizations and block end-user IDs are not on yet. We are rolling them out. Section 6 sets out the enforcement.
Confirm. A person reviews each flag in a separate review tool before we report it or close an organization. No one downloads, copies or forwards suspected material outside our review and reporting systems. If a review finds that a flag was wrong, we will lift any suspension it caused.
Report. We report to the NCMEC CyberTipline in the cases Section 8 describes, as soon as reasonably possible.
Notify. We will email the organization's owners which API key, end-user ID and requests were involved and what we did, unless the law or law enforcement requires us not to. Where the law and our agreement with the customer leave us the choice, we also do not tell them when telling them could put a child at risk or harm an investigation. We never send the material to the organization.

6. Enforcement: No Warnings

We do not give warnings and we do not give second chances for child sexual abuse material or for attempts to create it. This table, with the paragraphs below it, sets out what we do in each case and what you must do then. The controls on our side that suspend organizations, block end-user IDs and reject requests without an end-user ID are not on yet. We are rolling them out.

What happened	What we do	What you must do
Your organization, one of its members or one of its API keys sends, requests or generates child sexual abuse material, or tries to. A flagged request with no end-user ID counts as your organization's own.	We remove the flagged material from public access, preserve it and report as Section 8 describes. We suspend your organization. Once the case is confirmed, we permanently close the organization and every account in it.	Nothing. The decision is final. You may not open a new account.
An end user of your product sends, requests or generates child sexual abuse material, or tries to.	We remove the flagged material from public access, preserve it and report as Section 8 describes. Once blocking of end-user IDs is live, we can also permanently block that end-user ID for your organization. We will email your organization's owners, unless the law or law enforcement requires us not to. Where the law and our agreement with the customer leave us the choice, we also do not tell them when telling them could put a child at risk or harm an investigation.	Within 24 hours of the time we send our email: ban that user from your product, and send us that user's records (Section 7).
You miss the 24-hour deadline after our email for the ban or for the records, the records are incomplete or false, or you cannot identify the user.	Permanently suspend your organization: every account, member and API key in it.	Nothing. You may not open a new account.
A request that runs a model or a workflow arrives without an end-user ID.	Requests without one are not rejected today. Once these rules apply to your organization (Section 7), we can reject any of them at any time, without further notice: we switch this check on per organization. A workflow trigger is still accepted, and the step that would run a model fails instead. If your organization keeps sending requests without one, we can permanently suspend it (Section 7).	Send an end-user ID with every request that runs a model or a workflow (Section 7).
Your end-user IDs do not identify your real end users, for example a new random ID for each request, a placeholder such as anonymous or test, or another person's ID.	We ask you to show that you can identify the person behind each ID. If you cannot, we can permanently suspend your organization (Section 7).	When we ask, show us that you can identify the person behind each ID.
Your organization or one of its members tries to get around our child-safety checks or a block, for example by rewording a blocked prompt, splitting a request, switching models, or sending a blocked user's requests under a new end-user ID or without one. If an end user does this, the row above about an end user of your product applies instead.	We suspend your organization and permanently close it.	Nothing. The decision is final. You may not open a new account.

A closed or permanently suspended organization loses access to each::labs for good. Any new account opened for it, or on its behalf, is closed too. Section 10 of our Terms of Service governs any unused prepaid balance.

One confirmed attempt is enough for the enforcement above; there is no warning first. We may also suspend an organization for repeated attempts made through it.

If you believe we made a mistake of fact, such as acting on the wrong organization, API key or end user, write to safety@eachlabs.ai and we will review the facts. This review corrects mistakes of fact only. It does not change the rules above.

7. Platform Customers: End-User IDs and Records

If you build a product on each::labs, you are responsible for how your users use it. US law requires us to report apparent child sexual abuse material that we learn of to NCMEC (18 U.S.C. § 2258A). A report does the most to protect a child when it identifies the person responsible. When that person is your user, only you hold the records that identify them. That is why the end-user ID and records rules in this section are mandatory. They are set out in the End-user ID requirements page in our documentation (docs.eachlabs.ai/end-user-id). That page is a policy under Section 4 of our Terms of Service.

These rules apply now to every organization created at or after 00:00 UTC on 11 November 2026. For an organization created before then, they take effect on the dates given in the notice we email to its owners. That notice can give the organization more time before missing end-user IDs, or IDs that do not yet follow these rules, lead to suspension. It never gives more time for child sexual abuse material itself, or for sending a blocked person's requests under a new ID or without one.

End-user IDs

Send a stable per-user end_user_id with every request to api.eachlabs.ai that runs a model or a workflow. The same user always gets the same ID, and two users never share one. There are only two exceptions, both set out below: a shared ID for one business customer, and a job ID for an automated job.
Identify the last person in the chain. If your customers are businesses that serve their own users, require them to send you their end user's ID with every request and pass it to us.
If you use each::labs inside your own business, send the ID of the employee who made the request.
Exception for a business customer: you may send one shared ID for the users of a single business customer that refuses to give you per-user IDs. That is your risk: if we block the ID, everyone behind it is blocked, and you must still identify the person responsible within 24 hours of our email. Keep the time, IP address and any session or action ID of every request, so you can find the person who made it. Never share an ID across business customers or with your own direct users.
Exception for an automated job: for a job with no person behind it, send a job ID built from the ID of the employee who owns the job and the job's name. Use it only for work that no end user asked for.
Signed-out visitors are not an exception. Require sign-in. If you allow signed-out use anyway, send one stable ID per visitor, keep the records that let you identify that visitor, and accept that we permanently suspend your organization if a flagged visitor cannot be identified. When a visitor signs in, keep a record that links the visitor ID to the account, and never use the switch to get around a block.
You must be able to identify the person behind every request from the ID plus your own records.
Make the ID pseudonymous. Never use names, email addresses, phone numbers or IP addresses as the ID, hashed or not. Your own internal user ID, or a hash of it, works.
Make the ID unique across your whole platform. If your customers are businesses, put your direct business customer's ID in front of the complete value that customer sends you for its end user, including any prefixes of its own. Join them with a separator that cannot appear in your business customers' IDs, or hash the complete value after your prefix. Never use your API key or your organization ID as the ID.
Our documentation explains how to send the ID on each endpoint and how to choose it for your business. It also lists the endpoints that do not take the ID yet.

Records you must keep

For every end user, keep these records for at least one year after that user's last request through each::labs:

the end-user ID you sent us, and your own internal ID for that user;
the account details you hold for that user, such as username, email address, phone number and sign-up date;
the IP address, with date, time and time zone, of every request that user sent through each::labs;
the location, device identifiers and any age or identity verification result you hold for that user.

When one of your users is flagged

We will email your organization's owners the end-user ID, the request IDs, the time and the action we took, unless the law or law enforcement requires us not to. Where the law and our agreement with the customer leave us the choice, we also do not tell them when telling them could put a child at risk or harm an investigation.
Within 24 hours of the time we send that email, on any day of the year, you ban the user from your product, and you send us all of the records listed above for that user. Send them to safety@eachlabs.ai and confirm the ban in the same email.
If you miss the deadline, send incomplete or false records, or cannot identify the user, we permanently suspend your organization (Section 6).

Never send us the material itself. Records and IDs are enough. Do not copy, forward or attach it except as the law requires or NCMEC instructs you. Holding or sending it can be a crime. If the law requires you to report it to NCMEC, it also requires you to preserve what you report. Follow the instructions NCMEC gives you.

Your own duties

Prohibit child sexual abuse and exploitation in your own terms, and enforce them with your own controls, such as user verification, age checks where the law requires them, and bans.
Give your users a clear way to report child-safety concerns, and act on what they report. Tell us at safety@eachlabs.ai about anything that involves each::labs.
Keep child safety on. Turning off a model's NSFW filter, where our documentation allows it, never turns off these rules. Do not disable, weaken or work around our child-safety checks or any model provider's child-safety system.
Meet your own legal duties. If you provide an electronic communication service or a remote computing service, 18 U.S.C. § 2258A may require you to report apparent child sexual abuse material to NCMEC yourself. Our reports do not replace yours. Ask your counsel.

If you cannot meet these rules, do not send your users' requests to each::labs.

8. How We Report

We report apparent child sexual abuse material that we find to the CyberTipline run by the National Center for Missing & Exploited Children (NCMEC), as the law requires. We review other signs of child sexual exploitation and report them to NCMEC when 18 U.S.C. § 2258A requires or allows it.

This covers:

child sexual abuse material, whether real, edited or AI-generated;
requests to create sexual images or videos of a minor;
apparent grooming, enticement, sextortion or trafficking of a child.

US federal law requires us to report apparent child sexual abuse material, child sex trafficking and online enticement of children, and permits us to report facts that indicate such a crime involving child sexual abuse material may be planned or imminent (18 U.S.C. § 2258A(a)).

We report as soon as reasonably possible after we find an apparent case. If a child may be in immediate danger, we contact emergency services first.

Our reports include the information available to us, such as the organization, which API key was used (its ID, never the key itself), the model used, timestamps, file hashes and any end-user ID we hold for the request. We give NCMEC and law enforcement the records the customer sends us for that end user when they ask or the law requires. Where our review finds that material is AI-generated, we say so in the report.

If you are a platform customer, our report identifies your organization, because the request came through your account. If your end-user ID identifies the person, the report points to them. If it does not, your organization is the only party the report can identify.

Preservation

We keep the contents of each report, and related material that may give context about it, for at least one year after the report, as US law requires. We keep other case records for at least one year too. If law enforcement asks us to keep records longer, we will.

Law enforcement and other countries

NCMEC makes each report available to one or more law enforcement agencies: federal, state or local agencies in the US that investigate these crimes, or certain foreign law enforcement agencies (18 U.S.C. § 2258A(c)). An investigating agency can use legal process, such as a subpoena or a search warrant, to require records from us and from you. We cooperate with investigations and respond to valid legal process (Section 11 of this page). When a case involves another country, NCMEC can make our report available to law enforcement there.

9. How to Report to Us

Anyone can report a child-safety concern: customers, their users, researchers, parents and the public.

safety@eachlabs.ai is our child-safety inbox.

Include as much of this as you can:

a link to the content, or the execution or request ID;
the account or app involved, and which API key was used (its name or ID, never the key itself), if you know it;
the date and time you saw it, with time zone;
a short description of what you saw;
how to reach you, if you want a reply. You do not have to give your name.

Never send us the material itself. Do not attach, screenshot, download or forward images or videos of child sexual abuse to us or to anyone else. Doing so can be a crime. A link or an ID is enough. If you are a provider with your own duty to report to NCMEC, follow the instructions NCMEC gives you.

We treat every child-safety report as urgent. If you found the content outside each::labs, report it to the CyberTipline or your national hotline (Section 10).

10. Help and Support

If a sexual image or video of you or your child has been made or shared, including a fake made with AI, help is available. You do not have to deal with it alone.

If you are worried about your own sexual thoughts or behavior toward children, confidential help is available too. Asking for help early is the safest step for a child and for you, and it is treated with understanding, not blame.

If a child is in immediate danger, call your local emergency number now: 911 in the US, 999 in the UK or 112 in the EU.

Take It Down (NCMEC). Helps remove nude, partially nude or sexually explicit images and videos taken before you were 18 from participating platforms. Your image or video stays on your device.
Report Remove (Childline and the Internet Watch Foundation). For young people under 18 in the UK. Confidentially report sexual images or videos of yourself and get them removed from the internet.
CyberTipline (NCMEC). The US reporting system for child sexual exploitation. Report online, or call 1-800-843-5678, 24 hours a day.
Find your national hotline (INHOPE). For countries outside the US and UK.
Stop It Now (US helpline). Confidential help and advice for anyone worried about their own sexual thoughts or behavior toward children. You can ask for help without giving your name.

If the image or video was made or shared through each::labs, also email safety@eachlabs.ai with the link. Do not send the image or video itself. We will remove our copies from public access, preserve them for law enforcement and, if they are apparent child sexual abuse material, report them to NCMEC as the law requires.

11. Law-Enforcement Requests

Law enforcement can send requests to Eachlabs Inc. at safety@eachlabs.ai. Put "Law enforcement request" in the subject line.

We disclose account information when valid legal process requires it, such as a subpoena or court order. We disclose content only with a search warrant, unless the law allows otherwise.
If there is an emergency involving danger of death or serious physical injury, mark the request "Emergency". US law allows us to disclose information about the emergency without delay when we believe in good faith that the emergency requires it (18 U.S.C. § 2702(b)(8) and (c)(4)).
We honor preservation requests under 18 U.S.C. § 2703(f).
We review requests from outside the US under applicable law.
We do not tell the account holder about a request when the law forbids it or a court orders us not to. Otherwise, our agreement with the customer can require us to tell them before we disclose their personal data. If telling them could put a child at risk or harm an investigation, include a court order under 18 U.S.C. § 2705(b) with your request.

12. Transparency

We will publish our child-safety numbers every six months. Each report will include:

reports we filed with NCMEC;
organizations suspended or closed, and end-user IDs blocked;
requests blocked by our child-safety checks;
matches with known child sexual abuse material;
the share of images we scanned;
the median time from detection to report.

We will publish them on this page.

13. Relationship to Our Terms

This page explains how we apply the child-protection rules in Section 7 of our Terms of Service and Section 2 of our Acceptable Use Policy. This page is not part of your agreement with each::labs. If it differs from that agreement, the agreement controls.

We may update this page. The version and date at the top show when this page last changed, and earlier versions stay available at stable URLs.

Child safety.