Local CSAM Shield

Abolitus is designed to give users broad creative freedom in private local workflows, but that freedom is not unlimited.

There is one category where the platform takes a hard legal boundary: Child Sexual Abuse Material (CSAM).

That creates a difficult product problem.

If the service is built around a zero-knowledge posture, how can it enforce a legal boundary without creating a server-side moderation pipeline that reads ordinary user content?

The Local CSAM Shield is the answer.

The Core Idea

The shield tries to enforce one narrow legal red line without turning normal user chats into server-readable moderation traffic.

That means the system is designed so the decision happens locally on your device rather than by sending your chat stream to an external moderation API.

How the Shield Works at a High Level

The shield uses a layered local process.

In practical terms, that means:

1. an instant local tripwire catches obvious violations quickly,
2. a browser-side classifier can inspect more nuanced text,
3. and a local fallback heuristic exists for degraded situations.

The important user-facing point is not the exact implementation detail.

The important point is that the decision happens on the client side rather than by forwarding your ordinary scene text to a company-controlled moderation service.

Why This Is Different from Normal Moderation

Traditional moderation pipelines usually work by forwarding content to a company-controlled inspection service.

That approach is common, but it creates serious privacy problems:

• the service sees the text,
• the service can log the text,
• the moderation provider may become another party with visibility into your usage,
• and the product operator now has pressure to retain reviewable evidence.

For a privacy-first roleplay client, that is the wrong shape of solution.

The Local CSAM Shield tries to preserve the broader privacy model while still making one prohibited class of output unavailable.

What the Shield Does and Does Not Mean

It is important to distinguish the scope of this system.

The shield is not a general-purpose censorship engine for consensual adult roleplay, dark fiction, or violent fictional material.

It exists to enforce a narrow legal boundary.

That distinction matters because users often conflate three different things:

• provider-side alignment behavior,
• wrapper or prompt weakness,
• and platform-level filtering.

In many real cases, a refusal is caused by the selected model route, not by Abolitus itself.

The Privacy Consequence

Because the shield runs locally on your device:

• ordinary moderation decisions do not require server-side transcript access,
• detection does not need to become a readable moderation queue,
• and the product does not need to treat every user session as something that should be centrally inspected.

This matters even if you never personally hit the boundary.

The architecture protects everyone else from living inside an always-inspected product.

Why the Interruption Can Feel Generic

The user-facing failure surface is intentionally generic rather than overly specific.

That is not just cosmetic.

It reduces the amount of feedback the system gives about the exact boundary condition and avoids turning moderation into an interactive oracle.

It also helps keep the event local instead of escalating it into a visible server workflow.

False Positives and Edge Cases

Like any classifier or heuristic layer, a local safety system can be imperfect.

If you believe a scene is being interrupted incorrectly, isolate variables before assuming the cause:

1. retry with simpler phrasing,
2. remove ambiguous age references or compressed shorthand,
3. check whether the refusal is actually coming from the model provider,
4. compare behavior across routes if you have more than one provider available.

That process helps distinguish platform-side boundary enforcement from ordinary provider alignment or prompt instability.

Why This Matters for the Broader Privacy Model

The design goal is not to know more about users.

The goal is to know less while still making one prohibited class of output unavailable.

That is why the shield lives on the client.

It enforces a narrow legal boundary while preserving the broader zero-knowledge direction of the product.

Related Pages

• Read E2EE Architecture for the larger trust-boundary model.
• Read Operational Security (OPSEC) for the operational discipline behind keeping sensitive inspection local where possible.
• Read FAQ if you want the short practical summary rather than the architectural explanation.