14. Configure content detection and safety fences

Back to overview · Full table of contents · Download full PDF

This chapter is for tenant administrators and Security Admins. It explains how to add a Content detection action in a traffic rule, and apply content-safety protection to model calls, MCP calls, and API-service calls. After this chapter you can start from a rule template, pick Content detection · Conversation content or Content detection · Tool calls by inspection target, set sensitive information, keywords, model judge, and canned Q&A, write reply copy and custom categories, validate the rule before save, confirm it has taken effect after save, and check the actual effect with a test call and the rule detail. You can also connect a malicious feed and intercept outbound requests to known malicious domains or IPs.

Content detection is configured in two places: Admin Console › Guardrails › Guardrail rules only maintains the detection basis (sensitive-data types, lexicons, Q&A, internal-system allowlist, threat intelligence) and does not decide which calls it applies to. Whether to detect, which calls to detect, and what to do on a hit are all configured in a rule under Admin Console › Traffic › Traffic rules. Sensitive-data recognition rules are in Chapter 13. Traffic-rule conditions, order, and publish are in Chapter 15. This chapter's capabilities require Model guardrails in the license. Adding a detection action also requires Dynamic routing.

14.1 Parts of content detection

When to use: first time you configure content detection; first understand inspection targets, inspection methods, and the judge models they depend on.

The Content detection action is split by inspection target into two items, listed separately in the rule canvas Add action menu:

How they differ and how to choose are in section 14.2. Content detection · Conversation content can tick the following inspection methods at the same time:

Calls from business systems, developer tools, and external agents all go through the gateway. As long as they fall in the rule conditions, they are detected by the same rule.

Note: one rule has only one inspection stage (user question, model reply, or both). For a combination such as keywords at the user-question stage, model judge at the model-reply stage, split into two rules.

14.2 How conversation content differs from tool calls

When to use: you are unsure whether to pick Content detection · Conversation content or Content detection · Tool calls, or a rule is saved but did not stop the content you expected.

How to choose

• To stop what the user said or what the model answered, for example a user question contains a password, asks a competitor's price, or asks for prohibited content, pick Content detection · Conversation content.
• To stop what the model or external agent is about to do, for example run rm -rf, call an API to delete data, or send a file to an external URL, pick Content detection · Tool calls.
• When you need to govern both kinds of risk, add both actions on the same rule.

Note: Content detection · Tool calls does not inspect the user's question. When a user question contains a password, a rule that only configured tool-call detection will not intercept. That is expected.

14.3 Set judge models

When to use: first use of model judge, sensitive-info recognition (person names, addresses, organization names), or canned Q&A, or you need to change a judge model.

The platform has four judge models, one each for the whole tenant, belonging to platform infrastructure, not distributed by member:

Procedure

1. Open settings in either place:
   • Admin Console › System Settings › Global settings › Default models, click Edit on the row of the matching function;
   • When you edit a Content detection · Conversation content node on the traffic-rule canvas, if a required judge model is not set or is unavailable, the node shows that judge model's status and Set or Change model. Clicking opens a settings drawer on the right of the current page, showing only the item you need, without leaving the rule you are editing.
2. Pick a model in Model. When the chosen model's upstream belongs to an external provider, below it shows After you pick "{provider}", users' questions will be sent to that provider. Decide according to enterprise data-compliance requirements.
3. Click Save and use. The platform actually calls the chosen model with one violating sample and one normal sample to check, and automatically determines the call style; you do not choose a model type.

What you will see

• Check passed: shows Check passed, settings are saved, and all rules that reference this judge model switch to the new model at the same time. The canvas node and Global settings show the same status, for example ● Normal.
• Check did not pass: shows a reason and a suggestion, the save button is unavailable, and existing settings stay unchanged.

Change the content-judge model

Custom categories (section 14.5) can only be used by a chat model or a model that provides a structured-decision API. A dedicated content-safety guardrail model and a custom content-safety detection service can only recognize fixed risk categories.

