Dify content moderation with a custom endpoint keeps screening in your hands
Dify's moderation API extension lets you point Dify at an endpoint you host, so screening runs through the moderation or data loss prevention service your team already operates. The extension has two extension points: app.moderation.input, which reviews end user variables and conversation input, and app.moderation.output, which reviews what the LLM returns. A regulated team usually needs this when its policy requires one screening engine, one rule set and one audit trail across chat, APIs and other tools, and when built-in keyword or prompt controls cannot express the classifiers, patterns or case handling the security function already maintains. It also helps when the organization must prove that outbound model responses passed the same checks as other channels.
The extension does not replace the rest of the control set. Moderation sees only the text that reaches it, so it does not stop prompt injection through documents retrieved from a knowledge base, tool calls made by an agent, or data a workflow sends to an external API unless those paths are also designed. Access control, sign-up policy, outbound request filtering and the code sandbox remain separate decisions covered elsewhere. Before committing, confirm with your moderation vendor how it scores partial text, what latency it adds per call, and how it records blocked and allowed decisions, since those answers determine whether the endpoint is a reliable gate or only a logging point.
Plan the endpoint as a production dependency. Ask your security and platform teams who owns its availability, what the Dify app should do when the endpoint is slow or unreachable (fail closed or fail open, and who approves that choice), and where blocked events are logged for review. Test both extension points with known-bad and benign samples in a staging workspace before a live app is connected. Streamed responses are split into 100-character chunks before they reach the output endpoint, according to the Dify docs, so confirm that your classifier handles fragments accurately and that a pattern spanning a chunk boundary is not missed. Check the exact request and response fields your endpoint must accept and return in the Dify moderation API extension documentation against the Dify version you deploy.
Which extension point fits which screening goal
This table compares the input and output moderation extension points and the three actions a moderation endpoint can drive: block, redact or log only. Read each row as a screening goal, then check the blind spots before relying on that point for control.
| Screening goal | app.moderation.input | app.moderation.output |
|---|---|---|
| Screened content | End user variables and conversation input before the model call | LLM responses returned to the user, reviewed in 100-character chunks when streamed |
| Best fit | Stopping sensitive data, abusive prompts or disallowed topics from reaching the model and any external provider | Catching sensitive data or unsafe text the model generates, including content it produced from clean input |
| Blocking | Stops the request before the model runs, so no tokens are sent to the provider | Stops or replaces output, but chunks already streamed to the user may not be recallable |
| Redacting | Can replace values before the model sees them, provided the endpoint returns the modified content | Can mask fragments, but a pattern split across a chunk boundary may be missed |
| Logging only | Records what was sent without interrupting the request, useful for tuning rules | Records output for review without changing what the user sees |
| What it cannot see | Content the model invents, retrieved knowledge base text added later in the workflow, and files processed by tools | Context the endpoint never received, such as prompts that were not passed through, and meaning that spans multiple chunks |
| Typical blind spot | Data pulled from tools, HTTP nodes or knowledge retrieval after the input check | Sensitive values split across chunk edges or encoded in a form the scanner does not parse |
How to wire a custom moderation endpoint into a Dify app
This sequence connects a Dify app to a moderation or data loss prevention service you run, so user input and model output pass through your own checks before the user sees them. Each step closes with a check you can record. The result is a tested extension enabled on the app at both extension points.
Stand up the moderation endpoint
The platform or security team deploys the screening service inside the network that can reach the Dify API service, using the moderation or data loss prevention tooling your organization already runs. Decide where its logs are kept and who can read them, because the endpoint will see user prompts and model output. Confirm that the Dify API host can open a connection to the endpoint address. The Dify environment reference says outbound requests pass through an SSRF proxy that blocks internal and private IP ranges, so ask your platform team how that one destination is allowed. Done when a test request from the Dify API host returns a response.
Confirm the request and response contract
Read the Dify moderation API extension docs and write down the fields Dify sends for each extension point, the fields your endpoint must return, and how a block decision is expressed. Check these against the docs for the Dify release you run, since the contract is the part most likely to change between versions. Keep a short spec with one example request and response for input and one for output. Done when the service owner and the Dify administrator have reviewed the spec and a mock endpoint returns a response that matches it.
Register the moderation extension in the workspace
A user who can manage the workspace adds a moderation-type API extension in the Dify console, entering a name, the endpoint address and the credential your endpoint checks. Store that credential in your secrets manager and avoid pasting it into shared notes or tickets. Confirm that the extension appears in the workspace list with the values you entered. Done when the extension is saved and can be selected from an app's moderation settings.
Enable the input moderation point
In the app configuration, turn on sensitive content moderation and select your extension for the input point, which reviews end user variables and conversation input. Decide in advance what the app does when the endpoint flags content, and review the message users will see in that case. Send a benign message and a flagged test message through the app preview. Done when the flagged message is stopped before any model call, which you can confirm in the workflow or conversation logs.
Enable the output moderation point
Turn on the output point, which reviews what the LLM returns. According to the Dify docs, when output streams, the text sent to the moderation endpoint is split into 100-character chunks, so long answers are reviewed without waiting for the full response. Plan for content that spans a chunk boundary, for example by having the endpoint keep short context between chunks, and confirm with the docs how a block during streaming is shown to the user. Done when a long test response containing a marker placed across a boundary is handled as your spec requires.
Test with known-bad and benign samples
Build a test set with prompts that must be blocked, such as illustrative fake credentials or sample personal identifiers, along with ordinary business questions and long benign answers. Run each sample through the input and output points and record the result, including any benign sample that is wrongly flagged. Done when every blocked sample is stopped at the expected point, benign samples pass, and results are saved as evidence. Repeat this test after each Dify upgrade or endpoint change.
How streamed output is chunked before review
When an app streams its answer, Dify does not wait for the full response before calling your moderation endpoint on the output side. According to the Dify docs, the streamed output is split into 100-character chunks, and each chunk is sent to the app.moderation.output extension point. The benefit is latency: a long answer is screened while it is still being generated, so the user does not sit through a complete response before any review happens. The cost is that every decision is made on a fragment, not on the whole answer, and your design has to account for that.
Three trade-offs follow directly from chunking. A sensitive pattern, such as an account number or a name paired with a diagnosis, can be split across two chunks so that neither chunk matches your rule on its own. Text that a later chunk flags may already have been displayed to the user, so a block decision reaches the reader after the fact. And your endpoint will receive partial text, which means it must not assume a chunk is a complete sentence, a complete token or a complete identifier. Treat each call as a stateless check unless you deliberately keep context between calls, and document which of those two behaviors you chose.
Before you rely on this for regulated output, confirm in your own Dify version how stop and block behavior works for streamed responses: whether a flagged chunk halts generation, whether the already-sent text is retracted or only replaced by a preset message, and what the user sees at that point. Test with a payload that deliberately crosses a 100-character boundary and record the result. Also confirm the exact request and response fields your endpoint must use in the Dify moderation API extension documentation, since the chunk handling is only as reliable as the contract your endpoint implements.
Security risks when the moderation endpoint sits in the request path
A custom moderation endpoint runs inside the request path of every screened message, so its availability, logging, authentication and network reach all become part of the Dify deployment's security posture. The cards below cover the risks that follow from that position and the controls to put in place before the endpoint handles production traffic.
Endpoint outage stalls every request
Because the input and output extension points call your service before or while the model responds, an unavailable or slow endpoint can block every app that depends on it. Decide in advance whether a failed call should block the message or pass it through, and document that choice as a risk acceptance. Load test the endpoint at your expected peak concurrency, and confirm the timeout behavior of your Dify version before go-live.
Logs that copy sensitive content
A moderation service exists to see prompts, personal data and model answers, so its request logs, traces and error reports can become a second store of the same sensitive content. Turn off payload logging by default, log only verdicts, categories and request identifiers, and apply the same retention rules you use for Dify conversation data. Confirm where your observability tools send these logs and who can read them.
Unauthenticated moderation calls
If the endpoint accepts requests from any source, anyone who can reach it can submit text for free screening, probe your policy thresholds, or flood the service. Require Dify to present a credential on every call, restrict the endpoint to the network path Dify uses, and reject requests that lack a valid signature or key. Test that calls without the credential are refused.
Outbound calls reaching internal ranges
Dify makes the moderation call from its own servers, so a misconfigured endpoint URL could point at internal addresses, and the moderation service could be reached from places it should not. Route outbound traffic through the SSRF_PROXY settings, which block internal and private IP ranges, and make sure your moderation service is reachable through an allowed address. Verify the path with a test call from the Dify host, not from your workstation.
Endpoint credential in plain configuration
The key that Dify uses to authenticate to your moderation service is a secret, and placing it in a shared configuration file, a workflow export or a support ticket exposes it. Store the value in your secrets manager or the environment of the Dify host, limit who can read it, and rotate it on a schedule and after any staff change. Confirm that DSL exports exclude API keys before sharing app files.
Unreviewed changes to the endpoint
The endpoint decides what users and models can see, so a change to its policy, categories or thresholds changes the security behavior of every Dify app behind it without any change to Dify itself. Keep the endpoint code and policy under version control, require review for changes, and test a fixed set of known-bad and known-good samples before each release. Record which policy version screened each conversation so reviewers can trace a decision.
Questions teams ask before building a moderation endpoint
How much effort does building and testing a custom moderation endpoint take?
The effort depends mostly on what your moderation or data loss prevention service already does and how many Dify apps it must cover. Dify itself only needs an endpoint that receives a payload and returns a decision, so the wiring is a small part of the work. The larger costs are defining what gets blocked or masked, building test cases for both the input and output extension points, and checking streamed responses under realistic conversation lengths. Ask any partner to show how they will test blocked, masked and allowed content on both paths before they quote. No duration figure is supplied for this work, so confirm it against your own scope.
What drives the cost of a moderation endpoint project?
Cost is driven by the size of the policy, not the Dify configuration itself. The main drivers are:
- The number of moderation rules and whether they must be consistent across apps
- Whether your moderation or DLP service has a documented API and test environment
- How many apps, workflows and API paths must route through the endpoint
- The depth of logging, evidence and review needed for regulators or internal audit
For a quote, ask for the work broken into endpoint build, Dify configuration, test cases and handover, with each one tied to a written scope.
Can our own team build the moderation endpoint without outside help?
Yes, if your team has a developer who can write an HTTP service and someone who owns the moderation policy. The Dify side is a configuration of the moderation API extension, with two extension points: one for user input and one for model output. The harder parts are usually the policy decisions, the handling of streamed output and the test plan. Teams without experience in streamed responses often underestimate how partial text is reviewed, so a short proof of concept is a useful first step. DeployOpen can plan, build and test the endpoint as a fixed-scope engagement if you prefer a partner.
What do security and application owners need to provide?
Security owners should define which categories of content must be blocked, masked or logged, and which data may leave your network to reach a third-party moderation service. Application owners should list the Dify apps, their users and the workflows that call the model, so the endpoint can be attached to the right extension points. Both groups should approve the response behavior, including what end users see when content is blocked. Ask for these decisions in writing before build starts, because changing them later means retesting every affected app.
Are the built-in Dify controls enough for regulated use?
Built-in controls cover the basics of a self-hosted deployment, including secrets handling, outbound request filtering through the SSRF proxy and sandboxed template rendering, but they do not decide what your organization considers sensitive content. A custom endpoint lets you apply your own policy and data loss prevention rules to user input and model output. Whether that is sufficient for a particular regulator or internal control is a question for your compliance function and independent auditors. DeployOpen prepares systems and evidence for assessments but does not issue audit reports.
How does the moderation endpoint relate to other Dify guardrails?
The moderation endpoint is one control among several. Prompt design, knowledge base access rules, the Human Input node and annotation replies each shape what an app can say or do. The moderation extension points are most useful for screening text in and out of the app, while human review is useful for decisions a person must sign off on. Plan these together so that a blocked message, an approval step and an access rule do not contradict each other. Confirm how your chosen Dify version handles each control before you rely on it.
What should we check after the endpoint goes live?
Check that both extension points receive traffic, that blocked and masked responses are logged the way your policy requires, and that streamed answers are reviewed as expected. Re-test after every Dify upgrade, since minor releases arrive roughly monthly and extension behavior can change. Keep the endpoint's own dependencies, certificates and logs under the same operations routine as the rest of your Dify platform.
Operating and tuning the endpoint after go-live
The first thing to plan after go-live is the ongoing tuning loop, because a moderation endpoint is only as good as the rules behind it and those rules drift. Assign an owner for the endpoint's classifier or policy rules, and schedule regular reviews of false positives, where legitimate employee or customer messages are blocked or replaced, and false negatives, where sensitive content passed through. Bring compliance into the review of flagged events so that decisions about what is retained, who can see the raw text, and how long logs are kept are made with the people accountable for them. Record each rule change with its reason, since auditors and internal reviewers will ask why a threshold or pattern changed.
Model and Dify changes both require re-testing the endpoint. When you change the model behind your moderation service, or the model used in a Dify app, rerun your reference set of prompts and expected outcomes before the change reaches users. Dify releases arrive roughly monthly, with 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026 according to the langgenius/dify releases page, so treat each upgrade as a planned event. Follow the upgrade guide for the target version, take a backup first, and check the Dify Docker Compose documentation for new .env variables. Because extension behavior can change between releases, confirm that your endpoint still receives the same request fields and that app.moderation.input and app.moderation.output still fire where you expect.
How DeployOpen scopes and delivers moderation integrations
DeployOpen plans the moderation endpoint as part of the Dify deployment, not as an afterthought. We scope which apps, inputs and outputs the input and output extension points cover, then build, test and document the integration inside your infrastructure.
How we scope
- Inventory which Dify apps take user input and which model outputs must pass review before users see them.
- Confirm the moderation or data loss prevention service your team owns, its response times and what it can return.
- Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope by default.
How we build
- Wire the app.moderation.input and app.moderation.output extension points to your endpoint in a non-production instance first.
- Test streamed responses against the 100-character chunking behavior, including long answers and split words or phrases.
- Verify that blocked content, error responses and endpoint timeouts behave the way your policy requires.
How we hand over
- Document the endpoint contract, request and response fields, and the configured behavior for each extension point.
- Record the test cases, sample payloads and results so your security and compliance teams can review them.
- Walk your engineers through the configuration, rollback steps and how to change the endpoint after upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retesting the moderation path after Dify upgrades, since extension behavior can change between releases.
- Reviewing endpoint logs, false positive patterns and policy changes with your team on an agreed schedule.
