Why Gateco Denies on Policy Errors — and When to Change It

Every authorization system must answer one question: when something goes wrong — a timeout, a misconfigured rule, a missing dependency — does it allow access or deny it? Gateco denies. This is called fail-closed behavior, and it is the default for every organization.

What triggers a fail-closed denial

Fail-closed fires when the policy engine encounters an error it cannot resolve during evaluation. Common triggers: a database timeout when fetching metadata for a resource; a policy condition referencing an attribute that is missing from the principal's IDP sync; a connector that returns an error instead of retrieval results; an internal policy engine exception. In all of these cases, the retrieval is denied and the audit trail records the outcome with decision=error_deny and the error detail.

Fail-closed does not fire for legitimate policy denials. When a policy evaluates cleanly and the outcome is deny — because the principal lacks the required role, the resource is classified above their clearance, or a deny policy explicitly blocks access — that is a normal policy decision, not an error. Fail-closed only fires when evaluation itself cannot complete.

Reading fail-closed events in the audit log

Fail-closed denials appear in the audit log as retrieval_denied events with the failure_mode field set to closed and an error_detail string describing the specific failure. You can filter for these in the dashboard audit view or export them via the API. A cluster of error-deny events typically indicates a misconfigured metadata resolution mode or a policy condition that references a principal attribute not present in your IDP sync — both are worth investigating immediately.

The EU AI Act connection

Article 15 of the EU AI Act requires that high-risk AI systems operate correctly under degraded conditions. Fail-closed is the technical implementation of that requirement at the retrieval layer. When your auditor asks "what happens if a policy cannot be evaluated?", the answer is "access is denied and the event is logged." Not "we are not sure" or "it falls through to the next handler." This is a defensible position; the alternative is not.

When fail-open makes sense

There are legitimate use cases for fail-open behavior: high-availability public knowledge bases where a momentary policy engine error should not block all access; assistants serving fully public content; systems where the cost of a false denial exceeds the cost of a momentary false allow. Gateco supports fail-open through the failure_mode configuration on each organization (open_with_audit). In fail-open mode, policy evaluation errors result in an allowed retrieval — but the event is logged as retrieval_allowed with failure_mode=open_with_audit, making the fallback fully auditable.

Fail-open is an Enterprise option, available through a support request. It is off by default for every organization. For regulated industries and any system processing sensitive data, fail-closed is not optional. For lower-stakes deployments, the tradeoff is clear and the configuration exists. The failure_mode is visible in Organization Settings and in the GET /api/organization/settings response.