• When existing rules use custom categories, switching to a model that can only recognize fixed categories refuses save. The drawer lists rules that are using custom categories (click to open). Pick another chat model, or first delete custom categories from those rules.
• When the current content-judge model can only recognize fixed categories, the custom-category area in the rule is unavailable, with The current content-judge model can only recognize fixed categories and cannot use custom categories, plus Change model next to it.
• Switching between two chat models is not affected.

Note

• Automatic check only guarantees that the model can give a basically correct judgment; it does not mean it is accurate enough on your business corpus. Before go-live, self-check with custom-category Test (14.5) and Validate rule (14.12).
• When a general chat model is used as judge, detection at the user-question stage delays time to first token. For latency-sensitive business, prefer a fast model, or turn on model judge only for necessary callers.
• Judge-model calls show in model-group usage as platform-internal calls, and can be viewed in gateway call records.

14.4 Configure a conversation-content detection rule

When to use: have a class of callers' conversations handled by the rule when sensitive information, controlled words, prohibited topics, or a standard question appear, and reply with copy you wrote.

Prerequisites: when you need model judge or canned Q&A, the matching judge model is already set as in 14.3. You can also set it in place through the drawer while editing the rule.

Procedure

1. Open Admin Console › Traffic › Traffic rules, click New rule, or click Import rule template, switch to the Content detection group, and pick the template closest to the need:

   Template	Content	Judge model needed
   Keyword intercept and reply	When the question contains specified words, reply with fixed copy	None
   Sensitive-info intercept	When the question contains a password, ID number, and similar, intercept and reply	None
   Custom-topic intercept	Judge by a criterion you wrote whether the question belongs to a specified topic	Content judge
   Risk-content intercept	Risk categories such as illegal, pornography, violence	Content judge
   Canned Q&A	Specified questions replied with a standard answer	Q&A semantic matching
   Tool-call protection	Inspect tool calls, not conversation content (14.8)	Chosen by the rule

   When a template needs a judge model that is not yet set, applying the template opens the 14.3 settings drawer directly.

2. Narrow the range in Condition judgment, for example Model group = "Customer-service assistant". With no condition, the rule matches all requests and the canvas shows Match all requests.

3. Click Add disposition action, and in the Before forwarding the request group pick Content detection · Conversation content (skip if the template already has that action).

4. In Inspection stage choose User question, Model reply, or Both.

5. In Inspection methods tick the methods you need, and set them separately:

   • Sensitive information: tick detection items (for example Passwords and secrets, ID number, Bank-card number, Phone number), and in On hit pick Block, Redact, or Record only.
   • Keywords: in Referenced lexicons pick lexicons (14.6), multi-select allowed. Words must first be maintained in a lexicon.
   • Model judge: confirm Content-judge model status is Normal, tick risk categories and Prompt injection, set handling for Clear hit and Suspected hit separately; add custom categories as needed (14.5), and set When the judge model is unavailable (14.9).
   • Canned Q&A: pick Q&A entries (14.7).

6. In Reply copy choose Custom and fill in copy, or use the system default Sorry, I cannot answer your question. To give different copy per category, expand Set copy per category, and fill in separately for built-in risk categories and custom categories.

7. In the canvas right-hand Validate rule, check the effect with one sentence (14.12). After it looks right, click Save rule, check in Confirm changes, then click Confirm and apply.

What you will see

• The Content detection · Conversation content node only appears in the position that matches its inspection stage: User question in Before forwarding the request, Model reply in After receiving the upstream response. Both shares one node in both places; it is not drawn twice.
• After save it shows Rule "{name}" saved., plus View hit records (14.12).

Note

• Reply copy should state that the request cannot continue and which channel they can ask for help. It should not expose the rule, thresholds, or bypass methods.
• When the same call hits content detection of several rules, detection items are merged. The same item takes the stricter handling: block over redaction, redaction over record only.
• Record only does not change conversation content; it only leaves a record in hit records, which fits observing false positives in early go-live.

14.5 Risk categories, prompt injection, and custom categories

