Policy model — dvarドキュメント

dvarドキュメント

6ページ中2ページ

Dvar policy is written in dvar.yaml. The policy describes how proposed actions are evaluated before a tool, MCP call, framework tool, or local process is allowed to execute.

Core decision effects

Dvar produces one terminal effect:

Effect	Meaning
`allow`	The action may proceed.
`deny`	The action must not execute.
`require_approval`	A reviewer or approval provider must approve before execution.

Policy is deterministic. A decision must be reproducible from the normalized action, policy, lockfile state, approval state, and runtime safety state.

Modes

Mode	Behaviour
`off`	Dvar does not enforce policy.
`monitor`	Dvar allows execution while recording what it would have allowed, denied, or escalated.
`enforce`	Dvar blocks denies and approval-gated actions before execution.
`strict`	Dvar also fails closed on undeclared safety or integrity uncertainty.

Use monitor during rollout. Do not market monitor mode as protection.

Minimal policy

yaml

schemaVersion: "1"
mode: monitor
defaultEffect: deny

rules:
  - id: allow-safe-read-tools
    effect: allow
    when:
      tool.capabilities:
        containsAny: ["read"]

  - id: approve-production-finance
    effect: require_approval
    when:
      environment: production
      tool.capabilities:
        containsAny: ["finance"]
    approval:
      provider: manual
      scope: once

Normalized action fields

Rules can evaluate identity, environment, tenant, session, task, server, tool, arguments, destination, resource, risk, and metadata fields.

Common rule targets include:

principal.id
agent.id
environment
server.id
tool.name
tool.capabilities
arguments.*
destination.value
risk.level

Policy tests

Add examples to the policy and run:

bash

npx dvar test-policy
npx dvar replay actions.replay.jsonl --policy dvar.yaml

Replay never executes tools. It evaluates historical action records against current policy so teams can review policy changes safely.