Sécurité

Crew donne à un agent d'IA un accès réel aux outils — lecture de fichiers, commandes shell, navigation Web. Le modèle de sécurité repose sur la défense en profondeur : plusieurs couches indépendantes, chacune appliquée à la limite de l'environnement d'exécution plutôt que de s'appuyer uniquement sur des instructions dans les requêtes.

Chaque appel d'outil passe par ces vérifications, dans l'ordre :

1. Verrouillage du propriétaire — la passerelle du canal rejette les utilisateurs non autorisés avant que le message n'atteigne une session
2. Commandes refusées : les modèles intégrés et configurés bloquent les opérations destructrices (vérifiées avant de demander l'approbation)
3. Plafond de gouvernance — Politique ∩ Profil (le plus strict l'emporte) — ne peut pas être assoupli par l'agent ou l'application
4. Chemins sensibles et masques du bac à sable : les outils de fichiers directs bloquent les chemins protégés et le bac à sable du système d'exploitation masque les emplacements d'identifiants protégés aux sous-processus
5. Approbation des outils — révision interactive, escalade de confiance ou Autopilot (ne s'active qu'une fois les vérifications de refus réussies)
6. Validation des entrées — schémas MCP, vérifications de type, limites de longueur, normalisation Unicode
7. Bac à sable du système d'exploitation — isolation du système de fichiers au niveau du processus via des espaces de noms Linux ou Seatbelt sur macOS
8. Masquage des sorties — les modèles d'identifiants sont retirés de la réponse avant d'atteindre toute surface de clavardage

Le journal des événements de sécurité enregistre chaque décision à chaque étape. Il est transversal, et non une porte séquentielle.

Le bac à sable du système d'exploitation masque les chemins d'identifiants aux sous-processus de l'agent. Configurez à partir de Paramètres → Sécurité ou via kirocrew config set agent.sandbox <mode>.

Sur Linux, le bac à sable utilise des espaces de noms utilisateur et de montage. Sur macOS, il utilise des profils Seatbelt.

Le bac à sable adopte une position de refus lorsque Crew ne peut pas l'appliquer. Sous Linux, cela comprend armv7l, riscv64, ppc64le et s390x, ou une libc sans prctl. Sous Windows, cela s'applique lorsque le bac à sable interne de Kiro CLI est désactivé. Dans ces cas, Crew refuse de démarrer l'agent, sauf si vous définissez explicitement agent.sandbox sur off ou agent.sandbox_allow_unsandboxed_exec sur true.

Contrôlez la façon dont l'agent obtient la permission d'exécuter des outils. Configurez à partir de Paramètres → Sécurité ou du bouton Autopilot propre à la session. Lorsque Crew bloque un appel, son refus indique à l'agent quelle action est permise au lieu de le laisser réessayer la même requête.

Les commandes refusées et les blocages de chemins sensibles ne sont jamais contournés — même en mode Autopilot.

Lorsque plusieurs appels d'outils attendent votre réponse à la fois, un clic les approuve ou les rejette tous. La confirmation énumère chaque commande qu'elle couvre.

Vous pouvez aussi rejeter un seul appel et continuer à examiner les autres, plutôt que de refuser tout le lot. Un refus ne s'applique qu'à cet appel, de sorte que l'agent peut le réviser et le soumettre de nouveau.

Si un redémarrage met fin à une autorisation active et limitée dans le temps, Crew indique que l'autorisation a été abandonnée. Si l'hôte refuse un appel d'outil plutôt qu'une personne, Crew nomme la cause, comme une approbation expirée, un budget de tour épuisé ou l'échec de la livraison Slack.

Les longues commandes shell affichent un résumé facile à lire de ce qu'elles font. La commande complète est accessible en un survol.

Lorsque vous utilisez le harness Claude Code, un outil déjà préapprouvé dans les paramètres de Claude contourne le flux d'approbation de Crew. Les règles de refus et le journal d'audit de Crew n'observent pas cet appel. Codex refuse de démarrer lorsque agent.sandbox est défini sur off, car Crew demeure sa limite de bac à sable du système d'exploitation.

kirocrew chat affiche les invites d'autorisation des outils en ligne. Les tours ne restent plus bloqués silencieusement jusqu'à l'expiration du délai dans le terminal.

Les modèles intégrés bloquent les opérations destructrices et les voies courantes d'exfiltration d'identifiants avant l'approbation. Exemples :

• rm -rf /, rm -rf ~
• git push vers des branches protégées (main, mainline)
• cat ~/.aws/credentials, cat ~/.ssh/id_rsa
• curl 169.254.169.254 (métadonnées IMDS)
• aws ec2 terminate-instances, cdk destroy, DROP TABLE
• echo $AWS_SECRET*, commandes révélant des identifiants

Le moteur de correspondance continue d'appliquer les règles de refus malgré les guillemets shell, les caractères d'échappement, la substitution de commandes et les noms de programmes écrits avec des caractères génériques. Il ne bloque plus le travail normal simplement parce qu'il ressemble à une commande risquée : un grep récursif dans un espace de travail, un cd suivi d'un tube et les here-documents contenant des accents graves s'exécutent normalement.

Gérez les règles à partir de Paramètres → Sécurité → Commandes refusées. Vous pouvez désactiver par ID les règles individuelles admissibles, désactiver toutes les règles non épinglées ou ajouter des modèles personnalisés. Les règles fournies par votre édition portent une étiquette dans la liste et peuvent aussi être désactivées par ID.

Les identifiants sont protégés à plusieurs niveaux :

• Chemins sensibles bloqués — l'agent ne peut pas lire .aws, .ssh, .gnupg, .env, et d'autres fichiers d'identifiants par des appels d'outils
• Masquage des sorties — les clés AWS, les en-têtes de clé privée, les jetons Slack, les jetons GitHub, les URI de connexion à des bases de données et plus de 15 autres modèles d'identifiants sont retirés de chaque surface de sortie avant d'atteindre le clavardage
• Caviardage avant la troncation : les identifiants sont caviardés avant le raccourcissement d'un long texte afin qu'un secret chevauchant une limite de troncation ne s'affiche jamais dans les lignes d'audit, les journaux, les charges utiles du tableau de bord ou la sortie des Hooks
• Sortie de diagnostic sûre : les journaux échappent les caractères de contrôle et les URL de connexion ayant des paramètres d'autorisation valides ne sont pas rejetées comme de simples secrets
• Nettoyage de l'environnement — les variables d'environnement sensibles sont retirées des sous-processus de l'agent

Les secrets sont stockés dans un coffre-fort chiffré plutôt que dans votre fichier de configuration. Gérez-les à partir de Paramètres → Secrets dans le tableau de bord : les valeurs restent masquées dans l'interface et ne sont jamais envoyées au navigateur, de sorte que le tableau de bord n'affiche que le nom de chaque secret.

• Chiffré au repos : le coffre-fort stocke chaque valeur sous chiffrement authentifié, associé à un fichier de clé local
• Masqué dans l'interface : l'API des paramètres ne renvoie que les noms des secrets, donc aucune valeur stockée n'est envoyée au navigateur par la surface de gestion des secrets
• Retenu aux agents : une liste fixe de noms de clés d'environnement d'identifiants est retirée des sous-processus de l'agent

L'environnement d'un serveur MCP peut nommer un secret stocké sous la forme secret://NAME. La valeur est résolue à partir du coffre-fort au moment du lancement, de sorte que le secret ne se trouve jamais dans la configuration sur disque :

{
  "mcpServers": {
    "example": {
      "command": "example-server",
      "env": {
        "API_TOKEN": "secret://EXAMPLE_API_TOKEN"
      }
    }
  }
}

Si le secret nommé est absent du coffre-fort, le lancement échoue plutôt que de démarrer le serveur sans lui.

Chaque canal de messagerie est verrouillé aux utilisateurs autorisés :

• Slack — KIROCREW_OWNER_ID (propriétaire unique)
• Discord — liste d'autorisation refusant par défaut, basée sur les ID d'utilisateurs
• Telegram — liste d'autorisation d'ID d'utilisateurs numériques
• Teams — liste d'autorisation de courriels / ID d'objets Azure AD
• Webex — liste d'autorisation de courriels
• WeCom — liste d'autorisation d'ID d'utilisateurs (ou adhésion explicite via allow_all_users)
• WeChat — liste d'autorisation d'ID d'utilisateurs (refuse tout le monde par défaut)
• WhatsApp : le compte lié est l'opérateur. L'accès aux messages directs suit whatsapp.dm_policy; les groupes configurés n'acceptent que l'opérateur et les numéros dans whatsapp.allowed_wa_ids. Les autres expéditeurs autorisés utilisent des sessions distinctes sans outils sur le backend Kiro; les autres backends d'agent refusent leurs tours.
• iMessage : refus par défaut avec une liste d'autorisation explicite d'identifiants (macOS seulement)
• Feishu (Lark) : liste d'autorisation d'utilisateurs autorisés
• Tableau de bord — authentifié par jeton (chaque requête exige un jeton valide)

Les messages non autorisés sont silencieusement rejetés et enregistrés dans le journal d'audit.

Des fichiers de politique et de profil facultatifs se combinent selon un modèle où le plus strict l'emporte. Une application ou un agent en cours d'exécution peut restreindre la portée autorisée, mais ne peut pas assouplir le plafond. Dans tous les modes de bac à sable, la politique de sécurité, la politique d'admission, les profils et la liste des commandes refusées sont montés en lecture seule, de sorte qu'un script, Hook ou cron de commande exécuté dans le bac à sable ne peut pas réécrire ces contrôles.

• Politique — plafond au niveau de l'entreprise (chargée depuis ~/.kiro/crew/security_policy.json)
• Profil — restriction par surface ou par tâche (chargée depuis ~/.kiro/crew/profiles/)
• Effectif = Politique ∩ Profil (le plus strict l'emporte)

Les administrateurs peuvent publier un security_policy.json à une URL et faire en sorte que chaque hôte le récupère, le mette en cache et l'actualise périodiquement. Une modification de politique prend effet dans tout le parc sans redémarrage ni visite d'un hôte. Si la source est inaccessible, les hôtes continuent d'utiliser la copie en cache. Un document qui ne passe pas la validation est rejeté plutôt que d'abaisser le plafond en vigueur.

Sur un compte Kiro d'entreprise doté d'un registre MCP configuré par un administrateur, les contrôles MCP au niveau de l'organisation, y compris les versions épinglées, s'appliquent. Les comptes personnels ne sont pas concernés.

Les administrateurs peuvent autoriser leurs propres fournisseurs OAuth par configuration, sans attendre qu'une version en ajoute un.

Inspectez à partir de l'interface en ligne de commande :

kirocrew policy show        # display effective policy
kirocrew policy validate    # check policy files for errors
kirocrew policy explain     # explain how a tool call would be evaluated

Lorsque file_send détecte du contenu qui ressemble à un identifiant, il refuse la livraison et indique le processus de vérification. Le propriétaire du tableau de bord peut armer une approbation unique sous Paramètres → Sécurité, vérifier la destination et le fichier, puis exécuter cette commande directement sur l'hôte de la passerelle :

kirocrew file-delivery approve

L'agent ne peut pas accomplir lui-même cette étape sur l'hôte. La commande est refusée lorsque Computer Use est activé, afin d'empêcher un agent de simuler l'approbation de l'opérateur par automatisation du clavier. L'approbation se limite à la requête armée; elle ne contourne pas les contrôles pour les fichiers suivants.

Git sur SSH et la signature de commits par SSH peuvent utiliser le SSH_AUTH_SOCK de l'opérateur dans le bac à sable d'un agent uniquement après un consentement explicite. Le socket permet d'utiliser les clés détenues par l'agent SSH; il ne copie pas les clés privées dans le bac à sable. Le code exécuté par l'agent peut utiliser toute identité offerte par ce socket, donc le transfert est désactivé par défaut.

Créez ~/.kiro/crew/ssh_auth_sock_consent.json depuis votre propre terminal, à l'extérieur du bac à sable de l'agent :

{"enabled": true}

Aucun paramètre ni commande destinée à l'agent ne peut accorder cette autorisation. Les autres variables d'environnement sensibles demeurent supprimées, et le mode de bac à sable strict continue de masquer les fichiers de clés.

Chaque appel d'outil, approbation, refus et événement de sécurité est enregistré. Inspectez à partir de l'interface en ligne de commande :

kirocrew security events    # view recent security events
kirocrew security audit     # view the audit trail
kirocrew security verify    # verify audit-log integrity

Le journal d'audit peut être consulté à partir du tableau de bord, sous Paramètres → Sécurité.

• Gardez agent.sandbox à auto ou strict — n'exécutez pas avec off sans raison précise
• Utilisez Autopilot avec parcimonie — c'est pratique, mais cela retire la porte humaine pour les appels d'outils
• Ne collez pas d'identifiants dans le clavardage — le masquage capte les sorties, mais l'entrée relève de votre responsabilité
• Passez en revue les personnalisations des commandes refusées — désactiver des règles de refus affaiblit la protection
• Utilisez des profils de gouvernance pour les déploiements partagés ou en équipe afin d'imposer un plafond

Pour l'architecture de sécurité complète, y compris les détails d'implémentation, consultez le dépôt KiroCrew.