Gesamte Dokumentation
dvar-Dokumentation

Approvals und Runtime-Sicherheit

Nutzen Sie begrenzte Approval-Grants, Quoten, Schleifenerkennung, Circuit Breaker und geteilten Runtime-Zustand.

Repository ansehen
dvar-Dokumentation
Seite 4 von 6

Dvar trennt Policy-Bewertung von Autorisierung zur Ausführungszeit. So können Teams Policy sicher voranzeigen und gleichzeitig zustandsbehaftete Limits unmittelbar vor Side Effects erzwingen.

Approval-Regeln

Nutzen Sie Approvals für sensible Aktionen, die nicht autonom ausgeführt werden sollten.

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-Grants sind signiert, ablaufend und an geprüften Kontext gebunden. Ein geänderter Betrag, ein anderes Tool, eine andere Umgebung, ein anderer Benutzer, eine andere Session oder ein konfiguriertes Argumentfeld macht den Grant ungültig.

Approval-Scopes

ScopeAnwendungsfall
onceEine exakt geprüfte Aktion.
sessionEine begrenzte Menge verwandter Aktionen in einer Session.
taskEine begrenzte Menge von Aktionen für eine Aufgabe.

Bevorzugen Sie once für finanzielle, destruktive, externe Kommunikations-, Infrastruktur- und Datenexportoperationen.

Runtime-Limits

Runtime-Sicherheit beschränkt, was selbst eine erlaubte Aktion tun kann.

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 kann Call-Obergrenzen, Kosten- und Geldquoten, Retry-Limits, Tiefenlimits, Wiederholungsaktionsschleifen, Alternierungsaktionsschleifen und Circuit Breaker erzwingen.

Geteilte Stores

Nutzen Sie Redis oder Valkey, wenn mehrere Instanzen dieselbe Policy ausführen. Prozesslokaler Speicher ist für Entwicklung nützlich, reicht aber für verteilte Produktionslimits nicht aus.

Fehlerverhalten

Strict Mode schlägt geschlossen fehl, wenn erforderlicher Runtime-Zustand nicht verfügbar ist. Außerhalb von strict mode muss jedes Fail-open-Verhalten explizit in der Policy stehen. Dvar darf eine konfigurierte Sicherheitsabhängigkeit nicht stillschweigend herabstufen.