> ## 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. # Policies > How Averta policies control runtime checkpoint decisions. Policies live in Averta and attach to API keys. Your app sends an Averta API key with each runtime decision request; the policy attached to that key determines enforcement. ## What Code Owns vs. Policy Owns | Your application owns | Averta policy owns | | --------------------- | ------------------------------------------------------- | | Provider client | Whether checkpoints allow, block, restrict, or rewrite. | | Model selection | Request screening threshold. | | Tool definitions | Tool exposure rules. | | Tool execution code | Which tools should be hidden for a request. | | Conversation state | Dashboard-visible enforcement configuration. | | Request context | Event correlation through IDs. | This separation is the whole point. If you hardcode enforcement in the app, every threshold change becomes a deploy. ## Why Policies Attach to API Keys The API key is the runtime bridge between your app and Averta. Attaching policy to the key lets you: * use one production policy without changing application code * keep staging behavior separate from production * isolate agents with different tool sets * rotate credentials without rewriting the integration A key without an attached policy is not ready for normal runtime enforcement. ## Current Dashboard Controls The current dashboard exposes live controls for: * request policy * tool exposure policy The policy editor may also show sections for tool-call, tool-result, and output policy. Treat those as inactive dashboard editors unless your team has explicitly enabled a product path for them. Runtime SDKs and the raw API still understand all checkpoint decision types. The dashboard configuration surface is what is narrower today. ## Tool Exposure Policies Tool exposure policies can return `restrict_tools` during request preflight. The wrapper then filters the provider-native tool list before calling OpenAI or Anthropic. This is different from blocking the whole request: * `block`: the provider call does not happen. * `restrict_tools`: the provider call continues with a smaller tool set. Use tool exposure when you want graceful degradation instead of a hard stop. ## Policy Design Advice Do not build one giant policy unless every agent really shares the same risk profile. One tweak for a sensitive email-sending agent can accidentally change behavior for a read-only search agent. Better defaults: * one policy per environment when staging and production need different tolerance * one policy per agent when tools or risk differ materially * one API key per deployed app or agent boundary * tool exposure rules for side-effectful tools first ## Where to Configure Policies Use the dashboard to create policies, attach them to API keys, and inspect decision events. Create and manage policies. Attach policies to runtime credentials. Configure request-time tool filtering. Confirm how policy changes affect runtime decisions.