Guardrails

Guardrails let an application apply safety policies across AI traffic. They are configured per application in Applications -> your application -> Modules -> Guardrails.

Guardrails are designed to be understandable from the UI: choose what to detect, how sensitive the policy should be, and what Optiak should do when something is detected.

Use guardrails to reduce the risk of unsafe prompts, prompt injection attempts, personal information exposure, and sensitive data leakage while keeping policy decisions visible in observability.

Prompt Injection Detection

Prompt Injection Detection identifies attempts to override system instructions or manipulate the model outside the intended task.

When enabled, configure:

• Sensitivity - Higher sensitivity catches more suspicious prompts but may increase false positives.
• Action - Block detections or only record them.
• Block response mode - Return an assistant refusal response or return HTTP 403.

Use Detect (no action) when you want to measure impact before enforcing a blocking policy. Use Block when detected traffic should be rejected according to your application policy.

PII Detection

PII Detection identifies personal and sensitive information so it can be handled according to your application policy.

When enabled, configure:

• Entity groups - General information such as names and contact details, financial data such as payment cards and bank identifiers, and IT data such as network addresses, URLs, and AWS credentials.
• Sensitivity - Higher sensitivity catches more possible matches but may increase false positives.
• Action - Block detections, redact detected entities, or only record them.
• Block response mode - When blocking, return an assistant refusal response or return HTTP 403.

Use Redact when the request can still be handled safely after masking detected entities. Use Block when the request should not continue.

Block Response Modes

Guardrails can block in two ways:

• Refusal - The API returns a normal model-shaped response with an assistant refusal. This is useful when the calling application expects a successful response shape.
• Forbidden - The API returns HTTP 403. This is useful when the calling application should treat the request as rejected by policy.

Both modes enforce the same safety decision; choose the response shape that best matches how your application handles rejected traffic.

Observability

Guardrail activity appears in observability views. Use those views to understand:

• Whether requests were blocked, redacted, or only audited.
• Whether sensitivity settings are producing the expected behavior.
• How guardrails affect application traffic over time.