Skip to main content
At Portkey, we believe in helping you make your workflows as modular as possible. This is useful when:
  • You want the same Guardrail checks but want to take different basic actions on them
  • Your Guardrail checks definitions are dependent on an upstream task and are updated in code
  • You want greater control over how you want to handle Guardrails
With the Raw Guardrails mode, you can achieve all this.

Example of a Raw Guardrail

In this example:
  • type: Specifies the type of hook, which is guardrail.
  • name: Gives a name to the guardrail for identification.
  • checks: Lists the checks that make up the guardrail. Each check includes an id and parameters for the specific conditions to validate.

Configuring Guardrail Actions

In this example,
  • deny: Is set to TRUE or FALSE
  • async: Is set to TRUE or FALSE
  • sequential: Is set to TRUE or FALSE - when TRUE, guardrail checks run one after another instead of in parallel
  • on_success: Used to pass custom feedback
  • on_failure: Used to pass custom feedback

Forwarding Client Headers

You can forward specific client request headers to a guardrail provider by adding forwardHeaders inside the check’s parameters:
  • forwardHeaders: Optional string[] of client headers to forward to this check’s provider. If omitted, no client headers are forwarded. See Forwarding Headers for restricted headers and configuration details.

Portkey is now PRISMA AIRS AI Gateway. See it in action.

Contact Us
Last modified on August 17, 2026