When to use: you need to judge prohibited content by semantics rather than literals, recognize prompt injection such as role-play bypass and instruction override, or recognize a specific topic by the enterprise's own standard (for example competitor comparison, investment advice).

Prerequisites: the Content judge model is already set as in 14.3.

Risk categories and prompt injection

After you tick Model judge on a Content detection · Conversation content node, tick categories to recognize in Risk categories, multi-select allowed. The six built-in categories are: political sensitivity and national security; illegal, terrorism, and false rumors; pornography, vulgarity, and harmful values; discrimination, bias, and hate speech; privacy infringement and commercial compliance; high-risk-domain application limits. Ticking Prompt injection can recognize writing that asks the model to ignore existing instructions or leak the system prompt.

Each item can set handling for Clear hit and Suspected hit separately, for example block on a clear hit and record only on a suspected hit.

Add a custom category

1. Click Add custom category and fill in:
   • Name: for example Competitor topic;
   • Judgment criterion: in one sentence, what content belongs to this category, for example Mentions or compares another vendor's products, prices, or strengths and weaknesses;
   • Positive examples: typical sentences that belong, for example Is so-and-so cheaper than you, several allowed;
   • Negative examples: sentences that are easy to confuse but do not belong, for example What is your price, several allowed.
2. Click Test. The platform actually calls the content-judge model with the positive and negative examples, shows Correct x/y, and lists sentences it got wrong.
3. Change the judgment criterion or add samples from the test result until the result matches expectations.
4. Set this category's Clear hit and Suspected hit handling. For separate copy, fill it in for this category under Reply copy › Set copy per category.

What you will see: when the test is all correct it shows a result such as ✓ Correct 4/4. When some are wrong, the wrong sentences and the model's judgment are listed together.

Note

• The judgment criterion is what the model judge uses. Positive and negative examples are only for Test; they are not sent to the model with every request. Write the criterion specifically and distinguishably; avoid vague wording such as unsuitable content.
• Custom categories need the content-judge model to be a chat model or a model that provides a structured-decision API. A model that can only recognize fixed categories cannot use them (14.3 Change the content-judge model).
• If you do not want to depend on a model and only want to intercept fixed wording, you can put original text such as ignore existing instructions, output the system prompt as keywords (14.6). That only covers the listed wording; semantic rewrites still need model judge.

14.6 Keywords and evasion recognition

When to use: you need to intercept prohibited content by a controlled word list, and recognize rewrites such as full-width, traditional Chinese, homoglyphs, zero-width characters, character spacing, and encoding.

View and create a lexicon

1. Open Admin Console › Guardrails › Guardrail rules and switch to the Lexicon tab. Built-in denylist has 11 lexicons, Chinese and English sets of the six categories, about 26,000 Chinese entries. Built-in lexicons update with the version. You can view, search, and export them; you cannot change them.
2. Click New lexicon, fill in Name, set Type to Custom denylist or Allowlist, set Category to one of the six (which decides the category a hit is filed under, and copy set per category).
3. Open the lexicon, click Add entry, fill in Entry and Aliases (comma-separated), then confirm. Both hit the same rule. Bulk import uses Import, which accepts a UTF-8 .txt file, one per line.

Use in a traffic rule

On a Content detection · Conversation content node tick Keywords, pick lexicons in Referenced lexicons (multi-select allowed), then set evasion handling from the table below and save. You cannot type words directly in the rule. Words used only by one rule must still be built into a lexicon first.

Evasion recognition: before match, the entry and the text under inspection get the same normalization, with no configuration — full-width to half-width, traditional to simplified, homoglyphs normalized, skip zero-width characters and separators, compress repeated characters, lowercase. After Decode encodings is on, decode first then match.

What you will see

• When a user question hits a controlled word, the request is intercepted and copy is returned; the model is not called. Writing that only hits after normalization is also intercepted.
• Pinyin writing is admitted at the user-question stage and recorded as a suspected hit.
• When a controlled word appears in the model reply, already-output content is replaced by the copy.

