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.
| Capacité | IDE | CLI | Web | Mobile |
|---|---|---|---|---|
| Configuration YAML des autorisations | ✓ | ✓ | — | — |
| Invites d'approbation interactives | ✓ | ✓ | — | — |
| Portées globales et d'espace de travail | ✓ | ✓ | — | — |
Le système d'autorisations repose sur trois concepts fondamentaux :
| Concept | Description |
|---|---|
| Capacités | fs_read, fs_write, shell, web_fetch, web_search, mcp, subagent, skill, power, context, diagnostics, sandbox_network. Les méta-capacités s'étendent : all (tout), builtin (tous les outils intégrés), filesystem (fs_read + fs_write) |
| Effets | deny (bloquer toujours), ask (vous demander), allow (procéder silencieusement) |
| Priorité | deny > ask > allow - une règle deny l'emporte toujours, quelle que soit la portée |
Propriétés de règle supplémentaires :
| Propriété | Description |
|---|---|
| Modèles de correspondance | Modèles glob qui déterminent la portée de la règle (chemins de fichiers pour fs, préfixes de commande pour shell, noms de serveur/outil pour MCP) |
| Exclude | Modèles glob facultatifs qui ne doivent PAS correspondre - permet « tout autoriser sauf X » |
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{a,b} et les classes de caractères [abc] sont prises en charge~/temp correspond à ~/temp/childModèles Shell, Web et MCP :
* correspond à toute séquence de caractères**, ? et les classes de caractères ne sont pas prises en chargerules: # 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.
| Portée | Emplacement | Effets autorisés |
|---|---|---|
| Kiro | Invariants de sécurité codés en dur (ne peuvent pas être modifiés par la configuration) | deny, ask |
| administration | Politiques d'autorisations Enterprise dans managed-settings.json | deny, ask |
| user | ~/.kiro/settings/permissions.yaml | deny, ask, allow |
| workspace | ~/.kiro/workspace-roots/<hash>/permissions.yaml | deny, ask, allow |
| agent | Intégré dans le profil de l'agent (champ permissions) | deny, ask, allow |
| session | Règles en mémoire issues des décisions de consentement prises pendant la session | deny, ask, allow |
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.
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 travailshell pour les commandes git courantes en lecture seule - git status, git log, git diff, git branch, et similairesshell pour les commandes d'information système - pwd, whoami, uname, et similairesLa portée Kiro (codée en dur, non modifiable par la configuration) applique :
~/.kiro/settings/, .kiro/settings/ et ~/.kiro/workspace-roots/ (empêche l'agent de modifier ses propres fichiers d'autorisation).git/**, .kiro/agents/**, .kiro/hooks/**, .kiroignoreTout le reste demande une approbation. Créer un fichier permissions.yaml s'ajoute à ces valeurs par défaut; il ne les remplace pas.
En plus des règles permissions.yaml, l'autonomie de l'agent dans l'IDE est contrôlée via Paramètres → Agent → Autonomie de l'agent (clé de paramètre : kiroAgent.agentAutonomy). Les deux modes sont :
La couche d'autorisations basée sur les capacités s'applique après que le mode d'autonomie ait déterminé s'il faut procéder. Ensemble, ces deux couches vous offrent un contrôle global (Autopilot vs Supervisé) ainsi que des règles précises (permissions.yaml) pour des capacités spécifiques.
Lorsqu'un outil nécessite une approbation, une invite apparaît dans le clavardage. Allow et Deny sont disponibles pour l'invocation en cours. Kiro affiche aussi des choix persistants lorsqu'il peut dériver une règle enregistrée qui fonctionnera pour la commande demandée :
| Action | Effet |
|---|---|
| Allow | Approuver cette invocation précise, une seule fois |
| Always allow | Créer une règle allow persistante (ouvre le sélecteur de modèle/portée) |
| Deny | Bloquer cette invocation précise, une seule fois |
| Always deny | Créer une règle deny persistante |
Si Kiro ne peut pas vérifier une règle enregistrée fonctionnelle, il masque Always allow et Always deny et explique pourquoi dans l'invite.
Lorsque vous sélectionnez Always allow, vous configurez deux choses :
cd * pour toute commande cd, ou le chemin de commande exact)~/.kiro/settings/permissions.yaml à portée utilisateur~/.kiro/workspace-roots/<hash>/permissions.yaml (par utilisateur, à l'extérieur du dépôt)Le menu déroulant de modèles suggère une version généralisée de l'opération précise - par exemple, la commande exacte git add contents/docs/ devient le modèle git add *, et le chemin exact .env.local devient .env* ou **/.env*. Vous pouvez modifier la suggestion pour la rendre plus restrictive ou plus permissive.
Pour les commandes enchaînées (p. ex., cd /path && cargo build), chaque sous-commande de la chaîne est présentée séparément pour approbation.
Voici des modèles courants pour configurer les autorisations :
| Scénario | Configuration |
|---|---|
| Approuver les lectures de fichiers | capability: fs_read, effect: allow |
| Approuver l'écriture dans les répertoires du projet | capability: fs_write, match: ["src/**", "tests/**"], effect: allow |
| Bloquer les fichiers sensibles | capability: fs_write, match: ["*.env", "*.pem", "*.key"], effect: deny |
| Bloquer les commandes dangereuses | capability: shell, match: ["rm -rf *", "sudo *"], effect: deny |
| Approuver un serveur MCP précis | capability: mcp, match: ["my-server/*"], effect: allow |
| Retirer la confiance du shell en production | capability: shell, effect: ask (ou utilisez /tools untrust shell dans la CLI) |
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é :
Autorisations