Autorisations basées sur les capacités

Le système d'autorisations basées sur les capacités remplace le modèle de confiance 0.x — trustedCommands avec correspondance de préfixe et une liste de refus de commandes distincte avec correspondance de sous-chaîne — par un contrôle déclaratif et précis sur ce que l'agent peut faire. Vous définissez des règles par capacité, avec des motifs de correspondance et des effets explicites. Une seule règle peut cibler toute une classe d'opérations à travers tous les outils : un refus sur fs_read bloque tous les outils qui lisent des fichiers, sans avoir à les énumérer individuellement.

Les modes d'autonomie Autopilot et Supervised demeurent (Settings → Agent → Agent Autonomy, clé de paramètre kiroAgent.agentAutonomy). Ils déterminent si les modifications de fichiers s'appliquent immédiatement ou attendent une révision; la couche d'autorisations basées sur les capacités s'applique après que le mode d'autonomie a déterminé s'il faut procéder. Ensemble, ils vous offrent un contrôle à gros grain ainsi que des règles à grain fin.

Les autorisations sont définies dans des fichiers YAML. Il existe deux portées :

À portée d'espace de travail (~/.kiro/workspace-roots/<hash>/permissions.yaml, stocké par utilisateur en dehors du dépôt) — utilisez deny pour bloquer les opérations dangereuses dans un projet précis :

rules:
  - capability: fs_write
    match: ["*.env", "*.pem", "*.key"]
    effect: deny
  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny

À portée utilisateur (~/.kiro/settings/permissions.yaml) — utilisez allow pour préapprouver les opérations de confiance dans tous les espaces de travail :

rules:
  - capability: shell
    match: ["git *", "npm *", "npx *"]
    effect: allow
  - capability: fs_write
    match: ["src/**", "tests/**"]
    effect: allow
  - capability: mcp
    match: ["my-server/*"]
    effect: allow

Dans la 0.x, la confiance était configurée par outil : une seule intention comme « refuser les lectures de .env » devait être définie séparément pour chaque outil pouvant lire des fichiers, et en oublier un laissait une brèche. Dans la 1.0, exprimez l'intention une seule fois au niveau de la capacité.

• Si vous utilisiez les commandes de confiance, traduisez chaque préfixe en une règle d'autorisation shell (git *, npm *) dans votre permissions.yaml à portée utilisateur.
• Si vous vous appuyiez sur la liste de refus de commandes, traduisez chaque entrée en une règle de refus shell. Les règles de refus gagnent sur les règles d'autorisation dans toutes les portées.
• Aucune configuration n'est requise au préalable. Sans aucune règle, l'agent peut lire les fichiers de l'espace de travail et exécuter des commandes git en lecture seule; tout le reste déclenche une demande, et vous pouvez conserver les décisions prises depuis l'invite comme règles « toujours autoriser » ou « toujours refuser ».

Pour la référence complète (capacités, syntaxe des motifs, le flux d'approbation interactif et des exemples de configuration), consultez Permissions.