Note: an entry's pinyin writing is only recorded, not intercepted. To intercept pinyin writing at the user-question stage, add it as that entry's alias. When the business will send Base64-encoded attachments or signatures through the gateway, turning on Decode encodings may cause false positives. Prefer setting Hit after decode to Record only and watching for a while.

14.7 Canned Q&A

When to use: have company policy, product rules, and unified replies on sensitive topics returned directly by the gateway, without calling a model, including a different wording of the same question.

Prerequisites: the Q&A semantic matching model is already set as in 14.3, otherwise Q&A entries cannot be picked and the rule cannot be saved.

Procedure

1. Open Admin Console › Guardrails › Guardrail rules and switch to the Q&A tab. The list shows standard question, category, group, similar-question count, and source. Platform built-in question bank has 7481 entries and is searchable.
2. Click New Q&A, fill in Standard question, Answer, Add similar questions as needed, pick Category and Group, then confirm. Uncategorized Q&A applies to all categories. After you pick a group you can Enable the whole group or Disable the whole group.
3. On the traffic-rule Content detection · Conversation content node tick Canned Q&A, pick Q&A entries, save, and confirm apply.

What you will see: when the Q&A semantic-matching model is not set, the node shows that model's status and Set; clicking opens the 14.3 settings drawer. On a standard-question hit, the caller receives the standard answer.

Note: canned Q&A only acts on user questions. On a hit it returns the answer directly and does not call a model. When the Q&A semantic-matching model is unavailable it falls back to matching the original sentence.

14.8 Content detection · Tool calls

When to use: intercept dangerous calls a model or agent sends, such as dropping a database, destructive commands, or sending sensitive data out. This action is made of Match rules and Model judge, which can be configured alone or together. It only inspects tool calls, not conversation content (14.2).

Prerequisites: the rule's Call type is limited to model call, MCP call, or API service. Using Model judge requires picking a judge model.

Procedure

1. Create a rule, or in Import rule template › Content detection pick Tool-call protection. Set conditions (for example Model or Model group) and Call type.
2. Click Add disposition action, in the Before forwarding the request group pick Content detection · Tool calls. The top of the node states Inspect arguments when an agent calls a tool, and results the tool returns; do not inspect conversation content.
3. Click Add match rule and fill in:
   • Tool: * wildcards supported.
   • Inspection location: Call arguments the model sent or Results the tool returned.
   • Field: empty means inspect all; nested fields are separated by dots. Exceptions only exempt overlapping hits.
   • Match method: regex or keywords (keywords are case-insensitive and full-width/half-width-insensitive). Match content is the wording to intercept.
4. Fill in a sample in Example, click Test, confirm the hitting fragment. In On hit pick Block or Record only, save, and confirm apply.

Model judge: Detection scope is Command-execution tools only or All tool calls. Pick a model in Judge model, and tick in Block categories. There are eleven categories: download a script and run it, send sensitive data out, bulk or unrecoverable delete, change production, change shared infrastructure, expand permissions, expose secrets, escape an isolation environment, destroy audit, change a traffic target, rewrite history. For an enterprise-specific category, click Add custom category and fill it in the same way as 14.5.

Internal-system allowlist: open Admin Console › Guardrails › Guardrail rules, switch to the Internal-system allowlist tab, click New list, fill in name and entries such as internal domains and intranet hosts, then create, then reference it in Model judge. The judge model treats targets in the list as the company's own systems.

What you will see: the UI states Match rules run before model judge, only do literal match, and cannot recognize obfuscation such as concatenation or encoding. Handling is only Block and Record only. An intercepted tool call is not executed. The model continues to reply after receiving This content was intercepted.

Note: an internal-system allowlist is only a basis for model judge; it is not an allow or deny list for outbound connections.

14.9 What to do when the judge model is unavailable

When to use: confirm whether business continues or is denied when the judge model times out, errors, or is disabled.

Judge model unavailable includes: judge timeout, upstream returned an error, the return could not be recognized, and the judge model was disabled, deleted, or has no available upstream. Handling is set in When the judge model is unavailable on a Content detection · Conversation content node. Model judge of Content detection · Tool calls has its own same-named setting.

