> ## 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. # How Averta works > The runtime model Averta uses to protect agent execution. Averta is an enforcement layer around provider calls. It does not replace OpenAI, Anthropic, or your agent loop. Your application still owns: * the provider client * the model * the tools * the tool execution code * the conversation history * the response returned to the user Averta adds decisions at the points where an agent can cross a security boundary. ## Mental Model One user turn can produce several Averta decisions. ```mermaid theme={null} flowchart LR A["User input"] --> B["Request checkpoint"] B --> C{"Decision"} C -->|allow or restrict_tools| D["Provider call"] C -->|block| X["Stop before provider"] D --> E{"Tool call?"} E -->|yes| F["Tool-call checkpoint"] F --> G["Your tool executes"] G --> H["Tool-result checkpoint"] H --> D E -->|no| I["Output checkpoint"] I --> J{"Decision"} J -->|allow| K["Return response"] J -->|rewrite| L["Provider rewrite"] L --> I J -->|block| Y["Stop before user"] ``` The provider wrapper hides most of this plumbing, but the lifecycle matters when you debug [events](/dashboard/events) or write a [custom adapter](/custom/overview). ## Four Decisions | Decision | Meaning | Typical wrapper behavior | | ---------------- | -------------------------------------- | ----------------------------------------------------------------------------------------- | | `allow` | Continue normally. | Forward the request, expose the tool call, forward the tool result, or return the output. | | `block` | Stop at this checkpoint. | Throw `AvertaSdkError`. | | `restrict_tools` | Continue the request with fewer tools. | Remove `blockedTools` before calling the provider. | | `rewrite` | Replace final output. | Ask the provider for a safer answer, then check the rewrite once. | Valid decisions depend on checkpoint type. For example, `rewrite` is valid for output checks, not request checks. ## Why Tool Exposure Is Separate Tool exposure is not the same as tool execution. * Tool exposure runs before the provider call and controls which tools the model can see. * Tool-call checks run after the model asks for a tool and control whether your app should execute it. This distinction is not academic. If a dangerous tool is hidden, the model usually never plans with it. If a dangerous tool call is blocked, the model already requested it, but your app stops before execution. ## Where Policy Lives Your code defines the agent. [Averta policy](/concepts/policies) defines enforcement. That separation lets you: * keep provider integrations stable * tune enforcement without redeploying application code * attach different policies to production, staging, or separate agents * inspect decisions in the dashboard by API key and request context ## Text, Images, and Rich Media Averta checks normalized request content, not arbitrary provider payloads. Text is always the first-class path. Supported image inputs are extracted into a separate media payload so policy can evaluate them alongside the text request. Provider support is intentionally narrower than provider capability. If a wrapper cannot safely normalize a media type, it fails closed instead of silently sending an unguarded provider request. See [Images and rich media](/concepts/images-and-rich-media) before using multimodal agent inputs. ## Reading Path Learn what each checkpoint sees and what happens when it blocks. Understand `allow`, `block`, `restrict_tools`, and `rewrite`. Correlate decisions by conversation, request, and trace. Understand current multimodal support. See how policies attach to runtime credentials.