Fail-closed behavior

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

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;
}

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

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

Get Started

Core Concepts

OpenAI

Anthropic

Dashboard

Advanced

Fail-closed behavior

Common Fail-closed Cases

Why This Matters

Handling Errors

Integration Rule

​Common Fail-closed Cases

​Why This Matters

​Handling Errors

​Integration Rule

Common Fail-closed Cases

Why This Matters

Handling Errors

Integration Rule