Skip to main content
Les profils de sécurité vous permettent de définir des ensembles réutilisables de restrictions de sécurité — accès réseau, accès MCP, accès git et identifiants GitHub CLI — et de les appliquer aux sessions Devin dans toute votre organisation. Au lieu de configurer ces restrictions session par session, les administrateurs créent des profils nommés une seule fois et les associent au niveau le plus pertinent : comme valeur par défaut à l’échelle de l’organisation, sur une automatisation spécifique ou sur une session individuelle. Les environnements Enterprise peuvent également partager des profils entre toutes les organisations et les imposer comme seuil minimal strict que personne à un niveau inférieur ne peut assouplir.

​
Restrictions d’un profil

Un profil est un ensemble nommé de restrictions. Chaque restriction est facultative — un profil n’impose de restrictions qu’aux paramètres qu’il configure.

​
Politique réseau

Une politique réseau est une liste d’autorisation des destinations que la machine de la session est autorisée à joindre. Toutes les autres connexions sortantes sont bloquées. Les entrées de la liste d’autorisation peuvent être :
  • Noms d’hôte, avec des caractères génériques * (par ex. *.github.com, registry.npmjs.org). Un * correspond à n’importe quelle suite de caractères, y compris les points.
  • Plages CIDR IPv4 / IPv6 (par ex. 10.0.0.0/8).
La restriction s’applique à tous les accès réseau depuis la session — commandes shell, navigation, installations de packages et scripts. Devin détecte lorsqu’il s’exécute sous une politique réseau restrictive : il peut voir la liste d’autorisation actuelle et, lorsqu’il est bloqué parce qu’une destination manque, il demandera l’accès. L’approbation de la demande ajoute la destination pour cette session (sous réserve de toute application obligatoire — voir application). Les destinations nécessaires au fonctionnement de Devin (comme le proxy git utilisé pour accéder à vos dépôts connectés) sont autorisées automatiquement.

​
Accès MCP

Par défaut, les sessions peuvent utiliser n’importe quel serveur MCP installé dans votre organisation. Un profil peut restreindre cela avec une liste d’autorisation de serveurs MCP — les sessions soumises au profil ne peuvent utiliser que les serveurs listés.
L’accès MCP est géré indépendamment de la politique réseau : vous n’avez pas besoin d’ajouter l’adresse d’un serveur MCP à la liste d’autorisation réseau. Les serveurs autorisés par le profil sont automatiquement accessibles, et les serveurs exclus par le profil restent inutilisables quelle que soit la politique réseau.

​
Accès à Devin MCP

Les sessions ont également accès aux propres outils de gestion de Devin via le Devin MCP intégré — création de sessions enfants et envoi de messages, modification de Knowledge et des playbooks, gestion des planifications, etc. Un profil peut restreindre ce périmètre avec Devin MCP en lecture seule : les sessions régies par ce profil peuvent toujours consulter les ressources de Devin (lister les sessions, consulter Knowledge, examiner les playbooks), mais ne peuvent pas effectuer d’opérations d’écriture comme créer des sessions ou modifier Knowledge.

​
Niveau d’accès Git

Définit ce que la session peut faire avec vos dépôts connectés :

​
Jeton GitHub CLI

Au-delà des opérations git de base autorisées par le niveau d’accès git, la machine de Devin peut disposer d’un jeton GitHub CLI (gh) qui permet à Devin d’utiliser directement les fonctionnalités de GitHub via l’API GitHub. Un profil peut supprimer le jeton GitHub CLI de la machine : les sessions régies par ce profil continuent d’utiliser vos dépôts via l’intégration git de Devin, mais ne peuvent pas effectuer d’appels directs à l’API GitHub. Un profil ne peut conserver le jeton que s’il accorde également un accès git complet et, s’il définit une politique réseau, autorise api.github.com. Ces deux conditions sont vérifiées lors de l’enregistrement du profil.

​
Où se trouvent les profils

Les profils existent à deux périmètres :
  • Les profils d’organisation sont créés dans Settings → Customization → profils de sécurité et ne peuvent être utilisés qu’au sein de cette organisation.
  • Les profils Enterprise (comptes Enterprise uniquement) sont créés dans Enterprise settings → Devin → profils de sécurité et peuvent être utilisés par toutes les organisations de l’Enterprise. Les organisations peuvent sélectionner un profil Enterprise pour leurs sessions, leurs automatisations ou leur configuration par défaut d’organisation, mais seuls les administrateurs Enterprise peuvent modifier le profil lui-même.
