Politiques d'autorisation

Déployez des politiques d'autorisation sur votre parc pour restreindre ce que l'agent peut faire. Vous pouvez bloquer des commandes shell dangereuses, refuser l'accès Web ou forcer des invites pour des capacités précises. Ces règles ont préséance sur les paramètres d'autorisation propres à un utilisateur.

Lorsqu'une règle administrateur et une règle utilisateur visent la même capacité, l'effet le plus restrictif l'emporte :

deny > ask > allow

Un deny administrateur bloque l'opération, quoi que permettent les autorisations personnelles de l'utilisateur. Un ask administrateur force une invite même si l'utilisateur a une règle allow pour cette capacité.

Les politiques administrateur peuvent uniquement utiliser deny ou ask, jamais allow. Elles peuvent restreindre l'accès, mais pas l'accorder.

Placez un fichier de politique JSON au chemin protégé par le système d'exploitation pour votre plateforme. Ces chemins exigent un accès administrateur ou racine pour être modifiés, ce qui garde la politique hors de portée d'un compte utilisateur standard. La politique s'applique à toutes les surfaces Kiro sur la machine, car l'IDE et l'interface de ligne de commande lisent le même fichier.

sudo mkdir -p "/Library/Application Support/Kiro"
sudo nano "/Library/Application Support/Kiro/managed-settings.json"

{
  "rules": [
    { "capability": "web_fetch", "effect": "deny" },
    { "capability": "shell", "match": ["rm *", "sudo *"], "effect": "deny" }
  ]
}

Redémarrez Kiro pour que la politique prenne effet.

Chaque règle suit le même schéma que les autorisations rédigées par un utilisateur :

Pour la liste complète des capacités et de la syntaxe des motifs, consultez Permissions.

{
  "rules": [
    { "capability": "web_fetch", "match": ["*"], "effect": "deny" },
    { "capability": "web_search", "effect": "deny" },
    { "capability": "shell", "match": ["curl *", "wget *"], "effect": "deny" }
  ]
}

Empêche l'agent de récupérer des URL, de faire des recherches Web ou d'utiliser des commandes shell pouvant exfiltrer des données.

{
  "rules": [
    {
      "capability": "web_fetch",
      "exclude": ["docs.aws.amazon.com", "*.amazonaws.com", "*.github.com"],
      "effect": "deny"
    }
  ]
}

Refuse la récupération Web à tout domaine sauf ceux de la liste d'exclusion. Les domaines correspondant aux motifs d'exclusion n'ont aucune règle administrateur, donc ils retombent sur les autorisations propres à l'utilisateur, qui peuvent autoriser ou demander.

{
  "rules": [
    { "capability": "mcp", "effect": "ask" }
  ]
}

Même si un utilisateur a { "capability": "mcp", "effect": "allow" } dans ses autorisations personnelles, l'ask administrateur l'emporte, donc chaque appel d'outil MCP demande une confirmation.

{
  "rules": [
    {
      "capability": "shell",
      "match": ["rm *", "sudo *", "chmod *", "chown *", "mkfs *"],
      "effect": "deny"
    }
  ]
}

{
  "rules": [
    {
      "capability": "fs_write",
      "match": ["~/**"],
      "exclude": ["~/.kiro/**"],
      "effect": "deny"
    }
  ]
}

Empêche l'agent d'écrire dans le répertoire personnel de l'utilisateur (sauf le répertoire de configuration propre à Kiro), même si l'utilisateur a des autorisations d'écriture plus larges configurées.

Les politiques d'autorisation sont validées au démarrage de Kiro :

• JSON mal formé : Le fichier entier est rejeté et Kiro échoue en mode fermé. Tous les appels d'outils sont refusés jusqu'à ce que le fichier soit corrigé ou supprimé.
• Effet invalide : Les règles avec effect: "allow" sont rejetées (les politiques administrateur permettent uniquement deny et ask). Le fichier entier échoue, avec le même résultat de fermeture.
• Capacités inconnues : Les règles avec des noms de capacité non reconnus sont ignorées avec un avertissement, mais les règles valides restantes se chargent tout de même. Cela permet aux politiques plus récentes de fonctionner sur des versions plus anciennes de Kiro.
• Champs inconnus : Les règles avec des champs supplémentaires non prévus dans le schéma entraînent le rejet du fichier entier. Cela évite que des fautes de frappe (comme effct au lieu de effect) désactivent silencieusement les règles administrateur.

Après avoir déployé la politique :

1. Redémarrez Kiro sur une machine de test
2. Confirmez qu'aucun avertissement de validation de politique n'apparaît au démarrage. Kiro avise l'utilisateur si le fichier de politique n'a pas pu être chargé
3. Tentez une action qui devrait être refusée (par exemple, demandez à l'agent de faire une recherche Web si vous avez refusé web_search)
4. Vérifiez que l'agent signale un refus, la source de la règle indiquant « administration »

Lorsqu'un appel d'outil est refusé par une politique administrateur, l'utilisateur voit un message indiquant que la restriction est gérée par son organisation et que ses propres paramètres d'autorisation ne peuvent pas la contourner.

Les politiques d'autorisation fonctionnent de concert avec les autres fonctionnalités de gouvernance d'entreprise de Kiro :

• Gouvernance des modèles contrôle quels modèles d'IA sont disponibles
• Gouvernance MCP contrôle à quels serveurs MCP les utilisateurs peuvent se connecter
• Gouvernance des outils Web désactive entièrement les outils Web depuis la console
• Mises à jour gérées contrôle quelles versions de l'IDE atteignent votre parc

Utilisez les politiques d'autorisation lorsque vous avez besoin de correspondance de motifs, de listes d'autorisation ou de restrictions propres à une capacité. Pour activer ou désactiver une fonctionnalité entière, utilisez plutôt les paramètres de gouvernance de la console.