Autorisations

Kiro utilise un système d'autorisations basé sur les capacités qui vous offre 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 modèles de correspondance et des effets explicites, remplaçant les anciens modèles de confiance binaires.

Sur Web, le modèle permissions.yaml et les approbations interactives ne s'appliquent pas : l'agent s'exécute plutôt dans un bac à sable infonuagique isolé sans demander d'approbation pour chaque action. Ces lignes indiquent donc N/A plutôt qu'une absence de prise en charge.

Le système d'autorisations repose sur trois concepts fondamentaux :

Propriétés de règle supplémentaires :

Les autorisations sont définies dans des fichiers YAML à deux niveaux :

Portée utilisateur (~/.kiro/settings/permissions.yaml) - s'applique à tous les projets. Utilisez-la pour préapprouver des opérations fiables :

rules:
  - capability: shell
    match: ["git *", "npm *", "npx *"]
    effect: allow

  - capability: fs_write
    match: ["src/**", "tests/**"]
    effect: allow

  - capability: fs_read
    effect: allow

  - capability: mcp
    match: ["my-server/*"]
    effect: allow

Portée d'espace de travail (~/.kiro/workspace-roots/<hash>/permissions.yaml) - s'applique uniquement à un projet précis. Utilisez-la pour restreindre des règles à une seule base de code :

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

  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny

Les deux portées prennent en charge tous les effets (deny, ask, allow).

Les règles prennent en charge un champ exclude pour les modèles « tout autoriser sauf » :

rules:
  - capability: mcp
    match: ["my-server/*"]
    exclude: ["my-server/dangerous-tool"]
    effect: allow

Les règles utilisent des modèles glob. La syntaxe diffère selon le type de capacité :

Modèles de système de fichiers (fs_read, fs_write) :

• * correspond à l'intérieur d'un seul composant de chemin
• ** correspond à travers les séparateurs de chemin
• L'expansion d'accolades {a,b} et les classes de caractères [abc] sont prises en charge
• Les modèles sans caractères génériques correspondent implicitement aux enfants : ~/temp correspond à ~/temp/child

Modèles Shell, Web et MCP :

• * correspond à toute séquence de caractères
• **, ? et les classes de caractères ne sont pas prises en charge

rules:
  # Allow npm commands except npm publish
  - capability: shell
    effect: allow
    match:
      - "npm *"
    exclude:
      - "npm publish*"

  # Deny reads to secrets at any depth
  - capability: fs_read
    effect: deny
    match:
      - "**/.env"
      - "**/.env.*"
      - "secrets/**"
      - "**/*.pem"

Les commandes shell sont analysées avant la correspondance de modèles. Les commandes composées (utilisant ;, &&, ||, |) sont scindées, et chaque sous-commande est évaluée indépendamment. Cela empêche une règle pour npm test * de correspondre accidentellement à npm test ; curl attacker.com.

Les autorisations sont évaluées à travers plusieurs portées.

Les règles sont évaluées à l'aide d'un algorithme de préséance du refus : deny > ask > allow. Il n'y a pas de préséance entre les portées - l'effet le plus restrictif l'emporte, quelle que soit la portée dont il provient.

Les préréglages de politique sont des ensembles nommés et composables de règles allow de portée session. Les clients qui créent des sessions d'agent via l'Agent Client Protocol (ACP), comme les intégrations d'éditeur, les robots de revue et les harnais de CI, les utilisent pour amorcer une session avec un profil de capacités bien défini sans écrire chaque règle individuellement.

Les préréglages sont demandés par un client ACP dans le champ _meta.kiro.policyPreset d'une requête session/new ou session/load. Plusieurs préréglages peuvent être combinés; leurs règles sont fusionnées par union.

{
  "_meta": {
    "kiro": {
      "policyPreset": ["edit-workspace", "dev-shell"]
    }
  }
}

Les règles de préréglage sont amorcées dans la session au moment où le client l'ouvre, indépendamment des règles que vous avez configurées dans permissions.yaml. C'est pourquoi les règles actives d'une session peuvent contenir des entrées que vous n'avez jamais écrites.

Demander un identifiant de préréglage inconnu entraîne le rejet de la demande de session. Il n'y a pas de repli silencieux vers une politique par défaut.

