Guardrail changes not taking effect

You changed a guardrail’s action, threshold, or stage, but requests still come back exactly like they did before. Guardrails have two edit paths: the check cards on the Rules tab go through Save & Activate, while the Overview tab’s Edit dialog saves on its own. Three causes account for almost every case, plus one run to confirm the fix landed.

Check for the unsaved-changes banner

Go to Gateway > Guardrails > Rules. If an info banner sits above the check cards reading “You have unsaved changes. Save to push guardrail config to the gateway.”, with Reset and Save & Activate buttons, your edit never went live.

Click Save & Activate. If you’ve saved and behavior still hasn’t changed, move on to the next check.

Check the guardrail’s Stage

If the banner is clear and the change definitely saved, go to Gateway > Guardrails > Overview, click the guardrail row’s pencil icon button, and look at Stage. It’s one of pre, post, or both.

• Staged to pre but expecting it to catch something in the response? It never will: pre only looks at what goes in
• Staged to post but expecting it to block the request itself? It never will either: post only looks at what comes back
• Staged to both? It sees both sides, since both is the same check running once on the way in and once on the way out; see Understanding Protect

Match Stage to the side of the exchange you actually need checked.

If the toggle failed

If you flipped the Enabled switch on the guardrail’s row in the Overview tab and saw the “Failed to toggle guardrail” error toast instead of a success toast reading “<guardrail name> enabled”, the enabled state itself never changed. Retry the toggle and don’t move on until you see the success toast instead of the error toast.

Confirm with a Test tab run

The fastest way to know whether any of these fixes worked, rather than waiting on real traffic, is one run in Gateway > Guardrails > Test. Send a prompt that should trigger the check and read the result chip in the Result card: it reads BLOCKED (446), WARNING (246), or OK with the status code, showing whether the guardrail fired on that prompt or let it through.

If the test still doesn’t fire

If the banner was clear, the toggle succeeded, the Stage already matched what you needed, and the Test tab run still shows the guardrail not firing, the cause isn’t a leftover unsaved change or a stage mismatch. Contact support@futureagi.com with the guardrail’s name, its Stage and Action, and the prompt you tested with.

Dive deeper