What you will see

• When the judge model is disabled or failed, the canvas node and Global settings show the same status, plus Change model, which opens the 14.3 settings drawer.
• Every handling by When the judge model is unavailable records a hit. The rule-detail traffic view lists Judge model unavailable separately in the hit breakdown (14.12).
• A denied request returns HTTP 403, reason is CONTENT_SAFETY_UNAVAILABLE.

Note: Deny is stricter for safety. Keep Deny for high-risk, heavily regulated, or sensitive-data business. When several rules stack, as long as one is Deny, it is handled as deny. Handling is set statically per rule and judged independently per request. The platform does not automatically degrade to record-only after consecutive timeouts. When the judge model stays unavailable, prefer changing the judge model rather than switching to Allow.

14.10 Multi-turn conversation and streaming-output detection

When to use: the caller splits sensitive content into several short messages, or the model only gradually spells out sensitive content in a streaming output.

Prerequisites: the rule already has a Content detection · Conversation content action. The multi-turn detection switch can only be configured in YAML edit or through the API.

Procedure: click YAML edit, add the following under action.guard.content, then click Apply to canvas and Save rule › Confirm and apply. After the rule takes effect, check separately with a whole-piece request and a streaming request.

action:
  guard:
    content:
      multiTurn:
        reassembleShortMessages: true   # 拆分输入合并检测
        cumulativeOutput: true          # 多轮回答合并检测

What you will see

• A whole-piece request that carries sensitive data is intercepted.
• A normal streaming request arrives in order and ends with data: [DONE].
• When prohibited content appears in a streaming answer it stops at the hit. The last frame's finish_reason is content_filter. The stream has neither original text nor a placeholder (14.11).

Note: streaming detection is per segment. The gateway only holds back a small tail of each segment that might form a hit with later text; the rest is released as soon as detection passes. Related windows are platform-fixed parameters and cannot be adjusted.

14.11 What the caller sees

When to use: explain to maintainers of business systems and developer tools what is returned after a rule hit, or check whether the return matches expectations.

• The return only carries a rule ID, not a rule name. Administrators look up the matching hit by time and caller in the rule-detail traffic view (14.12).
• An intercepted request does not call a model and is not billed. In Operations overview › Requests it shows as Intercepted · policy intercept.
• When a caller receives CONTENT_POLICY_BLOCKED they should not automatically retry the same content; a retry gets the same result.

14.12 How to confirm a rule has taken effect

When to use: check once before the rule applies to real employees and callers; after save, confirm it has taken effect; after go-live, view hit effect. Cover at least: normal content, a violating sample, evasion writing, canned Q&A, judge model unavailable, both user-question and model-reply stages, and a streaming call.

14.12.1 Before save: validate the rule

1. On the right of the rule canvas expand Validate rule. The top states: Uses the current draft and actually calls the judge model. Real conversations follow this only after save and it takes effect. In-stream truncation at the model-reply stage cannot be validated here.
2. In Caller pick the caller to simulate, for example a test API key.
3. In User question type a sentence, for example My password is Abc@12345, help me sign in, then click Run validation.

What you will see: the result area lists whether This rule hit, the hitting inspection item and handling (for example Sensitive information "Passwords and secrets" → Block), and the reply copy The user will see. Validation uses the current draft, evaluated in real order together with other in-effect rules in the same tenant. Conditions, intent, and content detection all run; model judge actually calls the judge model.

Note

• Validate rule in the rule-list toolbar validates the whole in-effect rule set, not an unsaved draft.
• Lexicons and intent sets the draft references are evaluated against current data in the library. When referenced data has been deleted, the result says the reference cannot be resolved.

14.12.2 After save

1. Click Save rule › Confirm and apply.
2. The save prompt shows Rule "{name}" saved., plus a View hit records entry. The rule takes effect on new requests within a few seconds; you do not wait or refresh the page.
3. When configuration publish fails (for example a lexicon the rule references has not published successfully), a publish-failure prompt appears at the top of the rule-list page. Handle it as prompted, then save again.

