Toute la documentation
Documentation dvar

Approbations et sécurité runtime

Utilisez des grants d’approbation bornés, des quotas, la détection de boucles, des circuit breakers et un état runtime partagé.

Voir le dépôt
Documentation dvar
Page 4 sur 6

Dvar sépare l’évaluation de politique de l’autorisation au moment de l’exécution. Cela permet aux équipes de prévisualiser une politique en sécurité tout en appliquant des limites avec état juste avant les effets secondaires.

Règles d’approbation

Utilisez les approbations pour les actions sensibles qui ne devraient pas être exécutées de manière autonome.

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

Les grants d’approbation Dvar sont signés, expirables et liés au contexte revu. Un changement de montant, d’outil, d’environnement, d’utilisateur, de session ou de champ d’argument configuré invalide le grant.

Portées d’approbation

PortéeCas d’usage
onceUne action exacte déjà revue.
sessionUn ensemble borné d’actions liées dans une session.
taskUn ensemble borné d’actions pour une tâche.

Préférez once pour les opérations financières, destructives, de communication externe, d’infrastructure et d’export de données.

Limites runtime

La sécurité runtime contraint ce qu’une action, même autorisée, peut faire.

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 peut appliquer des plafonds d’appels, quotas de coût et monétaires, limites de relance, limites de profondeur, boucles d’actions répétées, boucles d’actions alternées et circuit breakers.

Stores partagés

Utilisez Redis ou Valkey lorsque plusieurs instances exécutent la même politique. La mémoire locale au processus est utile en développement, mais insuffisante pour des limites distribuées en production.

Comportement en cas d’échec

Le mode strict échoue fermé lorsque l’état runtime requis est indisponible. Hors strict mode, tout comportement fail-open doit être explicite dans la politique. Dvar ne doit pas dégrader silencieusement une dépendance de sécurité configurée.