すべてのドキュメント
dvarドキュメント

承認とruntime safety

境界付きapproval grant、quota、loop detection、circuit breaker、共有runtime stateを使います。

リポジトリを見る
dvarドキュメント
6ページ中4ページ

Dvarは、policy evaluationとexecution-time authorizationを分離します。これにより、チームはポリシーを安全にpreviewしつつ、副作用が発生する直前にstateful limitを適用できます。

Approval rules

自律的に実行すべきではない機密操作にはapprovalを使います。

yaml
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.amount

Dvarのapproval grantは署名付きで期限があり、レビュー済みcontextに紐づきます。金額、ツール、環境、ユーザー、セッション、または設定済みargument fieldが変わるとgrantは無効になります。

Approval scopes

ScopeUse case
once1つの正確なレビュー済み操作。
session1つのsession内の関連操作の境界付き集合。
task1つのtaskに対する操作の境界付き集合。

金融、破壊的操作、外部通信、インフラ、データエクスポートにはonceを優先してください。

Runtime limits

Runtime safetyは、許可された操作であっても実行できる内容を制限します。

yaml
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は、call ceiling、cost quota、monetary quota、retry limit、depth limit、repeated-action loop、alternating-action loop、circuit breakerをenforceできます。

Shared stores

複数instanceが同じpolicyを実行する場合はRedisまたはValkeyを使ってください。process-local memoryは開発には便利ですが、distributed production limitには十分ではありません。

Failure behaviour

strict modeでは、必要なruntime stateが利用できない場合にfail closedします。strict mode以外でのfail-open behaviorはpolicyで明示する必要があります。Dvarは設定されたsafety dependencyを黙ってdowngradeしてはいけません。