Choose failure behavior before controls fail

Learning objective

Choose fail-closed versus fail-open guardrail behavior based on risk, reversibility, latency, and downstream impact.

Core idea

A guardrail can return a policy decision, or it can fail to return a usable decision. Fail-closed behavior prevents the guarded consequence when that decision is unavailable. Fail-open behavior permits some defined consequence despite the unavailable check. Choose the behavior before an outage and for each operation, rather than assigning one permissive default to the whole agent.

The deciding question is what can happen while permission or safety remains unknown. A delayed suggestion and a completed bank transfer have different consequences. Evaluate risk, practical reversibility, the latency budget, and every downstream consumer that can act on the result. An operation that looks harmless locally can become consequential when another agent treats its output as authorization.

How it works

Separate denial from unavailable evaluation

A successful check can return a rejection. That is a policy outcome, not a detector outage. Do not use fail-open recovery to bypass a known denial. Likewise, a timeout, malformed response, or exception does not mean that the candidate is safe.

For an application-managed Content Safety check, ContentSafetyClient.analyze_text(...) returns category analysis on success and can raise HttpResponseError. The quickstart handles the exception separately from reading categories_analysis. Preserve that distinction in the application decision record. A failure to obtain the analysis should never be represented as a successful result with no detected categories.

Use application-defined outcomes such as accepted, denied, and unavailable, and map each to a permitted next step. Keep the failed check identifier, candidate identifier, elapsed time, and failure reason in the decision evidence. The fields are your contract, not a standardized Microsoft response schema.

Assess risk and practical reversibility

Fail closed when an unknown result could permit unauthorized disclosure, a prohibited action, or an effect that cannot be reliably reversed. A reversible database write is not necessarily a reversible business consequence: an email recipient can retain a message, a customer can rely on an offer, and another service can consume an emitted event immediately.

Ask what restoration requires. Can you restore the previous state without another principal’s cooperation? Can you retract every copy? Can you prove that no dependent action happened? If those answers are uncertain, treat the operation as consequential even when a compensating API exists.

For a low-impact, local suggestion that performs no action and exposes no sensitive information, a bounded fail-open path might be acceptable. State exactly what remains permitted: for example, displaying a preapproved public help message. Do not turn permission to show that message into permission to release the unvalidated model response or run a write tool.

Only an unavailable result reaches the choice between failing closed and a bounded fail-open path, and the operation’s consequence decides it.

Fit the decision inside the latency budget

Allocate time for the check and for the safe terminal response. A detector that times out after the caller’s deadline does not provide a useful synchronous gate. Choose an explicit timeout, then route unavailable results according to policy rather than launching unlimited retries.

Native Foundry guardrail processing adds approximately 50–100 ms per intervention point, varying with content length and the number of active controls. Include every configured point in the latency estimate rather than treating that number as a guaranteed total.

Python Agent Framework’s Agent Hooks has a per-interceptor and resolver timeout, defaulting to five seconds for awaitable calls. A synchronous interceptor that blocks the event loop cannot be preempted by this setting. Measure the path you deploy, including any external policy lookup, rather than interpreting the configured timeout as a universal wall-clock guarantee.

The capability is experimental in Python and unavailable in .NET and Go. In mode="enforce", interceptor failure or timeout blocks the guarded action by design. This is a concrete fail-closed contract, not a setting that automatically selects the application’s preferred availability trade-off. See 4.2.6 for verdict construction and integration.

A tighter latency objective can justify a preapproved degraded response, asynchronous review, or deferral. It does not justify silently treating the missing result as a pass. Keep the original candidate withheld while offering the approved alternative, and tell downstream stages which outcome actually occurred.

Account for streaming and persisted state

For native Foundry Tool call (Preview) controls, Microsoft documents that Annotate and block prevents a flagged call and stops the agent until another user input. These controls require a tool that supports moderation; see 4.2.1. Account for that stopped interaction in downstream recovery, rather than assuming the blocked agent continues autonomously.

Output that has already reached a caller cannot be made unseen by a later rejection. Agent Hooks buffers streaming updates until the complete model response passes post_model_call and the final response passes output. If either denies, no partial updates reach the caller. This trades token-by-token latency for output enforcement.

Persistence is a separate consequence. Default after-run history persistence waits for the output verdict. With require_per_service_call_history_persistence=True, each model exchange can persist after its post_model_call verdict permits it. A later output denial does not roll back that history. Put a confidentiality check at the persistence-relevant point when storage itself carries risk.

Cancellation also has limits. When a function-middleware failure aborts concurrent tool calls, Agent Framework cancels in-flight siblings cooperatively. A synchronous tool already running in a worker thread can finish its side effects even though its result is discarded. Failing closed at the orchestration layer does not establish that every concurrent effect was prevented or reversed.

Bound any fail-open exception

Treat fail-open as an approved exception for a particular check and outcome. Define its allowed operations, duration, affected consumers, and recovery conditions. Do not disable authentication, authorization, or mandatory disclosure controls because an optional ranking or presentation check is unavailable.

Agent Hooks’ evaluate_only mode records decisions but allows every action and applies no transformations. It is useful for measuring a proposed rule, but it is not a selective outage fallback: using it would stop enforcement of the installed controls. Do not switch the bundle into that mode merely to recover availability for one optional function.

If your application catches an enforcement failure, return a separately constructed, preapproved response outside the rejected candidate’s path. Preserve MiddlewareFailure when an unsafe function execution must abort; catching it inside middleware and continuing changes fail-closed behavior to fail-open. The application owns the fallback contract and must keep it narrower than the blocked operation.

Key distinctions and trade-offs

Use the consequence to choose the response:

Fail closed reduces exposure but makes control availability part of service availability. Bounded fail open can preserve low-impact service but accepts a specified residual risk. A degraded response can preserve useful behavior while withholding the unvalidated consequence. These policies can coexist within one workflow.

Architecture / decision scenario

A travel assistant recommends public destinations, drafts an itinerary from private employee records, and books tickets. Its presentation-quality check fails while producing a public help suggestion. The application returns an approved static suggestion; that exception permits no booking and no private-record output.

The disclosure detector then times out on an employee itinerary. The system withholds the candidate and offers deferral because disclosure cannot be retracted. If the ticket-purchase policy service is unavailable, the booking remains unapproved even when the user-facing deadline is short. The system returns a bounded failure instead of submitting the purchase.

The architect verifies buffered output, the point where private history persists, and whether concurrent booking tools had already started. Those checks connect latency and reversibility to downstream impact. A generic “the agent failed closed” log would not prove that no private data was stored or ticket purchased.

Common exam traps

• Treating a known policy denial as an availability failure to bypass.
• Converting missing analysis into an empty successful result.
• Assuming a compensating transaction reverses disclosure or reliance.
• Switching evaluate_only on as a selective fail-open fallback.
• Assuming an output denial rolls back persisted history or tool effects.
• Treating cooperative cancellation as proof that every side effect stopped.

What to remember

Choose failure behavior per consequence. Risk and practical reversibility determine what can proceed while the verdict is unknown; latency determines whether to wait or return a safe terminal outcome. Include streaming, persistence, and downstream actions in the decision, and make any permitted fallback explicit and narrow.

Knowledge check

References

• Microsoft, Agent hooks

• Microsoft, Quickstart: Analyze text content

• Microsoft, Intervention points concepts