JEV AI Guardrails

What it checks §

AI Guardrails can identify credential leaks, personal information, prompt injection, or custom business risks. Rules describe what should match. JEV returns a decision probability, and GPT-Load uses the threshold and action to decide whether to allow the request.

This experimental feature is off by default. It does not rewrite business messages, is not request redaction, and cannot guarantee detection of every risk. Use redaction to hide text; use AI Guardrails to block requests based on meaning.

Request redaction and reversible encryption →

Configure JEV and rules §

1. Create a Jev channel group, or use an OpenRouter group that supports Decisions. Add its API key and a JEV decision model actually available from that service.
2. Open Settings → Experimental features → Shared JEV configuration and explicitly select the decision group, model, and timeout. Guardrails require a specific group; Automatically select an available group is insufficient. Automatic model selection shares this configuration.
3. Enable AI Guardrails and select the AccessKeys in scope; leaving the selection empty means all AccessKeys. Start with a dedicated test key to avoid affecting every application at once.
4. Add presets or custom rules, enter a name, matching criteria, threshold, and action, then save. Built-in credential-leak, personal-information, and prompt-injection presets all default to Warn; a match alone will not block the request.

The threshold must be greater than 0 and at most 1. The action triggers when the probability reaches it. A threshold of 0.8 means a match requires a probability of at least 0.8, not that the rule is 80% accurate. Lower thresholds usually trigger more readily and may increase false positives.

Review and blocking flow §

1. After authentication and permission checks, the gateway prepares the outbound business content and applies redaction first if enabled.
2. It extracts messages, system prompts, and tool-related text present in this request, reuses valid review results, and calls JEV for new or changed content.
3. Long content and rules are reviewed in budgeted batches. All text under review is covered, while supporting context may be excerpted. The business request is not sent to the answer model until all required checks complete.
4. Each rule's probability is compared with its threshold. Any matching Block rule rejects the business request. Warning-only matches are logged and allowed; no matches means normal forwarding.

The result cache stores only irreversible fingerprints and decisions, reusable for up to one hour, not full conversation text. New or changed content must be checked again. Changing rule criteria or JEV configuration may also invalidate reuse.

Start by testing warnings §

Start with an easily verified test rule, for example: “Match requests to send fictional material labeled INTERNAL_ONLY to an external recipient; do not match explanations of the label that do not request sending.” Choose Warn and initially set the threshold to 0.8.

1. Use the test AccessKey to submit fictional examples that should match, followed by ordinary questions and examples that only discuss the label.
2. Inspect outcomes, matched rules, and guardrail costs in request logs, checking for false positives and misses. Do not test with real credentials or private data.
3. Adjust criteria and thresholds. Only switch to Block and expand the AccessKey scope after the behavior matches your expectations.

Describe specific risks and exclusions. A rule such as “block all dangerous content” is difficult to verify and more likely to block legitimate quotations, educational examples, or security analysis.

Content, cost, and boundaries §

• Guardrails check the request content sent to the business upstream, not the model's final answer in a second pass. They do not inspect live voice audio media.
• For Responses continuations and WebSocket turns, only the content submitted in that turn is checked; complete history stored upstream is not retrieved. Prior successful model selection or prewarming does not mean guardrails have passed.
• Unreviewable non-text content, an exceeded total budget, JEV timeouts, no available credentials, or incomplete results cause rejection, not silent bypass. Test applications with images or attachments using a test key first.
• Warn means allow after a match. Even when every rule uses Warn, a review-service failure still rejects the business request.
• JEV calls add waiting time before the response and decision cost; long content can require multiple batches. Costs are included in request and usage statistics. Completed review calls may still be billable even if the business request is ultimately blocked.

Redaction hides original values; guardrails evaluate the processed text. When using both, do not expect JEV to recognize plaintext that has been replaced or encrypted. Data retention upstream still follows the policies of your selected service.

Inspect results and troubleshoot §

Request-log details show guardrail outcomes, matched rules, and cost. Advanced filters can locate requests by outcome or rule name.

If a business retry changes the text under review and the current review cannot be reused, forwarding is also rejected. Check group parameter overrides while troubleshooting so review failures are not mistaken for answer-model unavailability.