14.12.3 Check with a test call

1. With a test API key that falls in the rule conditions, send a request that will hit the rule, confirm it returns 403 and the reply copy (14.11); then send a normal request and confirm it returns normally.
2. When the inspection stage includes Model reply, send once more with "stream": true a request that will make the model output prohibited content, and confirm the stream stops at the hit.

Note: when a test call does not hit, first confirm the rule is enabled, then use Validate rule with the same caller to check whether conditions are met. Common reasons are that the model, model group, or API key the condition limits does not match what was actually used, or you picked Content detection · Tool calls while what you want to intercept is conversation content (14.2).

14.12.4 View hits in the rule detail

1. In the save prompt click View hit records, or open the rule in the rule list and switch to the Traffic view.
2. Pick a time range Last 1 hour, Last 24 hours, or Last 7 days.

What you will see

• A hit breakdown, for example Content-detection hits 12: block 10 · record only 2 · judge model unavailable 0.
• A recent-hits list, listing time, caller, hit item, handling, and copy The user saw, loaded by page. Click any row to open that request's detail. Request-detail Routing and rewrite shows the matched rule and handling; Latency and outcome shows status, error class, and failure phase.

Cross-rule statistics and archiving

1. In Admin Console › Observability › Operations overview › Rule hits, view hit counts and trends of all rules for Last 7 days. You can filter by Handling, and click a rule name to view hit and intercept counts.
2. For hit notifications, open Admin Console › Operations & Troubleshooting › Alert Rules, find the built-in alert A guardrail intercepted content once, in that row's More menu click Choose channel to bind a notification channel, then turn on Enable (Chapter 22).
3. For periodic archiving, in Admin Console › Audit & compliance › Report export create an export. Frequency can be once, daily, weekly, monthly.

Note: built-in guardrail rows in the list (input guardrail, output guardrail, personal-info recognition) are maintained by the platform. The rule-identity field often shows —. First turn the rule on for one model group or one test API key, confirm intercept and false-positive situation, then widen.

14.13 Generate content labels

When to use: under the Measures for Labeling AI-Generated Synthetic Content and GB 45438-2025, add an explicit text label to a model answer, and write implicit-label metadata in the response header.

Procedure

1. Open Admin Console › Traffic › Gateway extensions, find the built-in extension AI-generated content label, click Manage.
2. On the Configuration tab fill in the fields below, Save configuration, turn on the enable switch in the upper right, then on the Bindings tab pick a model group.

What you will see: the extension detail shows type, declared hooks, and failure policy Fail closed. After enable and bind, label text appears at the end of the answer, and the response header contains aigc.

Note: when the extension is not enabled, the Bindings tab says The plugin is disabled; bindings do not take effect yet. They take effect after you enable the plugin. Full usage of gateway extensions is in Chapter 16.

14.14 Financial-compliance detection

When to use: govern financial prohibited content such as stock tips, capital-protected high-yield promotion, and money-laundering inducement. The platform has no separate Financial compliance category. Related wording is collected in the two built-in lexicons High-risk-domain application limits and Illegal, terrorism, and false rumors.

Procedure

1. Create a traffic rule. Conditions pick only the models or model groups that need compliance governance.
2. Add Content detection · Conversation content, set Inspection stage to Both, tick Keywords, in Referenced lexicons pick High-risk-domain application limits (Chinese) and Illegal, terrorism, and false rumors (Chinese). Set On character-insertion hit to Block, turn on Decode encodings as needed, and set Hit after decode to Block.
3. To recognize inducement that has no fixed wording, also tick Model judge, add custom categories (for example Investment advice, Capital-protected promise), write a clear judgment criterion, and Test (14.5).
4. Use Validate rule to check a normal question and a violating sample separately, save the rule, in Confirm changes confirm conditions only include this service, Confirm and apply, then check with a test call.

