Scenarios
Sensitive information routing is used to automatically route requests to different model services based on whether the request content contains sensitive information. Requests containing sensitive information are forcibly routed to private or locally deployed models, while requests without sensitive information are routed to public cloud models.
Unlike the existing "direct interception" and "inline alarm" approaches in the content security module, sensitive information routing does not intercept or desensitize requests. Instead, requests are forwarded to another model service, requiring no changes to the business-side calling code and causing no interruption to the user experience.
Typical use cases:
|
Automotive / Manufacturing | Vehicle model codes, supplier contracts, and internal project numbers | Local private cluster | Public cloud model |
Finance / Banking | Customer account numbers, identification numbers, transaction records, and internal policy documents | In-house private model | Low-cost public cloud model |
Healthcare / Health | Medical records, patient names, and diagnostic reports | In-hospital deployment model | General-purpose public cloud model |
Government / Energy | Project documents, equipment drawings, and internal directive documents | Government private cloud model | Public cloud model |
The detection logic reuses the lexicon policies already configured in "Security Protection > Content Security", eliminating the need to maintain lexicon entries on the routing side.
Note:
Sensitive information routing serves as an optional front layer in the routing framework. When it is not enabled, the existing routing configuration behavior remains completely unchanged.
Prerequisites
An AI Gateway instance has been created, and it is in the Running state.
At least one lexicon policy has been configured in "Security Protection > Content Security", and the policy is enabled, with the post-match action set to "Allow", and has been bound to the target model API.
The target model services for both the hit side and the miss side have been created.
Operation Steps
Step 1: Configuring a Content Security Policy
Sensitive information routing can only reference content security policies that meet the admission criteria, so policy preparation must be completed first.
1. Log in to the AI Gateway console. In the instance list, click the target instance name to go to the instance details page. 2. In the left sidebar, click Security Protection > Security Policies.
3. In the Content Security section, create a policy and confirm the following three configurations:
Policy Status: Enabled.
Post-Match Action: Select Allow. Do not select "Block" or "Alert".
Detection Direction: Select Input Only.
4. Bind the policy to the target model API.
Note:
The post-match action must be set to "Allow". If it is set to "Block", the content security layer returns an error directly before the request reaches the routing layer, and sensitive information routing cannot perform forwarding. This is a prerequisite for the routing and forwarding capability to take effect.
Step 2: Entering the Model API Configuration Page
2. In the left sidebar, click Model Management > Model API.
3. Click Create Model API, or click an existing API name to go to its details page and edit it.
4. Enter the API name, select basic information such as the use case and request protocol, and then click Next.
Step 3: Enabling Sensitive Information Routing and Selecting a Detection Policy
After you go to the Sensitive Information Routing step:
1. Turn on the Sensitive Information Routing switch to expand the configuration area.
2. Select a content security policy from the Detection Policy dropdown list. The dropdown list only displays policies that meet all admission criteria.
3. After selection, the configuration area automatically displays a preview of the selected policy's details, including its enablement status, post-match action, detection direction, and number of entries.
Note:
If the dropdown list is empty, none of the policies bound to the current model API meet the admission criteria. In this case, the dropdown list is hidden, and the page displays a message guiding you to go to "Security Protection > Content Security" to create or modify a policy before you return to the configuration.
4. Configure the target service for the hit side, which corresponds to the "request contains sensitive information" branch. It is recommended to configure a private or locally deployed model service.
Step 4: Configuring the Missed Target Service
The miss side corresponds to the "request does not contain sensitive information" branch. It is recommended to configure a public cloud model service.
Step 6: Saving and Verifying
Click OK to save the configuration, and the policy takes effect immediately.