Skip to main content
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 ownsAverta policy owns
Provider clientWhether checkpoints allow, block, restrict, or rewrite.
Model selectionRequest screening threshold.
Tool definitionsTool exposure rules.
Tool execution codeWhich tools should be hidden for a request.
Conversation stateDashboard-visible enforcement configuration.
Request contextEvent 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.

Dashboard policies

Create and manage policies.

API keys

Attach policies to runtime credentials.

Tool exposure

Configure request-time tool filtering.

Events

Confirm how policy changes affect runtime decisions.