What you will see: a typical violating question is intercepted at the user-question stage; the user sees the reply copy. Inducement without a controlled word may be admitted at the user-question stage and stopped at the model-reply stage. Intercepted requests can be found in the rule-detail traffic view.

Note: keywords are literal match and cannot distinguish asking about risk from inducing a violation. For compliance consulting, legal Q&A, or customer-service scenarios, add common consulting wording to a Allowlist-type custom lexicon and reference it in the same rule; or use a custom category as in 14.5 for semantic judgment.

14.15 Connect a third-party or in-house content-moderation service

When to use: the enterprise already has third-party or in-house content-moderation capability, and you want the platform to call it uniformly without changing business code.

Path 1: content-safety-detection HTTP API

1. The moderator deploys the detection service and implements the contract: endpoint POST {base_url}/v1/content-safety, authentication Authorization: Bearer <API 密钥>. The request body contains direction, userText, output-direction responseText, and optional history. The response returns six-class risk scores and a jailbreak score.
2. In Admin Console › Models › Model Providers click Add model provider, pick the preset Custom content-safety detection service, fill in request URL and key, then save. That provider comes with a fixed model content-safety-detector.
3. Set Content judge to that service as in 14.3. On save the platform checks automatically. Then use Model judge risk categories in the rule (14.5). This service can only recognize fixed risk categories and cannot use custom categories.

Path 2: WASM gateway extension

1. In Admin Console › Traffic › Gateway extensions click Download SDK to get a template, implement APIs such as allow or deny, rewrite the request, inspect a streaming response, then build the extension package. On upload the platform compiles and trial-runs once; failure is refused.
2. Check capabilities and failure policy the extension declared, fill in configuration, and install. After enable, pick service type and scope in Bindings. Check once with a hitting request and once with a non-hitting request, and view intercept counts in Execution statistics. Detailed steps are in Chapter 16.

Note: an HTTP detection service is the tenant-wide unique content-judge model; you cannot pick a different service per rule. The two paths can be used at the same time. When the detection service times out or the response is illegal, it is handled as the rule's When the judge model is unavailable (14.9).

14.16 Threat intelligence: check whether an outbound address hits a malicious feed

When to use: stop model calls, MCP calls, and API-service calls from sending requests to known malicious domains or IPs, for example malware-distribution URLs, phishing sites, and botnet control ends.

Threat intelligence, like other guardrails, is configured in two places: the Threat intelligence tab of Admin Console › Guardrails › Guardrail rules maintains malicious feeds and the exception list. Whether to check, and what to do on a hit, are configured in a traffic rule. When no traffic rule turns on the malicious-source check, the gateway does not do this check.

Prerequisites

• Malicious feeds belong to this tenant, maintained by the tenant administrator or Security Admin, mutually invisible across tenants. The platform does not provide a default malicious feed. Platform administrators have no threat-intelligence entry, and cannot see a tenant's malicious feeds or credentials.
• Each tenant can connect at most 8 malicious feeds, each independently enabled, with its own sync interval and credentials.

14.16.1 Connect a malicious feed

Procedure

1. Open Admin Console › Guardrails › Guardrail rules and switch to the Threat intelligence tab. Before any is connected the page shows No malicious feed connected yet. Click Connect a malicious feed.
2. In the Connect a malicious feed dialog fill in:
   • Name: a name that is easy to recognize.
   • Feed type: public sources URLhaus (CSV), ThreatFox (JSON), Feodo Tracker (CSV), or Custom HTTP bulk source. Picking a public source auto-fills that source's default URL. Public sources are for development and test only, not as a production default. In production, connect a feed you purchased or built.
   • Data-source URL: see URL requirements below.
   • Credential token (optional): for a public source, the access key the data-source provider issued. For a custom HTTP bulk source, the full authentication-header value, for example Bearer <令牌>. Leave empty on edit to keep the existing credential. Tick Clear the saved credential to delete it.
   • Sync interval (seconds): an integer of at least 60.