Les préréglages sont des profils composés uniquement de règles allow : ils suppriment les invites pour les opérations que la session doit effectuer, et tout le reste déclenche une invite d'approbation par défaut. Choisissez le profil le plus étroit qui correspond au travail de la session.

Chaque profil se demande de la même façon : les identifiants de préréglage vont dans le tableau policyPreset de la demande de session. Un robot de revue de code ouvre sa session avec :

{
  "_meta": {
    "kiro": {
      "policyPreset": ["read-workspace"]
    }
  }
}

Une session de diagnostic associe les lectures de l'espace de travail aux requêtes shell en lecture seule :

{
  "_meta": {
    "kiro": {
      "policyPreset": ["read-workspace", "read-only-shell"]
    }
  }
}

Un harnais de CI qui modifie, compile et teste combine les deux préréglages avec écriture :

{
  "_meta": {
    "kiro": {
      "policyPreset": ["edit-workspace", "dev-shell"]
    }
  }
}

Les règles deny et les invariants de la portée Kiro ci-dessous s'appliquent toujours, quel que soit le profil actif.

Les mêmes profils correspondent aux modèles d'intégration courants. Une intégration d'éditeur qui embarque Kiro demande généralement edit-workspace pour que les modifications de fichiers dans l'espace de travail ne déclenchent pas d'invite. Un robot de revue de code demande read-workspace et rien de plus. Un harnais de CI ou d'évaluation qui pilote l'agent par programmation combine edit-workspace et dev-shell, puis ajoute ses propres règles deny pour tout ce que le pipeline ne doit jamais toucher.

Les préréglages étendent ce qu'une session est autorisée à faire, mais ils ne peuvent pas remplacer des règles de préséance supérieure. L'algorithme de préséance du refus décrit dans la section Portées ci-dessus s'applique toujours intégralement :

• Les refus absolus de portée Kiro (écritures vers ~/.kiro/settings/, .kiro/settings/, ~/.kiro/workspace-roots/) bloquent l'action, quel que soit le préréglage.
• Les règles ask de portée Kiro (.git/**, .kiro/agents/**, .kiro/hooks/**, .kiroignore) demandent toujours une approbation, même lorsqu'un préréglage accorde un accès large en écriture.
• Toute règle deny que vous avez configurée à la portée user, workspace ou administration l'emporte sur un allow de préréglage.
• La capacité sandbox_network ne fait pas partie de la méta-capacité all : aucun préréglage, y compris allow-all, ne modifie donc le contrôle réseau du bac à sable.

Les sous-agents héritent de l'ensemble complet des règles de la session parente par intersection où le refus l'emporte : chaque allow, deny et ask du parent s'applique, de sorte que la règle la plus restrictive de part et d'autre l'emporte toujours.

Sans configuration permissions.yaml, la politique d'agent par défaut autorise :

• fs_read sur ./** - lire silencieusement n'importe quel fichier de l'espace de travail
• shell pour les commandes git courantes en lecture seule - git status, git log, git diff, git branch, et similaires
• shell pour les commandes d'information système - pwd, whoami, uname, et similaires
• Outils utilitaires (diagnostics, knowledge, et similaires)

La portée Kiro (codée en dur, non modifiable par la configuration) applique :

• Toujours refusé : les écritures vers ~/.kiro/settings/, .kiro/settings/ et ~/.kiro/workspace-roots/ (empêche l'agent de modifier ses propres fichiers d'autorisation)
• Demande toujours : les écritures vers .git/**, .kiro/agents/**, .kiro/hooks/**, .kiroignore

Tout le reste demande une approbation. Créer un fichier permissions.yaml s'ajoute à ces valeurs par défaut; il ne les remplace pas.

Voici des modèles courants pour configurer les autorisations :

Si vous effectuez une mise à niveau depuis CLI 2.x ou IDE 0.x, consultez les pages de référence pour savoir comment les autorisations fonctionnaient auparavant et ce qui a changé :

• Référence CLI 2.x - Autorisations
• Référence IDE 0.x - Autorisations
• Nouveautés de CLI 3.0 - Migration des autorisations