Request risk routing: classify the action before choosing a response

Last updated: 2 Oct 202611 min read

tutorial

A request-risk router identifies the requested effect and the data needed before a response is drafted. It should distinguish ordinary information, an ambiguous request that needs clarification, a disallowed disclosure, and a consequential action requiring an authorized workflow. The prompt may help describe the request, but deterministic account permissions and server-side policy determine what data or tools are available. Include benign near-neighbors in evaluation so a broad keyword filter does not block ordinary support. Record the route, reason code, and whether the response stayed within that route.

Decision in practice

A support assistant receives four messages about account AC-682. One asks when the next invoice is due; one asks to change a bank destination; one asks for another customer's invoice; one says the account may be compromised. A single polite-answer prompt can blur all four. The router sends the first to verified billing data, the second to an authenticated change flow, the third to a no-disclosure response, and the fourth to the incident channel. If the requester has not been verified, the assistant can explain the verification process but must not reveal private balances while it waits.

AC-682: next invoice date -> read verified billing field.
AC-682: change bank destination -> authenticated action flow.
Other account's invoice -> deny disclosure; no lookup result returned.
Possible compromise -> incident review route.
Log: route code, permission check, prompt bundle; no raw bank details.

Performance and operating cost

A deterministic router over F typed fields is O(F), while a model classifier adds a call and another failure mode. Use the cheaper rule when the distinction is explicit, and test ambiguous language with representative cases. The measurable costs include false refusals, missed risky requests, review volume, and latency. Routing cannot compensate for a tool that returns records without checking account ownership. A route that asks for human review should preserve enough context for that reviewer without copying irrelevant private data.

Common Mistakes

Do not route only by a single risky keyword.
Do not fetch private data before checking the requester's scope.
Do not describe a model's route label as authorization.

Connected lessons

Continue with: Mixed-language requests: separate intent from reply language.

prompt engineering

safety decisions