> ## Documentation Index
> Fetch the complete documentation index at: https://docs.averta.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Fail-closed behavior

> How Averta SDK wrappers handle unsupported or unsafe execution paths.

Averta wrappers fail closed on guarded paths when they cannot safely enforce a checkpoint.

That means unsupported inputs on documented wrapper methods throw before provider execution instead of silently bypassing protection. Native provider methods that are not listed as guarded surfaces are outside Averta coverage unless you add separate enforcement.

## Common Fail-closed Cases

| Case                                         | Behavior                                                  |
| -------------------------------------------- | --------------------------------------------------------- |
| Anthropic streaming                          | Throws before provider execution.                         |
| OpenAI streaming output rewrite              | Throws when policy requires rewrite during streaming.     |
| Unsupported rich media source                | Throws before request preflight.                          |
| Unsupported tool shape                       | Throws before provider execution.                         |
| Native provider method not listed as guarded | Not an Averta-guarded path. Do not treat it as protected. |
| Missing `run_id` for active tool chain       | Throws before tool-call checks continue.                  |
| Malformed Averta decision response           | Throws `AvertaSdkError`.                                  |
| Checkpoint-incompatible decision             | Throws `AvertaSdkError`.                                  |

## Why This Matters

Silent bypass is worse than a noisy failure. If the wrapper cannot prove that a checkpoint ran correctly, continuing would make your app look protected when it is not.

That is not conservative documentation language; it is the right security posture.

## Handling Errors

<CodeGroup>
  ```typescript TypeScript theme={null}
  import { AvertaSdkError } from "@averta-security/sdk-core";

  try {
    await guardedProviderCall();
  } catch (error) {
    if (error instanceof AvertaSdkError) {
      console.error(error.code);
      console.error(error.statusCode);
      console.error(error.checkpointDecision);
    }

    throw error;
  }
  ```

  ```python Python theme={null}
  from averta_core import AvertaSdkError

  try:
      guarded_provider_call()
  except AvertaSdkError as error:
      print(error.code)
      print(error.status_code)
      print(error.checkpoint_decision)
      raise
  ```
</CodeGroup>

For user-facing products, catch the error at your application boundary and return a safe fallback message. Log the error with `requestContext` or `request_context` so you can find the matching dashboard event.

## Integration Rule

Do not catch `AvertaSdkError` and retry the same provider call with an unwrapped client. That defeats the guardrail.

Acceptable responses are:

* return a safe fallback
* ask the user to rephrase
* remove unsupported input and retry through the wrapped client
* fix the integration path
* adjust policy if the block is expected but too strict