Fail Closed or Fail Open? Why Your AI Traffic Keeps Flowing
Every safety check can fail. Cloptima keeps your traffic flowing by default, lets each guardrail profile choose to block instead, shows you what went unchecked, and makes credit-funded spend wait for its budget decision.
In this post
Every safety check can fail
A guardrail provider has an outage.
A credential expires. A counter lookup times out. Safety checks are software, and software fails, usually at the least convenient moment.
Picture this
At 2 a.m. the safety service behind your customer-facing assistant stops responding. Customers are mid-conversation. With Cloptima, nobody has to wake up to decide what happens next: the assistant keeps answering on your own rules, and every request that went without the scan is on record for the morning.
That outcome is the default, and it is a decision we made on purpose. For guardrail scans, you can choose the other way. This post explains both.
Who a check protects decides what happens
Some checks protect your governance: your budgets, your limits, your guardrails.
One kind protects money Cloptima fronts for you: the credits that pay for requests. Cloptima treats the two differently.
Your governance keeps flowing
- A rate limit or agent limit that cannot be checked lets the request continue
- A guardrail scan that cannot run continues on your local rules, unless its profile is set to block
- Your local guardrail rules have already run
Cloptima credits wait
- A request on Cloptima credits waits for its budget decision
- It stops if there is no decision
- A credit balance is never overdrawn by a guess
Every policy follows these rules, so a customer-facing assistant and an internal prototype behave the same way during an incident. The only difference is the one you choose for a guardrail profile.
Why your traffic keeps flowing
Your budgets, limits, and guardrails exist to protect you from your own traffic.
When a Cloptima service has a bad minute, blocking that traffic would turn our incident into yours.
- Your app stays available while a provider or a Cloptima service recovers
- Your own guardrail rules still run, so secrets and the patterns you wrote are still caught
- Every check applies again as soon as it can run
Guardrail scans: your choice
Some teams would rather pause an app than let it answer without its safety scan.
So each guardrail profile chooses what happens when its scan cannot run.
Continue on local rules (the default)
- The request goes on with your local rules
- It shows as Not checked, so you see exactly what went without the scan
Block the request
- The request is refused until the scan can run again
- Your app gets a clear refusal it can handle
Choose Block for the apps where an unchecked answer costs more than a paused one, and keep the default everywhere else.
See what was not checked
A scan that could not run should never be invisible.
Cloptima shows you, without a flood of alerts.
- Requests that continued without their scan appear as Not checked, grouped by cause, policy, and app, with the fix for each cause
- Your dashboard flags a scan that is not running while it is happening, whether requests continue or are blocked, and clears the flag once scans run again
- An alert on requests whose scan could not run, continued or blocked, reaches your team with your own threshold
What happens, precisely
Vague promises are not useful in an incident.
This is what each situation does for a policy with a provider guardrail scan, under each choice.
| Situation | Continue on local rules | Block the request |
|---|---|---|
| Provider times out or returns an error | Continues, shown as Not checked | Blocked |
| Provider credential missing or revoked | Continues, shown as Not checked | Blocked |
| Cloptima-managed scan cannot be funded | Continues, shown as Not checked | Blocked |
| A rate or agent limit cannot be checked | Continues | Continues |
| A request on Cloptima credits cannot get its budget decision | Waits, and stops if there is no decision | Waits, and stops if there is no decision |
| A local rule matches | Handled by the rule's action | Handled by the rule's action |
Never a substitute
One principle sits under all of this.
When a check cannot run, Cloptima does not quietly swap in a different one.
- A request that continues runs on your own local rules, which have already run
- Cloptima never adds detection you did not configure to cover a gap
You decide what is checked. Nothing else is.
Make misses rarer
The best missed check is the one that never happens.
A few settings keep a provider scan from becoming a weak point.
1Local rules
No network call
2Provider scan
Only if still needed
3Model call
4Response checks
As the answer streams
- Put the rules that matter most in your local guardrails. They run inside the gateway and never wait on an outside service.
- If you use Cloptima-managed scans, keep your AI credits funded.
- Keep provider credentials current, and rotate them before they expire.
- Set an alert on requests whose scan could not run, so your team hears about a scan that stopped running, whichever choice the profile makes.
A sensible routine
Keep the default unless an app must never answer without its scan.
A short routine keeps every check running.
- Write the rules you cannot do without as local guardrail rules
- Choose Block only for the profiles that need it
- Review your guardrail findings and Not checked requests each week
- Keep provider credentials current, and rotate them before they expire
- Keep your AI credits funded if Cloptima runs your scans