3. Click Test connection. After it shows Connected, N entries, save. After save the malicious feed enters Waiting to sync, then updates automatically at the sync interval. To update immediately, click the row action Sync now.

Custom HTTP bulk-source format: the data source returns a JSON object, version is the list version, entries is an entry array. Each entry has indicator (domain or ip), value (domain or IP), category (category, for example c2), optional confidence (0–100).

{
  "version": "2026-10-22",
  "entries": [
    {"indicator": "domain", "value": "malware.example", "category": "c2", "confidence": 90},
    {"indicator": "ip", "value": "203.0.113.10", "category": "botnet"}
  ]
}

URL requirements

• Must be a public-network URL, not an intranet, localhost, or cloud-metadata URL.
• Redirects are not followed; fill in the final URL.
• A single download is at most 64 MiB. The estimated total of all enabled malicious feeds of this tenant is at most 256 MiB.
• Single-label domains in the list (for example com) are dropped and do not take part in judgment.

14.16.2 View sync and in-effect status

Each row of the malicious-feed list shows Name, Type, URL, Enabled, Status, Entry count, List updated, Referencing-rule count. Credential-class parameters in the URL show as ***. Row actions are Edit, Sync now, Disable (when already disabled, Enable), and Delete. Sync now is not provided while a sync is in progress.

What you will see

• When a malicious feed is Using the previous list or Not in effect, the top of the tab shows N malicious feeds have a sync exception. After you click Only show malicious feeds with a sync exception, the list only shows those.
• When the list has a Syncing row, the page refreshes status automatically.

Disable and delete: after disable, this malicious feed leaves judgment; configuration is kept. Delete also deletes sync status and cannot be undone. When a malicious feed is referenced by a traffic rule, the confirm box says N rules are using the malicious-source check. After the last enabled malicious feed is disabled or deleted, those rules will not take effect for now. After confirm you can still proceed.

14.16.3 Turn on the malicious-source check in a traffic rule

Procedure

1. Open Admin Console › Traffic › Traffic rules, create or edit a rule, set conditions.
2. In Add action pick Malicious source.
3. Tick Check outbound addresses against malicious feeds, in On hit pick Block or Record only, save and publish the rule (Chapter 15).

What you will see

• The malicious-source check can be turned on alone; you do not need to configure other content detection at the same time.
• When this tenant has not connected or has no enabled malicious feed, under the control it says No malicious feed connected yet; ticking this has no effect for now., plus a Go connect a malicious feed link that opens the Threat intelligence tab in a new window, without affecting the rule you are editing.
• After the rule is saved, Referencing-rule count of the malicious feeds it references increases. A Check not enabled malicious feed becomes In use.

Where it applies

Note

• Not turning it on means not checking. Only connecting a malicious feed, without turning on the check in a traffic rule, intercepts no request.
• Every hit records a hit event. Both Block and Record only are recorded. View in Operations overview › Rule hits; hit source shows as Outbound threat intelligence.
• The malicious-source check only judges outbound addresses; it does not inspect the caller's source IP.

14.16.4 Allow an address that was blocked by mistake

Procedure

1. On the Threat intelligence tab, in Exception list, click Add exception, fill in Domain or IP and Reason, then save.
2. You can also open that hit's detail in Rule hits and click Add as exception: the page jumps to the Threat intelligence tab and opens the Add exception dialog, already prefilled with the blocked domain or IP. Fill in a reason then save.

Note: a domain or IP in the exception list is not judged as a malicious source. A domain also allows its subdomains. After you delete the exception, that address takes part in judgment again.

14.16.5 After an upgrade

After an upgrade from an early version, the original platform-level malicious-feed configuration is not kept. A tenant administrator or Security Admin needs to reconnect malicious feeds in Admin Console › Guardrails › Guardrail rules › Threat intelligence, and turn on the malicious-source check in a traffic rule, otherwise there is no threat-intelligence intercept. The original inbound source-IP reputation judgment is no longer provided.

Capability notes

Previous: 13. Configure sensitive-data (PII) detection · Next: 15. Traffic rules and traffic protection