Les noms de profil doivent être uniques dans leur périmètre. Chaque profil comporte également un niveau d’application qui détermine si les niveaux inférieurs peuvent y déroger.

​
Ce à quoi vous pouvez associer un profil

Un profil prend effet lorsqu’il est associé à une ressource. Les associations forment une hiérarchie, du niveau le plus large au plus spécifique :
  1. Par défaut pour l’Enterprise — s’applique aux nouvelles sessions dans chaque organisation de l’Enterprise.
  2. Par défaut pour l’organisation — s’applique aux nouvelles sessions de cette organisation.
  3. Par défaut pour les automatisations — s’applique aux sessions démarrées par les automatisations de cette organisation, en remplaçant la valeur par défaut de l’organisation pour ces sessions. Défini depuis la même page des Settings des profils de sécurité.
  4. Automatisation — s’applique aux sessions démarrées par cette automatisation spécifique, en remplaçant la valeur par défaut des automatisations. Défini depuis l’Editor de l’automatisation.
  5. Session — choisi pour une session individuelle lors de sa création (via le menu d’options dans le panneau de démarrage de session), ou modifié plus tard dans les Settings de la session.
À chaque niveau, vous pouvez faire l’un des trois choix suivants :
  • Hériter (par défaut) — aucun choix explicite ; le niveau supérieur décide.
  • Épingler un profil — les sessions à ce niveau utilisent le profil sélectionné.
  • Aucun profil — retrait explicite, afin que les sessions à ce niveau s’exécutent sans restriction même si un niveau supérieur définit une valeur par défaut recommandée.
Lorsqu’une session démarre, Devin parcourt la hiérarchie de haut en bas : l’association la plus spécifique l’emporte, sauf si un profil obligatoire défini plus haut impose des restrictions (voir ci-dessous). Les sessions lancées par d’autres sessions (sessions enfants) sont régies par la même chaîne que leur parent ; il n’est donc pas possible de contourner les restrictions en déléguant le travail.

​
Quand les modifications prennent effet

Une session détermine le profil qui la régit au moment où elle démarre : lors de sa création initiale, puis chaque fois qu’elle sort de veille ou redémarre. Les modifications apportées au contenu d’un profil ou à une association quelconque (une valeur par défaut, une automatisation épinglée ou une sélection de session) ne se propagent pas automatiquement aux sessions déjà en cours d’exécution — une session en cours conserve les restrictions déterminées lors de sa dernière sortie de veille. Les modifications prennent effet immédiatement pour les nouvelles sessions, et pour les sessions existantes, la prochaine fois qu’elles reprennent. Chaque profil possède un niveau d’application : Un profil recommandé est un profil par défaut, pas une obligation. Toute personne (disposant de l’autorisation appropriée) à un niveau inférieur peut épingler un profil différent ou s’en retirer complètement. Utilisez les profils recommandés pour offrir aux Teams une configuration initiale pertinente tout en conservant la flexibilité.

​
Obligatoire

Un profil obligatoire constitue un seuil minimal auquel les niveaux inférieurs ne peuvent pas déroger :
  • Le refus n’a aucun effet. Une sélection « aucun profil » sous un profil obligatoire est ignorée.
  • Les sélections des niveaux inférieurs peuvent uniquement renforcer les restrictions, jamais les assouplir. Si un niveau inférieur épingle un autre profil, les deux sont croisés :
    • Les listes d’autorisation réseau sont restreintes aux destinations autorisées par les deux profils.
    • Les listes d’autorisation MCP sont restreintes aux serveurs autorisés par les deux.
    • L’accès Git prend le minimum (la lecture seule l’emporte sur l’accès complet).
    • L’accès Devin MCP est en lecture seule si l’un ou l’autre des profils définit la lecture seule.
    • Le jeton GitHub CLI est supprimé si l’un ou l’autre des profils le supprime.
  • Les modifications en cours de session restent contraintes. L’accès réseau accordé pendant une session (p. ex. en approuvant la demande de Devin pour un nouveau domaine) est croisé avec la politique du profil obligatoire ; une session ne peut donc jamais obtenir un accès dépassant ce qu’autorise le profil obligatoire.
Par exemple, une entreprise peut associer un profil obligatoire à une politique réseau autorisant *.internal.example.com comme valeur par défaut à l’échelle de l’entreprise. Les organisations peuvent ensuite superposer leurs propres profils pour restreindre davantage des Teams ou des workflows spécifiques, mais aucune organisation, aucune automatisation ni aucune session ne peut élargir l’accès au-delà de la politique de l’entreprise.

