HeartBeatAgents

Sécurité

Voir en Markdown

Comment HeartBeatAgents applique une défense en profondeur pour des agents qui exécutent du code et font des requêtes HTTP en votre nom.

Les agents capables d'exécuter du code et d'appeler des services externes ont besoin de limites de sécurité qui tiennent même si le raisonnement de l'agent déraille. Le principe de conception de HeartBeatAgents est que chaque limite est physiquement incontournable : appliquée à un niveau que le code de l'agent ne peut pas contourner, pas simplement demandée poliment.

Les sept mécanismes

  1. Courtier d'identifiants : les agents reçoivent des jetons opaques plutôt que de véritables jetons OAuth. Les identifiants réels ne sont injectés qu'au moment de la requête HTTP et ne sont jamais exposés au LLM lui-même.
  2. Politique de sortie : les opérations de lecture et d'écriture sont traitées différemment. Les hôtes publics sont accessibles via GET ; POST/PUT/PATCH/DELETE sont restreints aux points de terminaison d'intégration approuvés, et HTTPS est obligatoire.
  3. Défense contre le DNS rebinding : la résolution DNS, la validation de l'IP et la connexion TCP elle-même sont réalisées de manière atomique au niveau de la pile réseau.
  4. Proxy de sortie : tout le trafic sortant passe par un proxy réseau exécuté dans un conteneur Docker isolé avec des règles iptables appliquées au niveau du noyau.
  5. Nettoyage des jetons : un système de nettoyage par reconnaissance de motifs inspecte chaque frontière de sortie (contexte du LLM, journaux, historique des appels d'outils) et retire les jetons OAuth, clés API et JWT avant qu'ils ne puissent fuiter.
  6. Authentification WebSocket : les connexions exigent un jeton d'authentification en amont ; signature, expiration et appartenance à l'organisation sont toutes vérifiées avant l'acceptation de la connexion.
  7. Durcissement des conteneurs : les agents s'exécutent en non-root, avec des capacités Linux réduites, un système de fichiers racine en lecture seule, une isolation de conteneur par organisation, et des limites de ressources appliquées.

Ce que cela signifie au quotidien

  • Vous ne collez jamais une clé API brute dans l'invite ou les ordres permanents d'un agent. Voir le Guide des intégrations pour la manière dont les connexions sont authentifiées à la place.
  • Révoquer l'accès d'une intégration est immédiat et total (voir Configuration).
  • Fonctionner en auto-hébergé n'affaiblit rien de tout cela : les mêmes limites de conteneur s'appliquent que HeartBeatAgents tourne sur votre ordinateur portable ou sur votre propre serveur (voir Auto-hébergement).

Comment cela est vérifié, pas seulement conçu

L'analyse des secrets s'exécute à chaque commit en CI et en tant que contrôle pre-commit, ainsi qu'une analyse périodique sur l'ensemble de l'historique des commits et des tags, afin qu'un identifiant qui se serait glissé dans un commit passé ne reste pas caché. C'est le type de contrôle dont une revue de sécurité peut demander à voir la preuve, pas seulement une politique que cette page affirme.

La sécurité de développement et de production reste structurellement séparée, pas seulement documentée comme différente : le démarrage refuse de s'exécuter avec un secret par défaut ou de type placeholder, à moins qu'un indicateur unique, explicite et journalisé bruyamment n'active un mode de développement local assoupli. Il n'existe pas de réglage intermédiaire qui affaiblirait discrètement la production sans que personne ne le remarque.

Accès aux dossiers

Les agents n'accèdent qu'aux parties de votre système de fichiers que vous partagez explicitement. Partagez un dossier depuis Paramètres → Accès aux dossiers et les agents peuvent y lire, et à moins que vous ne le marquiez en lecture seule, y écrire ; rien en dehors d'un dossier partagé n'est accessible. Les répertoires système et les magasins d'identifiants ne peuvent en aucun cas être partagés, quel que soit le chemin vers lequel vous essayez de pointer.

À voir aussi