Fail-closed is the right default for most security-relevant AI workflow decisions, covered throughout this content series, but treating it as an absolute rule for every single dependency with no exceptions produces unnecessary availability cost for the specific cases where the actual risk of proceeding without a check is genuinely low. Identifying these exceptions deliberately, rather than defaulting every dependency to fail-closed reflexively, keeps the overall system both safe and reasonably available.
Low-impact, easily reversible actions are the clearest candidates
An action with low impact and easy reversibility, generating a draft response a human will review before it's sent, retrieving publicly available information with no sensitivity, carries little risk if a non-critical check, maybe a supplementary content quality filter that isn't itself a security boundary, fails to complete. For these cases, proceeding without that specific check, while logging the failure for later review, avoids unnecessary availability impact for a genuinely low-stakes decision.
Purely advisory checks that do not represent a security boundary
Some checks in a workflow are advisory rather than security-critical, a supplementary quality score, a style consistency check, that inform but don't gate whether an action should be authorized. These checks can reasonably fail open, since their absence means the workflow proceeds without that specific advisory input, not that it proceeds without an actual security boundary. The key distinction is confirming a given check is genuinely advisory and not, in practice, functioning as an unacknowledged security control that just happens to be labeled otherwise.
Redundant checks where an equivalent control exists elsewhere
If a specific check is one of several redundant layers enforcing a similar control, covered in defense-in-depth guidance, and another layer reliably provides equivalent protection, that specific check's failure may reasonably fail open, relying on the remaining layers to still provide adequate protection. This takes genuine confidence the remaining layers are sufficient on their own, not an assumption that redundancy exists without ever having actually verified it.
Never fail open for anything genuinely irreversible or high-impact
Regardless of the exceptions above, any action that's genuinely irreversible or carries meaningful financial, safety, or reputational consequence should never fail open, even under the reasoning that an outage is inconvenient or that the specific failure seems unlikely. The cost asymmetry here strongly favors caution: a blocked legitimate action during a rare outage is an inconvenience. An unauthorized high-impact action that proceeded during that same outage can be a significant, sometimes unrecoverable, incident.
Document every fail-open decision with explicit justification
For any dependency deliberately configured to fail open, document the specific reasoning: why this check's absence is acceptable, what the actual worst-case consequence of proceeding without it is, who approved this deliberate deviation from the fail-closed default. This documentation, similar to the exception process covered in governance guidance, keeps fail-open decisions deliberate and reviewable rather than letting them become an unexamined default that quietly expands over time as new dependencies get added without the same scrutiny.
Revisit fail-open decisions as the workflow's context changes
A dependency reasonably configured to fail open when a workflow had low impact can become a genuine risk if that workflow's scope or impact later expands, a low-stakes internal tool that later gains higher-impact capability, say. Revisit fail-open decisions when a workflow's risk classification changes, rather than assuming a decision made under the original, lower-risk context stays appropriate forever as the workflow evolves.
Monitor fail-open events even though they do not block anything
Even for a deliberately fail-open dependency, log and monitor its failure events, since a pattern of frequent failures for a dependency configured to fail open still represents a reliability problem worth understanding and fixing, even though it isn't blocking any action in the meantime.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, defaults to failing closed for the authorization decisions it governs, reflecting the appropriate default for most tool-call authorization scenarios. Where a specific, deliberately identified exception genuinely warrants different handling, that decision and its justification belong in the application's own documented risk decisions, not as an unexamined default.
A short checklist
- Identify low-impact, easily reversible actions as candidates for
fail-open exceptions.
- Confirm a check is genuinely advisory, not an unacknowledged security
boundary, before allowing it to fail open.
- Verify genuine redundancy exists before relying on it to justify a
fail-open exception.
- Never fail open for irreversible or high-impact actions, regardless of
outage inconvenience.
- Document every fail-open decision with explicit reasoning and
approval.
- Revisit fail-open decisions when a workflow's risk classification
changes.
- Monitor fail-open dependency failures even though they do not block
anything.
Fail-open is appropriate for a small, deliberately identified set of low-impact, well-justified cases, and naming these exceptions explicitly, rather than defaulting every dependency reflexively to fail-closed, keeps the system's overall availability reasonable without compromising the cases where fail-closed genuinely matters.