​
Autorisations et gouvernance

La gestion des profils est régie par une autorisation dédiée, Gérer les profils de sécurité, distincte de la gestion générale des paramètres. Elle existe à deux niveaux, chacun étant accordé indépendamment : Les deux niveaux de cette autorisation peuvent être attribués à des rôles personnalisés, ce qui vous permet de déléguer la gestion des politiques de sécurité (par exemple à une équipe de sécurité) sans accorder tous les droits d’administration. Les membres qui ne disposent pas de cette autorisation ne peuvent ni lister, ni sélectionner, ni modifier les profils — leurs sessions appliquent simplement la configuration par défaut résolue — mais chacun peut voir si sa session est régie par un profil et de quel accès réseau elle dispose.

​
Configuration des profils de sécurité

  1. Créez un profil. Accédez à Settings → Customization → Profils de sécurité (ou Enterprise settings → Devin → Profils de sécurité pour un profil à l’échelle de l’entreprise), créez un profil et configurez ses paramètres de sécurité et son niveau d’application.
  2. Définissez une valeur par défaut. Définissez ce profil comme profil par défaut de votre organisation (ou profil par défaut de l’entreprise) afin que les nouvelles sessions l’utilisent automatiquement.
  3. Épinglez-le là où c’est nécessaire. Appliquez une dérogation à la valeur par défaut sur des automatisations spécifiques — par exemple, un profil plus strict pour une automatisation qui touche des systèmes sensibles — ou sur des sessions individuelles au moment de leur création.
  4. Renforcez progressivement. Commencez par un profil recommandé pour observer l’impact, puis rendez-le obligatoire une fois que vos listes d’autorisation couvrent les besoins légitimes de vos équipes.

​
Automatisations et profils

Les automatisations peuvent avoir leur propre politique réseau et leur propre sélection de serveurs MCP. Il s’agit de couches uniquement restrictives qui s’ajoutent au profil applicable : les sessions démarrées par l’automatisation n’ont accès qu’aux destinations réseau et aux serveurs MCP autorisés par l’automatisation et le profil. Une automatisation ne peut donc jamais étendre l’accès du profil. La couche d’automatisation est déterminée dynamiquement à chaque démarrage ou sortie de veille de session. La modification de la politique réseau d’une automatisation prend donc effet sans qu’il soit nécessaire de recréer ses sessions.

​
Outposts et profils

Les sessions exécutées sur les Devin Outposts déterminent leur profil applicable via la même chaîne d’association que les sessions cloud, et les restrictions appliquées par Devin depuis son cloud — la liste d’autorisation MCP, le mode lecture seule de Devin MCP, le niveau d’accès Git et la suppression du jeton de la GitHub CLI — s’appliquent aux sessions Outpost exactement comme aux sessions cloud. La politique réseau est différente. Devin applique la liste d’autorisation réseau d’une session au niveau de la machine sur les VM gérées par Devin, mais un worker Outpost s’exécute sur l’infrastructure que vous exploitez. Devin n’installe donc pas de règles de pare-feu sur vos machines. À la place, la politique réseau effective de chaque session en file d’attente est transmise à votre orchestrateur via l’API Outposts sous la forme de spec.network_policy (l’activation de la politique, ainsi que les noms d’hôte et CIDR autorisés). Son application — par exemple à l’aide d’un proxy de sortie par session, d’une NetworkPolicy Kubernetes ou de règles de pare-feu de VM — relève de la responsabilité de l’opérateur Outpost. Devin voit toujours la liste d’autorisation et demande l’accès aux destinations manquantes comme d’habitude, mais l’approbation d’une demande met uniquement à jour la politique de la session dans Devin ; elle ne modifie pas votre réseau à elle seule. spec.network_policy est capturée lorsque la session est mise en file d’attente pour un Outpost et actualisée lorsqu’elle y est remise en file d’attente (par exemple après que la session entre en veille et en sort). Relisez-la donc via l’API plutôt que de supposer qu’elle est statique.
Si vous vous appuyez sur la politique réseau d’un profil obligatoire comme frontière stricte, assurez-vous que votre infrastructure Outpost applique spec.network_policy à chaque session qu’elle exécute. Sans cela, les sessions sur les Outposts disposent du même accès réseau que vos machines.