What happens when an AI safety check stops working?
Every AI safety check is a gate. When the gate breaks, it either swings open or swings shut. 'Fails open' means harmful requests pass unchecked at the exact moment the check is struggling. 'Fails closed' means all requests stop, including harmless ones. The honest question is not which failure mode you prefer — it is how you make failure rare enough that the question rarely matters. GROX executes real work — messages send, payments settle on-chain, applications deploy — and when it is about to send, post, pay, call or change something for you, it puts up a card saying what will happen and acts only when you press Approve.
What do 'fails open' and 'fails closed' actually mean?
A safety check that fails open behaves like a bouncer who waves everyone through when they feel unwell. The check is still nominally present, but it is not doing its job. Requests that would normally be refused get through, and the system behaves as though no check existed. The danger is that this tends to happen under load or degraded conditions — precisely when unusual volumes of requests are arriving.
A safety check that fails closed behaves like a door that locks when the power cuts. Nothing passes. Users who wanted perfectly ordinary things are turned away alongside anyone with bad intentions. The system is safe in the narrow sense that nothing harmful escapes, but it is also useless. Depending on what the system does — monitoring infrastructure, processing medical queries, routing urgent communications — 'useless' can itself cause harm.
- Fails open
- The check stops running but requests continue to be processed, bypassing the guard entirely.
- Fails closed
- The check stops running and all requests are blocked until the check recovers.
- Graceful degradation
- The check enters a reduced mode — perhaps applying a simpler rule set — rather than choosing between the two extremes.
- Circuit breaker
- A pattern that detects repeated failures and deliberately switches to a known fallback state rather than letting partial failures accumulate.
Why is a check that fails open worse than no check at all?
A system with no safety check at all is at least honest about what it is. Engineers and operators know they are working without a net and can make decisions accordingly. A system with a check that fails open under pressure gives the appearance of safety without the substance. Operators may believe the check is running when it is not. Auditors may see logs that show the check was invoked without seeing that it returned a default 'allow' rather than a genuine assessment.
There is also a timing problem. Failures in safety checks tend to correlate with the conditions that make failures most consequential: high traffic, unusual inputs, cascading errors elsewhere in the system. A check that works perfectly at low load but waves everything through under stress is providing safety theatre rather than safety.
What does 'fails closed' actually cost you?
The cost of failing closed is availability. When the check is down, nothing works. For some applications this is the right trade-off — a system that controls access to sensitive data probably should stop rather than guess. For others, the calculus is different.
Consider a customer service agent that handles thousands of routine queries per day. If the safety layer fails closed during a two-hour outage, every one of those queries is blocked. The harm from the outage may exceed the harm that would have resulted from the small fraction of queries the check would have caught. This does not mean failing open is the right answer — it means the honest engineering order is to make the check reliable first, and only then decide what it should do when it fails.
A simpler rule-based filter that runs locally and rarely fails is often a better foundation than a sophisticated model-based check that fails unpredictably. Sophistication is not the same as reliability.
| Failure mode | What users experience | What passes through | Typical use case where this is preferred |
|---|---|---|---|
| Fails open | No interruption | Everything, including harmful requests | Almost never the right choice |
| Fails closed | Complete outage | Nothing | Access control for sensitive data |
| Graceful degradation | Reduced capability | Low-risk requests only | Consumer-facing services with mixed traffic |
| Circuit breaker with fallback | Partial outage, clear messaging | Pre-approved safe defaults | Infrastructure and monitoring systems |
Is there a sensible order of priorities when designing for failure?
Yes, and the order matters. The first priority is making the check reliable enough that failure is a rare event rather than a routine one. This means redundancy, monitoring, fast recovery and — critically — testing the check under the conditions that cause failures, not just under normal load. A check that has never been tested at ten times its usual traffic is an untested check.
The second priority is deciding what the check should do when it does fail. That decision should be made in advance, documented, and agreed by the people who bear the consequences of each failure mode. It should not be an implicit default chosen by whichever engineer happened to write the error handler.
The third priority is making the failure visible. A check that fails silently — logging nothing, alerting nobody, returning a default response indistinguishable from a genuine assessment — is the worst outcome. Operators cannot fix what they cannot see.
Only after those three priorities are addressed does it make sense to debate the philosophical question of which failure mode is more ethical. That debate, conducted without the engineering foundations in place, is a way of feeling rigorous without being rigorous.
- Make the check reliable first — redundancy, load testing, fast recovery.
- Decide the failure mode explicitly, in advance, with the people who bear the consequences.
- Make failures visible — log them, alert on them, distinguish them from genuine assessments.
- Review the failure mode decision periodically as the system's role and traffic change.
How does GROX handle actions it takes on your behalf?
When GROX is about to send, post, pay, call or change something for you, it puts up a card saying what will happen and acts only when you press Approve. You can change the card's wording before approving. Reading, searching and drafting run at once, without a card. Without a card, GROX acts only inside an allowance you set ahead of time or a routine you have switched to autopilot.
For trading strategies, GROX turns your idea into a strategy you can read, tests it on past prices before any real money moves, and runs it inside limits you set in advance — size per trade, a stop, a daily loss cap — so it asks before it spends. You can pause, change or stop a running strategy with a sentence in the chat. A practice mode runs the same strategy with no money at risk. Because the limits are written down before anything happens, the system's behaviour in edge cases reflects choices you made in advance.
- Sending, posting, paying, calling or changing something: GROX puts up a card describing what will happen and acts only when you press Approve.
- You can change the card's wording before approving.
- Reading, searching and drafting run at once — no card required.
- Without a card, GROX acts only inside an allowance you set ahead of time or a routine you switched to autopilot.
- For trading, GROX tests a strategy on past prices before any real money moves, and runs it inside limits — size per trade, a stop, a daily loss cap — that you set in advance.
- Pause, change or stop any running strategy with a sentence in the chat.
Common questions
Can an AI safety check fail open without anyone noticing?
Yes. If the check returns a default 'allow' response when it encounters an error, the system continues to process requests and logs may show the check was invoked. Without explicit monitoring for error states — as distinct from monitoring for invocations — operators may not realise the check has stopped doing meaningful work. This is why logging the outcome type, not just the invocation, matters.
Is failing closed always the safer option?
Not always. Failing closed is safe in the narrow sense that nothing harmful passes through, but availability failures carry their own costs. A system that monitors critical infrastructure, routes urgent communications, or processes time-sensitive requests can cause real harm by stopping entirely. The right failure mode depends on what the system does, not on a general principle that blocking is always safer than allowing.
What is graceful degradation in the context of a safety check?
Graceful degradation means the check enters a reduced but still functional mode when its primary mechanism fails. For example, a sophisticated model-based check might fall back to a simpler keyword filter rather than choosing between full operation and complete shutdown. The fallback is less capable but more reliable, and it is applied only to traffic that the system judges low-risk. Higher-risk requests are held or declined until the primary check recovers.
How should teams decide between failing open and failing closed?
By working through the consequences of each failure mode with the people who bear them, before any failure occurs. In GROX, when it is about to send, post, pay, call or change something, it puts up a card describing what will happen and acts only when you press Approve. Autonomous action runs only inside an allowance you set ahead of time or a routine you have switched to autopilot — so the boundaries are decided before any edge case arises.
If you are building automations that act on your behalf — sending messages, executing trades, deploying code — GROX lets you set explicit limits and approval requirements in advance, so the system's behaviour during edge cases is something you have chosen rather than something that surprises you.