> ## 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

> Create reusable policies, configure request enforcement, and manage policy lifecycle.

A policy is the reusable enforcement profile attached to one or more Averta API keys.

Each runtime decision uses the policy attached to the API key that made the request.

## What Policies Control Today

The current dashboard has live controls for:

* request policy
* tool exposure policy

The policy editor may also display sections for tool-call, tool-result, and output policy. Treat those sections as inactive controls unless your team has explicitly enabled them. The live dashboard controls documented here are request policy and tool exposure.

## Access

Policies are visible only to roles with policy permissions:

| Role  | Policy access                |
| ----- | ---------------------------- |
| Owner | View and manage policies.    |
| Admin | View and manage policies.    |
| User  | No policy management access. |

## Policy List

The policies list shows one row per policy, including:

* policy name
* request policy summary
* request protection status
* number of attached API keys
* last updated time

Use this page to create a policy or open a policy editor.

## Create a Policy

When creating a policy, set:

* policy name
* request risk threshold

The current request policy model is intentionally simple:

* default action is `allow`
* a binary block rule evaluates request risk
* the request is blocked when the score is greater than or equal to the threshold

If you do not change it, the default threshold starts at `0.90`.

## Request Policy

Request policy controls the first checkpoint: the request before provider execution.

From the policy editor, you can:

* rename the policy
* change the binary threshold
* save updates
* enable or disable request protection

Disabling request protection affects every API key attached to that policy. Do not use it as a casual debugging switch in production.

## Tool Exposure Policy

Tool exposure is also configured inside a policy. It removes tools before they are shown to the model.

Use tool exposure to:

* hide high-impact tools on riskier requests
* allow safer tools without blocking the whole request
* respond to newly discovered tools
* degrade agent capability before a hard block

Detailed rule semantics live in [Tool exposure policy](/dashboard/tool-exposure-policy).

## Lifecycle Safeguards

The policy detail view shows:

* current status
* current threshold
* number of attached API keys
* last updated time

Deletion is blocked while API keys are attached. That is the right safeguard: deleting a policy that still backs live credentials would break or change runtime enforcement.

## Recommended Setup

| Scenario                      | Recommendation                                                   |
| ----------------------------- | ---------------------------------------------------------------- |
| Production and staging differ | Use separate policies and separate API keys.                     |
| Agents have different tools   | Use separate policies per agent boundary.                        |
| One tool is high impact       | Add selective tool exposure rules before broad request blocking. |
| A new tool appears in events  | Review discovered tools and map it intentionally.                |
| A policy feels noisy          | Inspect events before changing thresholds.                       |

## Related Pages

<CardGroup cols={2}>
  <Card title="Tool exposure policy" icon="toolbox" href="/dashboard/tool-exposure-policy">
    See rule semantics, discovered tools, and rollout guidance.
  </Card>

  <Card title="API Keys" icon="key" href="/dashboard/api-keys">
    Attach policies to organization-owned credentials.
  </Card>

  <Card title="Events" icon="activity" href="/dashboard/events">
    Confirm policy behavior from runtime decisions.
  </Card>
</CardGroup>