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 — 137 modèles 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. Blocage des chemins sensibles — les répertoires et fichiers d'identifiants sont inaccessibles aux appels d'outils
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

L'audit (SEL) 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. Windows ne dispose actuellement pas de cette couche au niveau du système d'exploitation — toutes les autres protections s'appliquent tout de même.

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.

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

137 modèles intégrés bloquent les opérations destructrices et les voies courantes d'exfiltration d'identifiants. 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

Gérez à partir de Paramètres → Sécurité — vous pouvez désactiver des règles individuelles, désactiver toutes les règles ou ajouter vos propres modèles personnalisés.

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
• Nettoyage de l'environnement — les variables d'environnement sensibles sont retirées des sous-processus de l'agent

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)
• 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.

• 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)

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

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 est inclus dans les instantanés et 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 l'analyse approfondie de la sécurité du dépôt.