Dvar separates policy evaluation from execution-time authorization. This lets teams preview policy safely while still enforcing stateful limits immediately before side effects occur.
Approval rules
Use approvals for sensitive actions that should not be executed autonomously.
rules:
- id: approve-production-refunds
effect: require_approval
when:
environment: production
tool.name: payments.refund
approval:
provider: manual
scope: once
bind:
- principal.id
- environment
- tool.name
- arguments.paymentId
- arguments.amountDvar approval grants are signed, expiring, and bound to reviewed context. A changed amount, tool, environment, user, session, or configured argument field invalidates the grant.
Approval scopes
| Scope | Use case |
|---|---|
once | One exact reviewed action. |
session | A bounded set of related actions in one session. |
task | A bounded set of actions for one task. |
Prefer once for financial, destructive, external communication, infrastructure, and data-export operations.
Runtime limits
Runtime safety constrains what even an allowed action can do.
runtime:
limits:
- id: session-tool-calls
metric: calls
max: 50
window: session
scope: [principal, agent, session]
- id: production-cost-budget
metric: cost
max: 10
window: day
scope: [tenant, environment]Dvar can enforce call ceilings, cost and monetary quotas, retry limits, depth limits, repeated-action loops, alternating-action loops, and circuit breakers.
Shared stores
Use Redis or Valkey when multiple instances execute the same policy. Process-local memory is useful for development but is not enough for distributed production limits.
Failure behaviour
Strict mode fails closed when required runtime state is unavailable. Outside strict mode, any fail-open behaviour must be explicit in policy. Dvar must not silently downgrade a configured safety dependency.