Physiquement incontournable. Confiance zéro.

Les agents qui exécutent du code et font des requêtes HTTP ont besoin d'une sécurité qui ne dépend pas du bon comportement de l'agent. Sept mécanismes l'assurent :

1. Courtier d'identifiants : des jetons opaques remplacent les véritables jetons OAuth ; les identifiants réels ne sont injectés qu'au moment de la requête HTTP elle-même.
2. Politique de sortie : GET est largement autorisé ; POST/PUT/PATCH/DELETE sont restreints aux points de terminaison d'intégration approuvés, HTTPS est obligatoire.
3. Défense contre le DNS rebinding : la résolution DNS, la validation de l'IP et la connexion TCP se font de manière atomique au niveau de la pile réseau.
4. Proxy de sortie : un conteneur Docker isolé avec des règles iptables appliquées au niveau du noyau constitue l'unique voie de sortie du trafic.
5. Nettoyage des jetons : chaque frontière de sortie (contexte du LLM, journaux, historique des outils) est analysée pour retirer les jetons OAuth, clés API et JWT.
6. Authentification WebSocket : les connexions exigent un jeton signé, non expiré et propre à l'organisation avant d'être acceptées.
7. Durcissement des conteneurs : exécution non-root, capacités Linux réduites, système de fichiers racine en lecture seule, isolation par organisation, limites de ressources appliquées.

Composable par conception

Une seule requête (par exemple, publier vers une API de calendrier) traverse plusieurs de ces mécanismes en séquence : la politique de sortie la valide, le courtier d'identifiants résout le jeton, la défense DNS vérifie l'IP, l'authentification injecte l'identifiant, et le nettoyage des jetons assainit les journaux qui en résultent.

Vérifié, pas seulement affirmé

L'analyse des secrets s'exécute en CI et en pre-commit à chaque commit, ainsi qu'un examen périodique de l'historique complet sur chaque commit et chaque tag, pas seulement sur l'arborescence actuelle. C'est un contrôle dont on peut demander à voir la preuve, pas seulement une déclaration de politique.

La commodité de développement et la sécurité de production restent structurellement séparées : le démarrage refuse de s'exécuter avec des secrets par défaut ou de type placeholder, à moins qu'un indicateur unique, explicite et journalisé bruyamment n'active le mode de développement local non sécurisé. Il n'existe pas de réglage intermédiaire discret.

À voir aussi

• Intégrations : le modèle OAuth 2.0 + PKCE que ces limites protègent
• Compétences : les compétences auto-construites restent à l'intérieur de ces mêmes limites