The Request Parameters Check is a BASIC deterministic guardrail that inspects the incoming request body and enforces allow/block rules on:
- Tools declared in the request (
tools[].type, tools[].function.name, tools[].name)
- Top-level request parameter keys (e.g.
stream, temperature, tools, logprobs)
- Values for specific top-level parameters (e.g.
model=gpt-4o, stream=true)
If any rule is violated, the guardrail returns a failure verdict with a structured explanation of what was blocked and why. The gateway then denies or flags the request based on the action configured on your Guardrail.
This guardrail runs on input only (beforeRequestHook).
Using Request Parameters Check in Portkey
1. Add the Request Parameters Check
-
Navigate to the
Guardrails page and click the Create button
-
Search for “Request Parameters Check” in the BASIC category and click
Add
-
Configure the check (all fields are optional - leave a list empty to skip that constraint):
Tools
- Allowed Types - strict allow list of tool
type values (e.g. function, web_search_preview, web_search, file_search, code_interpreter, computer_use, mcp)
- Blocked Types - tool
type values to reject
- Allowed Function Names - strict allow list for
tool.function.name / tool.name
- Blocked Function Names - function names to reject
Params
- Allowed Keys - strict allow list of top-level keys in the request body
- Blocked Keys - top-level keys to reject
- Values - per-parameter rules. For each parameter (e.g.
model, stream, temperature) you can set allowedValues and/or blockedValues. Values must be primitives (string, number, or boolean).
-
Set any
actions you want on your check, and create the Guardrail!
Guardrail Actions let you orchestrate your guardrail’s behaviour (deny, feedback, etc.). Learn more about them here. | Check Name | Description | Parameters | Supported Hooks |
|---|
| Request Parameters Check | Allow/block tools, top-level request keys, and specific parameter values | tools (object), params (object) | beforeRequestHook |
2. Add Guardrail ID to a Config and Make Your Request
- When you save the Guardrail, you’ll get an associated Guardrail ID - add this ID to the
input_guardrails param in your Portkey Config
- Create the Config in the Portkey UI, save it, and attach its Config ID to your requests. More here.
Example config:
{
"input_guardrails": ["guardrails-id-xxx"]
}
NodeJS
Python
OpenAI NodeJS
OpenAI Python
cURL
const portkey = new Portkey({
apiKey: "PORTKEY_API_KEY",
config: "pc-***"
});
portkey = Portkey(
api_key="PORTKEY_API_KEY",
config="pc-***"
)
const openai = new OpenAI({
apiKey: 'OPENAI_API_KEY',
baseURL: PORTKEY_GATEWAY_URL,
defaultHeaders: createHeaders({
apiKey: "PORTKEY_API_KEY",
config: "CONFIG_ID"
})
});
client = OpenAI(
api_key="OPENAI_API_KEY",
base_url=PORTKEY_GATEWAY_URL,
default_headers=createHeaders(
provider="openai",
api_key="PORTKEY_API_KEY",
config="CONFIG_ID"
)
)
curl https://api.portkey.ai/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "x-portkey-api-key: $PORTKEY_API_KEY" \
-H "x-portkey-config: $CONFIG_ID" \
-d '{
"model": "gpt-3.5-turbo",
"messages": [{ "role": "user", "content": "Hello!" }]
}'
Configuration reference
The guardrail accepts the following parameter shape. Every field is optional; an empty config is a no-op. Values in <...> are placeholders describing the expected type, not literal strings.
{
"tools": {
"blockedTypes": ["<string>"],
"allowedTypes": ["<string>"],
"blockedFunctionNames": ["<string>"],
"allowedFunctionNames": ["<string>"]
},
"params": {
"blockedKeys": ["<string>"],
"allowedKeys": ["<string>"],
"values": {
"<paramName>": {
"blockedValues": ["<string | number | boolean>"],
"allowedValues": ["<string | number | boolean>"]
}
}
}
}
{
"params": {
"values": {
"model": { "allowedValues": ["gpt-4o", "gpt-4o-mini"] },
"stream": { "blockedValues": [true] },
"max_tokens": { "allowedValues": [256, 512, 1024, 2048] }
}
}
}
tool.function?.name || tool.name || tool.type, so both OpenAI-style ({ type: 'function', function: { name: 'getWeather' } }) and Responses-API-style ({ type: 'web_search_preview' }) tools work consistently.
Allow vs. block behaviour
| List | Behaviour |
|---|
blocked* | Deny list. Matching items are flagged. |
allowed* | Strict allow list. If the list is non-empty, items not in it are flagged. If empty or omitted, there is no allow-list constraint on that axis (it does not mean “block everything”). |
type_blocked and name_not_allowed).
Scope
- Only top-level keys of the request JSON are inspected for params - nested objects and arrays are not walked.
- Only entries in the request’s
tools array are inspected for tool rules.
- Value comparisons use strict equality and are intended for primitives (
string, number, boolean).
If the same entry appears in both a blocked and an allowed list (e.g. in blockedTypes and allowedTypes), the guardrail returns a configuration conflict error. Remove the duplicate from either list.
Common recipes
Your security policy forbids auto-browsing, file uploads, code interpreter, and computer-use agents.
{
"tools": { "allowedTypes": ["function"] }
}
Block specific sensitive functions
Your agents expose many tools but some (shell execution, DB writes, payments) must be off-limits for this consumer / virtual key.
{
"tools": {
"blockedFunctionNames": ["executeShell", "dropTable", "chargeCard", "deleteUser"]
}
}
{
"tools": {
"allowedTypes": ["function"],
"allowedFunctionNames": ["lookupCustomer", "createTicket", "sendKYCReminder"]
}
}
Force non-streaming responses
Your proxy, logging, or guardrail pipeline cannot handle SSE, so stream: true must never reach the provider.
{
"params": {
"values": {
"stream": { "blockedValues": [true] }
}
}
}
Block Anthropic fast-mode (speed: "fast")
Anthropic’s fast-mode beta exposes a top-level speed parameter (e.g. "speed": "fast" alongside the anthropic-beta: fast-mode-… header). Block the value to stop it from reaching the provider while still allowing standard requests through:
{
"params": {
"values": {
"speed": { "blockedValues": ["fast"] }
}
}
}
blockedKeys instead:
{
"params": {
"blockedKeys": ["speed"]
}
}
thinking, safety_identifier, service_tier, etc.
Pin the model to an approved list
Only approved, contracted models are allowed on this key.
{
"params": {
"values": {
"model": {
"allowedValues": ["gpt-4o", "gpt-4o-mini", "claude-3-5-sonnet-20241022"]
}
}
}
}
Enforce safety settings
Prevent callers from loosening safety, sampling, or privacy knobs.
{
"params": {
"values": {
"temperature": { "allowedValues": [0, 0.2, 0.5, 0.7] },
"top_p": { "allowedValues": [1] },
"store": { "blockedValues": [true] },
"logprobs": { "blockedValues": [true] },
"parallel_tool_calls": { "blockedValues": [true] }
}
}
}
Strict parameter allow list (zero-trust body)
Callers can only send a minimal, audited set of fields - anything extra is rejected until explicitly approved.
{
"params": {
"allowedKeys": ["model", "messages", "temperature", "max_tokens", "user"]
}
}
Block dangerous parameter keys
Disable experimental or high-risk fields without enumerating everything you do allow.
{
"params": {
"blockedKeys": ["logit_bias", "seed", "tool_choice", "tools", "functions"]
}
}
Cap output length via an allowed-tier list
blockedValues and allowedValues operate on exact primitives, so true numeric ranges must be modeled as an enumeration.
{
"params": {
"values": {
"max_tokens": { "allowedValues": [256, 512, 1024, 2048] }
}
}
}
For arbitrary numeric ranges (e.g. max_tokens <= 2048), pair this guardrail with a custom plugin or upstream validation. Range comparisons are not supported natively.
{
"tools": {
"allowedTypes": ["function"],
"blockedFunctionNames": ["executeShell"]
},
"params": {
"blockedKeys": ["logit_bias"],
"values": {
"model": { "allowedValues": ["gpt-4o", "gpt-4o-mini"] },
"stream": { "blockedValues": [true] }
}
}
}
Verdict payload
When the guardrail denies a request, the failure payload in hook_results contains:
blockedToolsFound - tools that violated a rule, each with type, name, and one or more reasonsblockedParamsFound - params that violated a rule, each with param, value (if any), and one or more reasonsexplanation - a human-readable summary, e.g. Blocked tools: "executeShell" (function name is blocked). Blocked params: "stream"=true (value is blocked)
Reason codes
| Category | Code | Meaning |
|---|
| Tool | type_blocked | tool.type is in tools.blockedTypes |
| Tool | name_blocked | tool.function.name / tool.name is in tools.blockedFunctionNames |
| Tool | type_not_allowed | tools.allowedTypes is set and tool.type is not in it |
| Tool | name_not_allowed | tools.allowedFunctionNames is set and the name is not in it |
| Param | key_blocked | Top-level key is in params.blockedKeys |
| Param | key_not_allowed | params.allowedKeys is set and the key is not in it |
| Param | value_blocked | Value is in params.values[key].blockedValues |
| Param | value_not_allowed | params.values[key].allowedValues is set and the value is not in it |
Decision matrix
blocked* present | allowed* present | Result |
|---|
| No | No | No constraint on this axis |
| Yes | No | Everything passes except blocked entries |
| No | Yes | Only entries in the allow list pass |
| Yes | Yes | Entries must be in the allow list and not in the block list |
Get Support
If you face any issues with the Request Parameters Check guardrail, join the Portkey community forum for assistance. 
