Nouveau sur Kiro CLI 3.0? Cette page couvre les changements depuis la CLI 2.x. Si vous configurez les autorisations pour la première fois, commencez ici : Comportement par défaut (sans permissions.yaml) : Toutes les opérations demandent une approbation. Rien n'est autorisé ou refusé silencieusement. Créez un
permissions.yamlpour préapprouver les opérations fiables et réduire les interruptions.
Le système d'autorisations est le changement le plus important de la CLI 3.0. Les indicateurs de confiance et les commandes à barre oblique sont remplacés par une politique permissions.yaml structurée qui vous donne un contrôle précis et vérifiable sur ce que l'agent peut faire.
Le changement fondamental : au lieu d'indicateurs activant un accès étendu, vous déclarez exactement quelles capacités sont autorisées et pour quelles opérations. Tout le reste demande une approbation ou est bloqué par défaut.
| Comportement 2.x | Comportement 3.0 | Migration |
|---|---|---|
toolsSettings supprimé | Bloc de paramètres par outil (allowedCommands, deniedPaths, etc.) | permissions.rules unifié avec capability/match/effect |
autoAllowReadonly approuvait automatiquement les commandes shell en lecture seule | Aucun équivalent — listez explicitement les commandes autorisées | Ajoutez des règles d'autorisation shell pour les commandes en lecture seule que vous utilisez |
denyByDefault bloquait les outils non listés | Aucun équivalent | Utilisez exclude pour autoriser des exceptions : { capability: shell, exclude: ["git *", "npm *"], effect: deny } refuse tout sauf les motifs exclus |
| Motifs regex dans les autorisations | Motifs glob seulement (pas de regex) | Réécrivez .* en *, \.ts$ en *.ts, etc. |
Caractère générique ? pour un seul caractère | Non pris en charge pour les motifs shell/URL | Utilisez * ou explicitez les alternatives. Les motifs de chemins de fichiers (fs_read, fs_write) prennent toujours en charge ? |
fs_read/fs_write séparés par outil | Unifié — un seul refus fs_read bloque TOUS les outils de lecture (read, glob, grep, code) | Soyez conscient du rayon d'impact plus large |
| Le refus par outil était indépendant | Le refus l'emporte toujours, dans toutes les portées | Un refus n'importe où bloque l'action, quelles que soient les autorisations ailleurs |
kiro-cli --trust-all-tools kiro-cli --trust-tools shell,write /tools trust write /tools trust-all
Créez ~/.kiro/settings/permissions.yaml pour les règles à portée utilisateur :
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
Les règles à portée d'espace de travail (~/.kiro/workspace-roots/<hash>/permissions.yaml) sont stockées par utilisateur à l'extérieur du dépôt, de sorte qu'un dépôt cloné ne peut pas injecter de règles d'autorisation. Utilisez-les pour limiter les règles à un seul projet : un dépôt ne peut pas injecter de règles d'autorisation. Utilisez-les pour limiter les règles à un seul projet :
rules: - capability: shell match: ["rm -rf *", "sudo *"] effect: deny - capability: fs_write match: ["*.env", "*.pem", "*.key"] effect: deny
Les règles sont évaluées à l'aide d'un algorithme de préséance du refus : deny > ask > allow. Il n'y a aucune préséance entre les portées — l'effet le plus restrictif l'emporte, quelle que soit la portée d'où il provient.
| Portée | Emplacement | Effets autorisés |
|---|---|---|
| Kiro | Invariants de sécurité codés en dur (ne peuvent pas être remplacés) | deny, ask |
| administration | Politique gérée par l'entreprise/MDM (forfaits Entreprise seulement) | 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 | Exécution (p. ex. --trust-all-tools) | deny, ask, allow |
Sans aucune configuration, l'agent applique ces valeurs par défaut intégrées :
fs_read sur ./** — lit silencieusement tout fichier de l'espace de travailshell pour les commandes git en lecture seule courantes — git status, git log, git diff, et similairesshell pour les commandes d'information système — pwd, whoami, uname, et similairesfs_write vers ~/.kiro/settings/ et .kiro/settings/ — toujours refusé (empêche l'élévation de privilèges)La création d'un permissions.yaml s'ajoute à ces valeurs par défaut; elle ne les remplace pas. Le refus sur les chemins de paramètres est toujours appliqué.
Pour les pipelines d'intégration continue qui utilisaient auparavant --trust-all-tools, créez un fichier d'autorisations à portée utilisateur dans votre environnement d'intégration continue :
# ~/.kiro/settings/permissions.yaml (CI environment) rules: - capability: all effect: allow
L'indicateur --trust-all-tools fonctionne toujours comme un remplacement à portée de session et continue de fonctionner pour les cas d'utilisation d'intégration continue sans changement de configuration.
fs_read, fs_write, shell, web_fetch, web_search, mcp, subagent, skill, power, context, diagnostics, sandbox_network. Méta-capacités : all (tout), builtin (tous les outils intégrés), filesystem (fs_read + fs_write).
Les règles prennent également en charge un champ exclude pour les motifs « tout autoriser sauf » :
rules: - capability: mcp match: ["my-server/*"] exclude: ["my-server/dangerous-tool"] effect: allow
Migration des autorisations